Monday, December 29, 2014

Git Flow finishing a hotfix

Once the hotfix development / fix is completed, we have to finish the hotfix branch, while finishing a hotfix the updates (commits) from this branch will be merged with develop and master branches and the hotfix branch will be deleted.

In the post Git flow starting a new Hotfix, we saw on how to start a new hotfix using git flow, and in the post “Git flow adding commits to a new Hotfix” we saw on how to add / update changes to the new hotfix. In this post we shall see on how to finish the changes made to the new hotfix.

Git flow adding commits to a new Hotfix

In the post Git flow starting a new Hotfix, we saw on how to start a new hotfix using git flow, in this post we shall see on adding / updating changes to the new hotfix.
In this post I will be adding a new file to an existing hotfix branch. Let me add a new file “Git Hotfix.docx” to the new hotfix branch Hotfix1.

Sunday, December 28, 2014

Git flow starting a new Hotfix

A Hotfix is started when there are bugs / issues in production. Starting a hotfix creates a new hotfix branch from the master branch. The testing and big fixing activities will be carried out in the hotfix branch. Once the code is stable without any issues, the hotfix is finished; this will merge the changes made to the hotfix branch to develop and main branches and delete the hotfix branch.

In this post we shall see on how to create a new release (branch) and start working on the new release. In the post Creating a Git-Flow branching structure usingSource Tree, we have seen on how to setup Git-flow. Once the setup is done you can follow the below steps to create a new release branch.

Git Flow finishing a release

Once the release development / fix is completed, we have to finish the release branch, while finishing a release the updates (commits) from this branch will be merged with develop and master branches and the release branch will be deleted.

In the post Git flow starting a new Release, we saw on how to start a new release using git flow, and in the post Git flow adding commits to a new Release, we saw on how to add / update changes to the new release. In this post we shall see on how to finish the changes made to the new release.

Git flow adding commits to a new Release

In the post Git flow starting a new Release, we saw on how to start a new release using git flow, in this post we shall see on adding / updating changes to the new release.

In this post we will add a new file to an existing release branch. Let me add a new file “Git Release.docx” to the new release branch Release1.

Git flow starting a new Release

A release is started when a feature development is completed and merged with the develop branch, once this is done a new release is created from the develop branch. The testing and big fixing activities will be carried out in the release branch. Once the code is stable without any issues, the release is finished; this will merge the changes made to the release branch to develop and main branches and delete the release branch.

In this post we shall see on how to create a new release (branch) and start working on the new release. In the post Creating a Git-Flow branching structure using Source Tree, we have seen on how to setup Git-flow. Once the setup is done you can follow the below steps to create a new release branch.

Monday, December 22, 2014

Git Flow finishing a release

Once the release development / fix is completed, we have to finish the release branch, while finishing a release the updates (commits) from this branch will be merged with develop and master branches and the release branch will be deleted.

In the post Git flow starting a new Release, we saw on how to start a new release using git flow, and in the post “Git flow adding commits to a new Release” we saw on how to add / update changes to the new release. In this post we shall see on how to finish the changes made to the new release.
         

Git flow adding commits to a new Release

In the post Git flow starting a new Release, we saw on how to start a new release using git flow, in this post we shall see on adding / updating changes to the new release.

In this post I will be adding a new file to an existing release branch. Let me add a new file “Git Release.docx” to the new release branch Release1.

Git flow starting a new Release

A release is started when a feature development is completed and merged with the develop branch, once this is done a new release is created from the develop branch. The testing and big fixing activities will be carried out in the release branch. Once the code is stable without any issues, the release is finished; this will merge the changes made to the release branch to develop and main branches and delete the release branch.

In this post we shall see on how to create a new release (branch) and start working on the new release. In the post Creating a Git-Flow branching structure using Source Tree, we have seen on how to setup Git-flow. Once the setup is done you can follow the below steps to create a new release branch.

Sunday, December 21, 2014

Git Flow finishing a feature

Once the feature development is completed, we have to finish the feature branch, while finishing a feature the updates (commits) from this branch will be merged with develop branch and the feature branch will be deleted.

In the post Git flow starting a new Feature, we saw on how to start a new feature using git flow, and in the post Git flow adding commits to a new Feature we saw on how to add / update changes to the new feature. In this post we shall see on how to finish the changes made to the new feature.

Git flow adding commits to a new Feature

In the post Git flow starting a new Feature, we saw on how to start a new feature using git flow, in this post we shall see on adding / updating changes to the new feature.

In this post I will be adding a new file to an existing feature branch. Let me add a new file “Git Feature.docx” to the new feature branch feature1.

