Chapter 3. Git Branching

1.   Branching means you diverge from the main line of development and continue to do work without messing with that main line.

 

 

2.  When you commit in Git, Git stores a commit object that contains a pointer to the snapshot of the content you staged, the author and message metadata, and zero or more pointers to the commit or commits that were the direct parents of this commit: zero parents for the first commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.

 

3.  Staging the files checksums each one (the SHA-1), stores that version of the file in the Git repository (Git refers to them as blobs ), and adds that checksum to the staging area. When you create the commit, Git checksums each subdirectory and stores those tree objects in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.

 

4.  If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it.

 

5.  A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master . As you initially make commits, you're given a master branch that points to the last commit you made. Every time you commit, it moves forward automatically.

 

6.   git branch [branch-name] command creates a new pointer at the same commit you're currently on.

 

7.  Git keeps a special pointer called HEAD which is a pointer to the local branch you're currently on.

 

8.   To switch to an existing branch, you run the git checkout command:

$ git checkout testing

This moves HEAD to point to the testing branch:

What is the significance of that? Well, do another commit and you will see:

 

9.  git checkout command did two things: it moved the HEAD pointer back to point to the target branch, and it reverted the files in your working directory back to the snapshot that the target branch points to. Note that if your working directory or staging area has uncommitted changes that conflict with the branch you're checking out, Git won't let you switch branches.

 

10.   A branch in Git is in actuality a simple file that contains the 40-character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Developers are encouraged to create and use branches often.

 

11.  To create a branch and switch to it at the same time, you can run the git checkout command with the -b switch:

$ git checkout -b iss53

 

12.  If you want to merge hotfix branch back into your master branch, you can do this:

$ git checkout master

$ git merge hotfix

 

13.  When you try to merge one commit with a commit that can be reached by following the first commit's history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together—this is called a fast forward.

 

14.  To delete a branch, you can delete it with the -d option to git branch :

$ git branch -d hotfix

 

15.  If the commit on the branch you're on isn't a direct ancestor of the branch you're merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two.

Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it. This is referred to as a merge commit and is special in that it has more than one parent.

 

16.  If you changed the same part of the same file differently in the two branches you're merging together, Git won’t automatically created a new merge commit. It has paused the process while you resolve the conflict. To see which files are unmerged at any point after a merge conflict, you can run git status . Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts.

 

17.   Your conflict file contains a section that looks something like this:

<<<<<<< HEAD:index.html

<div id="footer">contact : [e-mail]</div>

=======

<div id="footer">

  please contact us at [e-mail]

</div>

>>>>>>> iss53: index, html

This means the version in HEAD is the top part of that block (everything above the ======= ), whereas the version in your iss53   branch looks like everything in the bottom part.

 

18.  After you've resolved each of these sections in each conflicted file, run git add on each file to mark it as resolved. Staging the file marks it as resolved in Git.

 

19.  To use a graphical tool to resolve these issues, you can run git mergetool . You will see all the supported tools listed at the top after "merge tool candidates ". Type the name of the tool you'd rather use. After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you. After you verify that everything that had conflicts has been staged, you can type git commit   to finalize the merge commit.

 

20.  I f you run git branch with no arguments, you get a simple listing of your current branches. The * character that prefixes the branch indicates the branch that you currently have checked out. To see the last commit on each branch, you can run git branch –v .

 

21.   To see which branches are already merged into the branch you're on, you can run git branch –merged . To see all the branches that contain work you haven't yet merged in, you can run git branch --no-merged . Because it contains work that isn't merged in yet, trying to delete it with git branch -d will fail, however you can force it with –D .

 

22.   Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their master   branch—possibly only code that has been or will be released. They have another parallel branch named develop or next that they work from or use to test stability—it isn't necessarily always stable, but whenever it gets to a stable state, it can be merged into master . It's used to pull in topic branches (short-lived branches for hox-fix and new feature) when they're ready, to make sure they pass all the tests and don't introduce bugs.

 

23.  Remote branches are references to the state of branches on your remote repositories. They're local branches that you can't move; they're moved automatically whenever you do any network communication. Remote branches act as bookmarks to remind you where the branches on your remote repositories were the last time you connected to them. They take the form (remote)/(branch) : origin/master

 

24.  If you clone from a remote git repoitory, Git automatically names it origin   for you, pulls down all its data, creates a pointer to where its master branch is, and names it origin/master locally; and you can't move it. Git also gives you your own master branch starting at the same place as origin's master branch:

 

25.  When you run a git fetch origin command. This command looks up which server origin is, fetches any data from it that you don't yet have, and updates your local database, moving your origin/master   pointer to its new, more up-to-date position:

 

26.  If you have a branch named serverfix that you want to work on with others, you can push it up the same way you pushed your first branch. Run:

Git push origin serverfix

 

27.  This is a bit of a shortcut. Git automatically expands the serverfix branch name out to refs/heads/serverfix:refs/heads/serverfix , which means, "Take my serverfix local branch and push it to update the remote's serverfix branch." You can also do git push origin serverfix:awesomebranch if you don't want it to be called serverfix on the remote. When you do a fetch that brings down new remote branches, you don't automatically have local, editable copies of them. If you want your own serverfix branch that you can work on, you can base it off your remote branch:

$ git checkout -b serverfix origin/serverfix

This gives you a local branch that you can work on that starts where origin/serverfix is.

 

28.  Checking out a local branch from a remote branch automatically creates what is called a tracking branch. Tracking branches are local branches that have a direct relationship to a remote branch. If you're on a tracking branch and type git push , Git automatically knows which server and branch to push to. Also, running git pull   while on one of these branches fetches all the remote references and then automatically merges in the corresponding remote branch.

 

29.  When you clone a repository, it generally automatically creates a master branch that tracks origin/master . That's why git push and git pull   work out of the box with no other arguments.

 

30.  You can set up other tracking branches if you wish—ones that don't track branches on origin and don't track the master   branch by:

git checkout -b [ branch] [ remotename]/[ branch]

You can also use --track shorthand for Git version 1.6.2 or later:

$ git checkout --track origin/serverfix

 

31.  You can delete a remote branch using the rather obtuse syntax:

$ git push [remotename] :[branch]

     A way to remember this command is by recalling the git push [remotename] [localbranch]:[remotebranch] syntax. If you leave off the [localbranch] portion, then you're basically saying, "Take nothing on my side and make it be [remotebranch] ."

 

32.  In Git, there are two main ways to integrate changes from one branch into another: the merge and the rebase .

 

33.  With the rebase   command, you can take all the changes that were committed on one branch and replay them on another one.

Before rebase:

Then you run:

$ git checkout experiment

$ git rebase master

After rebase:

At this point, you can go back to the master branch and do a fast-forward merge.

 

34.  rebase works by going to the common ancestor of the two branches (the one you're on and the one you're rebasing onto), getting the diff introduced by each commit of the branch you're on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.

 

35.  The snapshot pointed to by the final commit you end up with, whether it's the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot—it's the history that is different. Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.

 

36.  If you have following branches:

You can take the changes on client that aren't on server (C8 and C9) and replay them on your master branch by using the --onto option of git rebase:

$ git rebase --onto master server client

This basically says, "Check out the client   branch, figure out the patches from the common ancestor of the client   and server   branches, and then replay them onto master .":

 

You can rebase the server branch onto the master   branch without having to check it out first by running git rebase [basebranch] [topicbranch] —which checks out the topic branch (server ) for you and replays it onto the base branch (master ).

 

37.   Do not rebase commits that you have pushed to a public repository. When you rebase stuff, you're abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with git rebase   and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.