This week’s blog title is not the greatest. This is simply because what I’m really talking about is Git branching strategies or models. However, there is also a very popular branching strategy called the “GitHub flow” and another one named “Git flow”. All of this could lead to some confusion, but hopefully it won’t throw you off!
The GitHub Flow
The Git branching strategy most of you will recognize once its described is the GitHub flow (pdf). There are three steps in this pattern of version control:
- Create a branch and add your commits.
- When finished with a code unit, make a pull request.
- Discuss, and review, then merge.
This is the strategy I use. Well, that is, when I’m not just merging into the master branch 😐. (Also called ‘Centralized workflow’) I mean, when I’m working on my own projects, all by myself, I don’t see much usefulness in branching off. At least not yet. I have used branches when I worked with other people on group projects, but even then we just sort of stumbled through it.
The idea behind the Github flow is simple and elegant. Keep your improvements, changes and bug fixes separate from your “live” code. The way that GitHub describes it is: Your master branch should always be deployable.
Regarding commits, each commit should be a clear and separate unit of work. Every time a parcel of work is finished, commit it, hopefully, you will use a clear and concise commit message (perhaps, even with multi-line commit messages from the CLI) and not just “Did stuff here.”
There are multiple benefit of using pull requests, whether you are using a Fork & Pull Collaborative model or Shared Repository model. Using a pull request with Fork & Pull pings the project maintainers, lets them see your changes, allows you to discuss with them any issues and incorporate code that fits the project scope. Whereas when you are making a PR in a Shared Repository model it starts a code review, which lets you discuss with your team, test and improve, to get everything in order before merging to Master, which would deploy the code.
The Git Flow
The Git Flow is similar to the GitHub flow, except that there are two long-lasting branches, Master and Development. The Master is the deployable, clean and ready to go branch. The Development branch is where new features are implemented, Bug Fix branches are built up before being deployed to Master and Hotfix branches.
Altassian.com does a good job of clearly describing it in their Gitflow Workflow tutorial.
The Forking Workflow
This workflow utilizes a forked repository, which is separate from the repository from which the deployed software is drawn from. Often used in Open Source software, it allows the maintainers to keep their repository pristine. Code changes are made to your own copy of the repository and then a pull request is opened to the original repository.
The main (or “original” or “deployed”) repository is forked (“cloned”) and new code is added to it. After the unit of works have been committed and a pull request has been made, the changes can be reviewed, tested and made ready to be pulled into the main repository. To do that, the latest version of the main repository is retrieved (“pulled”) and any conflicts are resolved, before rebase-ing the forked branches commits onto the tip of the branch and then merging it back into the main repository.
RhodeCode has a succint, clear illustrated summary of the Forking work flow.
The last thing I’ll share is a GitHub video on Continuous Integration and Continuous Delivery/Deployment. Its a general overview of CI/CD that is a bit heavy on technical terms and feels quite a bit over my head.
But, that’s okay, sometimes its good to just pay attention, grasp what you can, let the buzzwords soak into your brain and save it for future learning.
Conclusion
Each of these workflows have intricacies that are beyond my understanding, and as my readers know, I like to share what I learn as I’m learning it. There is a Korean proverb: 개구리 올챙이 적 생각도 못 한다. Which roughly translate to: The frog cannot remember when they were a tadpole.
Likewise, I feel there are insights that can only be shared within the process of moving from inexperience to proficiency, because once we arrive at mastery we oft-times forget what it was like to be a novice.
Until next time, stay positive, radiate it to those around you, and keep learning and growing!