Git flow starting a new Feature

A feature is started when we want to develop a new module to an application, creating a feature creates a new branch from the develop branch, all additions/changes done for the feature will be committed to the feature branch, finally when the feature development is completed, the feature is finished, this will merge the changes (commits) made to the develop branch and delete the feature branch.

In this post we shall see on how to create a new feature (branch) and start working on the new feature. In the post Creating a Git-Flow branching structure usingSource Tree, we have seen on how to setup Git-flow. Once the setup is done you can follow the below steps to create a new feature branch.

Creating a Git-Flow branching structure using Source Tree

Git Flow is an add-on package to Git, which provides a set of commands to create and manage the branches. SourceTree supports Git Flow, it provides as icon in the tool bar to create and manage Git Flow.

Let us create a branch structure proposed by Git-flow for one of the repository, I have a repository called GitDocuments, and there is only one branch origin/master, now let us use Source Tree and create a Git-flow based branching model for this repository.

Git-flow working branches

Git Flow is an add-on package to Git, which provides a set of commands to create and manage the branches. By default Got flow creates the following 2 branches

What is Git Flow

Git flow is a branching model proposed by Vincent Driessen, this model aims in standardizing the branching and merging operations for a project. If there is not fixed model then, every project will have its own set of branched which will not be easy for others to understand, hence it is advisable to go for a standard set of branches to make the version control clean and reusable.

Git flow, abstracts the development team from the underlying Git commands, they can work on the repository using the Git-flow commands instead of directly using the underlying Git commands.

Git flow defines the following the following branches for a repository.

Pull in SourceTree

The pull command in Git/Source Tree is used to get the changes (commits) from remote repository to the local repositories, the changes are fetched and merged with the local working folder.

Pull can be done on a specific branch or on all the branches, by selecting the appropriate option. Use the following steps to pull the latest details (commits) from a remote branch to the local working folder using Source tree.

Fetch in SourceTree

The fetch command in Git/Source Tree is used to get the changes (commits) from remote repository to the local repositories, the local working copy is not affected as a result of executing the Fetch command, this gives an opportunity to get the remote changes and do a comparison with the local version before we merge and commit the local changes.

Fetch can be done on a specific branch or on all the branches, by selecting the appropriate option. Use the following steps to fetch the latest details (commits) from a remote branch to the local branch using Source tree.

Saturday, December 20, 2014

Rebase in SourceTree

In the post Checkout (Create new Branch), we created a new branch and added a new file to the branch. Here we shall rebase this branch back into the main branch.

Unlike merge where the old branch is retained, in rebase the old branch is discarded and all the commits which were made to the branch are moved to the new branch to which the rebase is done. To rebase follow the below steps.

Merging Branches

Merging is another important feature of any version control system. Merging involves joining the changes from 2 branches.

In general a base [master] branch is maintained, when a major change is to be done a branch is created from the master branch, all the changes are done in the branch and tested. Once the version of the code in the branch is certified as stable it will be merged into the main branch.

The current branch will be the target branch of the merge, when you want to merge changes from an iteration branch to the main branch you will have to switch (Checkout) into the main branch and then select the iteration branch which you want to merge with the main branch.

Follow the below steps to perform a branch merge in SourceTree

Checkout (Create new Branch)

Checkout option in Git is used to switch between an existing branch to another, it can also be used to create a new branch and switch to the newly created branch. In the post Checkout in SourceTree (switch branches) we saw on how to use Checkout to switch to an existing branch, here we shall use the Checkout command to create a new branch and switch to the new branch.

To create a new branch and checkout to the new branch follow the below steps.

Tuesday, December 16, 2014

Checkout in SourceTree (switch branches)

In the previous post Creating a new Branch in SourceTree we created a new branch “GitCommands”, we now have 2 branches “master” and “GitCommands” and the [Head] is pointing to the “GitCommands” branch, we will switch from this branch to the “master” branch.

Creating a new Branch in SourceTree

Branching is an important feature of any version control system. Branching concept in Git is quite different from the conventional version control systems. In conventional version control systems’ branching involves creating a physical set of files/documents and storing them as a separate copy for that branch.

In Git branching is done in a different logic, Git basically stores all the changes to the repository in the form of commits, and branching is done just by switching the [head] pointer between the commits.

Let us now create a new branch called GitCommands and add a new file Git Commands.docx to the new branch.

Branch Vs Checkout in Git

Branch and Checkout do the same thing but there is a small difference between the two. This post explains the difference between the operation of the branch and checkout commands in Git.

