Demystifying git branches
In this article we will explore how to use git for effective development. Branching is a powerful feature of git and we will explore a few ways of leveraging it to create a development workflow with git
Before we get started, lets review some basic taxonomy to familiarize ourselves
What is a branch?
Branch is a parallel stream of code line where you can make edits. Branches make it easier for multiple collaborators to work in parallel with ease. We will learn more about how we can leverage branches for more efficient development workflow.
What is “master”?
Master is the default branch that comes out of the box with git. You can change this on GitHub.
Git does not have special significance for master and you can always create a different branch and designate it as default.
Development workflow — Take 1 — Making changes directly to master
This is the quickest path to making changes and saving them to a version control system. You start by selecting master branch and syncing your local repository with the origin.
git checkout mastergit fetch && git pull
Once you make edits and save them you will need to stage
git add .
and commit
git commit -m “<commit message>”
You can now push your changes directly to the master branch @origin git push
The biggest disadvantage of this single branch workflow is that there is no way to keep a stable tested branch alive at all times. If you were to publish the software and if there are bugs, it makes working with this approach a little extra messier.
Development workflow — Take 2 — Using branches
We can create additional branches for development while we can designate “master” as the stable branch. There are two ways to use branches for development
- Feature branches: In this approach you create a branch for every feature, enhancement or bug fix and then merge it into master once ready
- Continuous branch: In this approach, instead of creating multiple branches for individual features you have a continuous branch where you add features merge them into master and then continue building new features on the same branch.
Feature branch vs Continuous branch
Feature branch
Every time you are creating a new feature you start with a new branch. So if we are creating a new feature for story buttons we can do something like this
git checkout -b feature_story_button master
# this creates a new branch from masterYou make your edits, save them. When you create commits they are saved to this branch. Lets visualize the steps below.
In order to save these changes in cloud, you will push them to your hosted copy of the code base i.e. your GitHub repository (origin)
git push -u origin feature_story_buttonThis now creates a new branch called “feature_story_button” on your GitHub repository as well. Next you want to review these changes and merge them into master. You do this by creating a pull request (PR) on github.com or using GitHub desktop app. You and your peers can review the PR and then you can merge it into the master branch on github.com
Your changes for the new feature are now available in the master branch. In order to sync changes to your local machine you can run git fetch and git pull.
Note: This example shows one commit on the branch, however you can create multiple stacked commits on the feature branch and then create a PR. In this case when you try to merge on github.com you will have an option to squash all the commits into a single commit when merging the branch into master. This makes is easy for you to split your feature work into smaller commits and then combine them into a single large commit in the master branch
So far we learnt how to use a feature branch to develop and test new code changes and then merge them into master once we have review them using the PR and merge steps.
Since this is a feature branch and you finished developing this feature you can close this branch
git branch -d feature_story_button
# deletes the branch on the local machine. You can also delete the branch on GitHub by running
git push origin --delete feature_story_button or you can do from the GUI on github.com
Your local copy may still show references to the remote branch if you have deleted the branch on GitHub. You can see all the branches referenced by git by running
git fetch and git branch -aIf you see the deleted branch there and you want to remove it, you can run
git remote prune origin --dry-runYou can then run the same command without ーdry-run to clean up references for origin.
Continuous branch
In this case the basic workflow is slightly different from the above workflow. You use branches for your development work and do not push your commits directly into master. However instead of creating a new branch for each feature, you create a generic branch for e.g. “development” and make your changes on top of that. Once you are satisfied with your changes you push them to the development branch @origin and use PR and merge to integrate it back into master.
The main difference arises now — instead of deleting the feature branch like we did above, we will rebase the long running generic branch on master every time after we finish merging it into master and before we start some new work
git rebase master
#OR
git rebase master <branch-name>Once you rebase your branch, all the commits and changes that are already merged in master will automatically be omitted.
