Using branches in Git

Why and how branches are used in Git

Preface:

Version control systems like Git help manage changes to files. Sometimes, you’ll want (or need) to make some ‘feature’ or ‘patches’ to a collaborative research project. Or maybe you want to make some experimental changes to your code, but don’t want to touch your main code. This, and more, is where branches come into play.

In this code-along we’ll go over what branches are, and how and why you would use them.

Pre-requisites:

What are Git branches

In very simple terms, git branches are individual projects within a git repository. Different branches within a repository can have completely different files and folders, or it could have everything the same except for some lines of code in a file.

Let’s use a few real world examples (at least that I’ve used before, others may have used them differently):

There are many uses of branches in Git. The nice (and very powerful) thing about Git is the fact that branches are very cheap compared to other version control systems. By cheap, I mean they don’t take up much disk space, it’s computationally easy to move between branches, and it’s (relatively) easy to merge branches together. This is because of how Git represents branches, since they are simply pointers or an individual commit. That’s it. Just a pointer… Git commit history is a directed acyclic graph, which means that every single commit always has a ‘parent’ commit (the previous commit in the history, or multiple parents when a merge happens), and any individual commit can have multiple ‘children’. This history can be traced back through the ‘lineage’ or ‘ancestry’. The branch just gives a name to each ‘lineage’ when a commit has multiple children.

When you merge two branches together, the commit histories get merged together as well. Which means that all the changes you made in each branch gets combined back into a single lineage, rather than two. This makes it easier to work collaboratively on a project, since each individual could work on their own branches, without dealing with the messiness that could come from working all on one branch.

Commands used with branches

Branches are best understood visually. So let’s first start with using this website to see what the branch, checkout, and merge commands are doing.

After we’ve tried that, let’s do it locally (on your own computer). Here is a sequence of commands to try out:

cd ~/Desktop
mkdir git-branches
cd git-branches
git init # start a repo
git add .
git commit -m "First commit" # make the first commit
git branch testBranch # create branch
git checkout testBranch # move to branch
## can also do git checkout -b testBranch
echo "Some text" > file.txt 
git add file.txt
git commit -m "Added a file with text"
git checkout master
echo "Text in another file" > new-file.txt
git add new-file.txt
git commit -m "Added another file"
git log --graph --oneline --decorate --all
# This command is long, so shorten it using aliases
git config --global alias.lg 'log --graph --oneline --decorate --all'
git merge testBranch
git lg
git branch -d testBranch # delete the branch

Using branches for pull requests

I mentioned this already, but branches are best used when doing a pull request (unless the pull request is very small or few people work on the repository).

The steps to take would be:

  1. Fork a repository on GitHub
  2. Clone it onto your computer
  3. Make a branch and move to it: git checkout -b fixingBranch
  4. Make changes to the files
  5. Commit the changes to the history
  6. Push the branch up to your forked version: git push origin fixingBranch
  7. On GitHub, submit a Pull Request of your fixingBranch
  8. Once the pull request is merged, delete the fixingBranch on your forked repo on GitHub and on your computer (git checkout master && git pull upstream master && git branch -d fixingBranch)

Resources:

If you have any questions, often one of the best places to start is either
StackOverflow or Google (which more likely links to StackOverflow).

Glossary: