If you’re moving from another source control management (SCM) system to Git, you will need to develop some operating procedures and make sure everyone on the team buys into those procedures.
Why? Git is a different type of SCM tool and its concepts are somewhat different than most SCMs. Git’s concept of “origin” repository with the use of “local” repository takes getting used to over a traditional SCM’s concept of the main repository. And Git promotes using the Master / Branch relationship differently than most SCMs.
Example: In Subversion the main code tree is in Trunk. I’ve seen companies do all their work within Trunk. Multiple developers submitting changes to Trunk, and when release time comes, a freeze on check-ins is enforced. Once the release is built and tagged, only then are developers permitted to continue working. What a waste of time!
Some companies will not do the tag, but copy release Trunk over to a branch. To see what is in production you have to locate the correct branch.
Other companies will work strictly out of branches. They create a branch off what they believe is the most recent release code base (trunk or a branch) and at some point “might” merge release work back into Trunk.
With Git, the direction is that all releases are out of Master (aka: Trunk). Branches are where the work happens. Branches get merged back into the Master for release builds. And Master is tagged for those release builds.
Keeping release code within Master and separating out current work into Branches helps to make logical breaks in features and dependencies. And you will not block your developers from checking in code.
With that in mind, here is a short list to get you started with your team’s Git procedures:1. Production releases come from Master
2. Tag Release builds
3. Work out of a Branch, never Master
4. Create a Branch for fixes
5. Never merge your own work into Master
6. Commit work to your Branch daily
7. A Branch should represent a Sprint / Unit of work / Deliverable
1. Production releases come from Master
In the grand scheme of things you need one source of truth and it should be Master.
Using Subversion I’ve seen clients make release pushes from branches, and then down the road there are 20 different branches and no one can remember which one is the one in production.
Remember: Master equals Release!
2. Tag Production builds
This moves along with the first step, if you tag your release then you can always go back to that version. If a bug comes up, go to the last tag (which should be the last one in production), branch it, duplicate the issue, then do a fix.
3. Work out of a Branch, never Master
Working out of a branch allows you to review your code changes and ensures you will not step on a teammates code.
But, “never say never”.
If you just started the project and it is not in production, then fine, work out of Master. But the earlier you get into a habit of working from a branch, the better off you will be.
4. Create a Branch for fixes
When fixing code that originated in your branch, if that code has been merged into Master, create a new branch for the fixes.
The scenario: you’ve created a Branch (say for a sprint) and after exhaustive testing you’ve had it merged into Master. Prior to a release build a bug is discovered. Oops! (More likely the PM has come up with a “minor” addition). Do not be tempted to update your original branch. Create a new branch. This will enable you to easily view your coding changes.
5. Never merge your own work into Master
Let someone else merge your changes into Master. Part of quality control is to ensure your code is solid, matches the standards and more importantly that “you got it right”. A second set of eyes is always helpful. By having someone else merge your code changes, you get someone else to review your code, to ensure you have all the loopholes covered.
Side note: There should be a couple of Lead Engineers or Owners that are assigned to a repository. Their main tasks would be to review all merge requests and give “constructive” feedback on the code. These code reviews should be constructive, not snippy. If the code works, great, if there are issues, bring them out in a professional/constructive manner. If you have a real beef with the direction of the code or logic, etc., then talk directly to the developer.
6. Commit work to your Branch daily
Part of continuous integration is to have automatic jobs to execute tests against your project, to ensure it still works. To get the best bang for your buck, check in small changes, ensuring you did not break something.
Also, if your working within a team, doing the incremental check-ins to the branch will ensure you are not stepping on each other’s code, or if you are, will identify it earlier.
7. A Branch should represent a Sprint / Unit of work / Deliverable
If you’re attempting to figure out what should be in a branch, the branch should represent a sprint or deliverable. Each team member should then create a branch off of that deliverable branch.
When a team member completes their work, their branch code should be merged into the deliverable branch.
Once that Sprint/Deliverable is completed, tested and ready for production, only then should it be merged into Master.
Conclusion
Git is a powerful tool to manage your code. But with great power comes great responsibility: plan out how you will use the tool, then get everyone on board and working in the same direction. This will alleviate future pain points (such as: what is in production and who put it there).
For additional information on Git and Git workflows, here are some good sources:
