Branches
Branches are used to commit changes separate from other commits. It is very common to create a branch when you start working on a feature and you are not sure if this feature will be finished in time for the next release.
There are multiple ways to create a new branch. You can right-click on an item in the history window and select Create Branch or select Command -> Create Branch. Deleting a branch is done the same way. In the ‘Create branch’ dialog box there is a checkbox you can check if you want to checkout this branch immediate after the branch is created.
To work in a branch, it has to be checked out. Checking out a branch is done similar to how a branch is made, either by right-clicking or using the the command menu. If you chose to checkout a branch, the next commit will be committed to that branch.
When you delete a branch that is not yet merged, all commits will be lost. When you delete a branch that is already merged with another branch, the merged commits will not be lost because they are also part of another branch. You can delete a branch using ‘Delete branch’ in ‘Commands’ menu. If you want to delete a branch that is not merged into another branch, you need to check the ‘Force delete’ checkbox.
When doing a push, go to the Push multiple branches tab in the Push dialog box and place a check in the Delete Remote Branch column next to the branches you wish to delete.
Merging branches can be easily explained using the following example. We have two branches, Master and SideProject. SideProject is the current checked-out branch. We can merge the commits from the Master branch into the SideProject. If we do this, the SideProject branch will be up to date with the Master branch, but not the other way around.
As long as we are working on the SideProject branch we cannot touch the Master branch itself. We can merge the sources of Master into our branch, but cannot make any change to the Master branch. To change the Master, we would have to check out the Master branch.
The rebase command is the most complex command in Git. The rebase command is very similar to the merge command. Both rebase and merge are used to get a branch up-to-date. The main difference is that rebase can be used to keep the history linear contrary to merges.
Why is a rebase helpful? One of the most common use cases is that you’ve been working on your own features in separate branches. Instead of creating ugly merge commits for every change that is brought back into the master branch, you could create one big commit and let rebase handle attaching it. Another frequent use of rebase is to pull in changes from a project and keep your own modifications in line. Usually by doing merges, you’ll end up with a history in which commits are interleaved between upstream and your own. Doing a rebase prevents this and keeps the order in a more sane state.
A rebase of Refactor on top of master will perform the following actions:
• All commits specific to the Refactor branch will be stashed in a temporary location
• The branch Refactor will be removed
• The branch Refactor will be recreated on the master branch
• All commits will be recommitted in the new Refactor branch
During a rebase merge conflicts can occur. You need to solve the merge conflicts for each commit that is rebased.
Because this function rewrites history you should only use this on branches that are not published to other repositories yet. When you rebase a branch that is already pushed it will be harder to pull or push to that remote. If you want to get a branch up-to-date that is already published you should merge. Also don't rebase branches that others have created new commits on top of. It is possible to recover from that, it's not hard, but the extra work needed can be frustrating.
Below is an example of how the History would look before and after a rebase.
Before
After
To better understand rebasing, read:
http://eagain.net/articles/git-for-computer-scientists/
http://gitready.com/intermediate/2009/01/31/intro-to-rebase.html