Deleting a local Repository using SourceTree

There are situations in which you want to totally remove the repository from your local, suppose you have messed up the code in your local copy and want to get rid of the same completely, then you can completely delete the local repository and clone a new copy from the remote repository and start using it.

To delete a local repository use the following steps.

Discarding changes to a file in SourceTree

There are situations in which you have a work in progress code, which you do not want to commit, but want to roll back changes for the previous commit state, Git helps us achieve this using the Discard option.

         When you discard changes in the working / staging area the changes are removed and            the working copy is rolled back to the previous commit state. Discarding changes can be            done as follows.

Monday, December 15, 2014

Stashing changes to a file in SourceTree

There are situations in which you have a work in progress code, which cannot be committed, but you want to work on some other branch for an emergency issue. For example you want to park the work in progress change in your development branch and work on an emergency issue in the production branch, Git helps us achieve this using the Stash option.

When you Stash changes in the working / staging area the changes are stored in a separate copy and the working copy is rolled back to the previous un-modified state. Stashing can be done as follows.

View changes line by line using SourceTree

In the previous post we saw on how to view the history of commits made on a file in SourceTree, this will show the history of commits their date and time, but what if we need a detailed difference report which shows the line by line change history made to the file, SourceTree provides an option Blame which shows the line by line changes made to a file.

To view the changes done to a file author wise use the following steps.

View change history of a file in SourceTree

Any source control system should allow the user to view the change history of a specific file or document which is stored in the source control system; in Source Tree we can view the change history details of an item using the “Log Selected” option.

To view the change histories of a specific file, follow the below steps. 

Pushing local repository changes to remote repository

The Git version control / source control system is slightly different from the conventional systems, in Git to update a change to a remote repository involves the following steps.

1. Add/Modify/Delete the required files in the local working copy.
2. Move the changes to the Stage/Index
3. Commit the changes in the Stage/Index to the local repository
4. Finally push the changes from the local repository to the repository

Before pushing the changes to the remote repository make sure that the changes are staged and committed to the local repository, once this is done we can push the changes to the remote repository by clicking on the “Push” icon in the toolbar as follows.



5.  In the push window make sure that the “push to repository” points to the correct remote repository to which the changes needs to be pushed.
6. Select the correct local and remote branch and click OK
7. The changes will be pushed to the remote repository and a success message appears as follows.


8. That’s it the changes from the local repository, will be moved to the remote repository and the will be visible to other users who are using the same remote repository.


Committing Changes to the local repository

Once we move added / modified files from the local working copy to index, the next step is to move the changes to the local repository, this is done by committing the changes to the local repository. To commit changes in the index to the local repository use the following steps.

SourceTree staging modified files

In the previous post we saw on how to stage new files which were added to the local working copy, in this post we shall see on how to identify files which are modified in the local and stage the changes. To stage the modified files from the local working copy to index follow the below steps.

SourceTree - Adding new Files to Index

Once we move the local changes to stage / Index, next we need to move the changes to the local repository, this is done by committing the changes, to move new files from the local working copy to index follow the below steps.

Saturday, December 13, 2014

SourceTree checking File Difference between Local and Staged

Once we clone the remote repository, we can start making changes to the local working copy, once we are done with all changes in the local working copy, we will make to move the changes to stage before committing and pushing the changes back to the remote repository.

SourceTree will show the file difference between the local working copy and the stage/index copy, SourceTree will show the added/modified/deleted files between the local working copy and the stage/index as follows.

SourceTree Creating a Clone Repository (Working Copy) from the remote Repository.

Before working on a repository, we will have to create a local copy of the repository from the remote repository, this can be done by cloning the remote repository. Cloning will make a full copy of the remote repository in the local machine, changes committed in the local working copy will get applied to the local repository, and later the changes can be merged to the remote repository by pushing the changes from local to remote repository.

In this post we shall see on how to clone a copy of the remote repository to the local machine. Before starting make sure that you install SourceTree in your local machine. Once you have SourceTree follow the below steps to clone the remote repository.

What is SourceTree?

SourceTree is a free UI based tool from Altassian for Git and Mercurial version control system. SourceTree makes it easy to use these version control systems, without having to use the command line instructions.

To know more about SourceTree and to download a free copy of the tool refer to the below Altassian link.

Monday, December 8, 2014

Bitbucket Overview

GitBash Overview

Git Overview

Version Control System Overview

Getting the latest files from the remote repository

Changes made by other users will be pushed to the remote repository, you might want to get the latest version before you start working so that you will not have to merge your changes at a later point in time. Use the following steps to pull latest changes pushed by other users from the remote repository.

