Working with Branches in Git

Git branches are a great way to separate things in development that are not immediately connected to each other, e.g., your tasks from the sprint backlog. Branches allow you to work on several things in parallel without mixing them up. This is especially useful in the case of pull requests that are not immediately merged because there are still issues to discuss and/or changed. Instead of being blocked until your pull request is resolved, you can just continue working on another task in a separate branch. Additionally, possibly unrelated future commits of yours are not added to your latest pending pull request. This makes things much easier for the people checking/merging your pull request. In the following, we present the most common Git commands for working with branches.

To create a new feature branch and switch to it, use the following while being on your master branch (use git status to see on which branch you currently are):

• git checkout -b myBranch

You can then continue working and committing stuff as usual. If you push your commits to your remote GitHub repository, a new branch will be created there, too. As a quick reminder, you can push a branch or its local commits like this:

• git push origin HEAD

We have changed the Jenkins configuration so that now all branches are included in the automatic test runs. Branches in the GitHub repository can be accessed from the web frontend and you can (and should!) also create pull request from them to the META-SHARE master.

If you want to stay up-to-date with the development in the master branch, you first switch to your master branch using

• git checkout master

and then update it as usual using

• git pull upstream master

To make the latest updates in master available in your feature branch, too, e.g., because you want to test if your new feature is working with the latest version, you switch back to your feature branch and then merge the master branch into it using

• git checkout myBranch (for making your feature branch the current branch, i.e., switching to it)
• git merge master (for merging all updates from master to the current branch)

If you issued a pull request for your feature branch and it turns out that there are still things to be changed, you can just continue working on the feature branch and add more commits to it that will then automatically be included in your open pull request when you push the new commits to your origin repository again.

If your pull request is finally merged, the feature branch becomes obsolete. You can delete the local branch using

• git branch -d myBranch

Be aware that this does not delete the branch in the GitHub remote repository. This can be done using

• git push origin --delete myBranch

Finally, your new feature will be available in your master branch after another

• git pull upstream master

Please note that you are not restricted to a single feature branch. You can create as many branches as you like! This comes in handy when you are developing on one feature but discover a bug along the way on some unrelated piece of code. Then you can just create a new branch (based on master!), fix the bug there and eventually create a pull request for the bug fix. After this little bug fixing interlude you can continue working on your first feature branch.

For more details please check this great article.

If you have any more questions about branches, please ask Christian Spurk or Jörg Steffen.