Reversing commits made to the local Repository.

Changes are initially made to the local working copy, local changes are moved to index/staging and later committed to the local repository, till this point the changes still remain in the local user pc, and this is the last chance to revoke/rollback any changes before pushing them to the remote repository.

In the post Committing changes to the Local repository we saw on how to commit changes to the local repository, in this post we shall see on how to rollback changes made to the local repository.

Pushing updated files from Local to Remote Repository

In the previous post Pushing local repository changes to remote repository we saw on how to add newly created files in the local copy to remote repository, now we shall see on push updated files from the local working copy to remote repository.

Files which are present in both local and remote repository can be updated to the remote repository, by using the following steps.

Sunday, December 7, 2014

Pushing local repository changes to remote repository

In the previous post Committing changes to the Local repository we saw on how to Stage / Index local changes to the local repository, now we shall see on how to push the changes to the remote repository. The push operation will move the changes from the local repository to the remote repository.

Follow the below steps to push changes from local repository to the remote repository.

Committing changes to the Local repository

In the previous post Adding new Files to Stage/Index we saw on how to add local file to Staging / Index, now we shall see on how to commit the changes to the local repository. The commit operation will move the changes from the staging/index to the local repository.

Follow the below steps to commit changes from Stage/Index to the local repository.

Adding new Files to Stage/Index

In the previous post Cloning Bitbucket Repository using SourceTree we created a repository in Bitbucket and cloned a copy of the repository to the local PC, in this post we shall see on how to add local files from the local machine to Stage / Index.

Follow the below steps to create a new file in the local machine and add them to staging/index.

Cloning Bitbucket Repository using SourceTree

In the previous post Creating a new Repository in Bitbucket, we saw on how to create a new Bitbucket repository, in this post we shall see on how to clone a local copy of the created repository.

Cloning of the repository can be done using commands, SourceTree is a UI editor to access Bitbucket, to clone a local copy of the Bitbucket repository using SourceTree follow the below instructions.

Creating a new Repository in Bitbucket

In the previous post we saw on how to create a free account in Bitbucket, in this post we shall see on how to create a new repository and start using it. Before creating the repository create and account, once you have the account follow the below steps to get started with creating your first Git Repository using Bitbucket.

Creating a free account in Bitbucket

Bitbucket provides free accounts for private repositories. The first step to start using the Bitbucket repository is to create an account in the site https://bitbucket.org/

Follow the below steps to create your free Bitbucket account and repository.

Bitbucket vs GitHub

Both Bitbucket and GitHub are a web-based hosting service for projects using the Git version control system.

GitHub provides free accounts for open source projects, for other types of users it offers free and paid accounts. More details on GitHub can be found on its site
https://github.com/

Both Bitbucket and GitHub provide private repositories, which come with a license fee.
More details on the plans and license fee can be found here.

What is a Bitbucket?

Bitbucket provides web based hosting service for Git and Mercurial version control systems. Bitbucket can be used as the central repository, since it is a web based system, it can be accessed from anywhere.

Distributed teams located in different geographies can use Bitbucket as the central repository and create local repositories at each location. Bitbucket offers both private and public repositories. 

Review commit history using Git log

The $git log command is used to review the commits performed on a repository/branch. The command lists out the various commits performed with details of the date when the commit was done and the user who performed the commit.

The following is the syntax for the log command.

Get status of working folder using git status

The git status command is used to inspect the status of the local working folder and the stage/index, this gives the list of files which are added/modified in the local copy but not reflected in the stage/index.

The following images shows the output of git status command in the following 3 situations.

List out all the branches in the current repository


In the previous post we saw on how to switch to a specific branch using the checkout command, at times we might have more branches in a repository which we cannot remember always, the $git branch command is used to list out all the branches in the current repository.
The following command lists all the branches in the repository.

Checkout a branch using Git Bash

The checkout command is used to switch to a specific branch, also the checkout command gets the latest changes from the specified branch and updates them to the local working folder. Before using the checkout command to switch to a branch, the specific branch should be created using the git branch command.  

The checkout command can be used with the –b switch to create a new branch and switch to that branch in a single command.

Pull changes from a remote repository using Git Bash

The pull command is used to get the latest from the remote repository to the local working copy, the pull command pulls changes committed and pushed by the other users to the local working copy. It is advisable to pull changes before starting to make changes in the local copy this will help to avoid merging changes made by other users later when we want to push our changes to the remote repository.

Use the following steps to pull changes from the remote repository to the local working folder.