Bulletproof Git Workflow is a small four-step guide. It is part of my series of Bulletproof Workflow guides. It contains a set of constraints that will keep your team in a safe area of Git.
If you're working in a team, you'll need to agree on a few things regardless of your opinion. It doesn't mean your opinion doesn't count. It doesn't mean you're wrong.
However, for the good of the business, the team, the products, the projects, and the future people that will replace you, make things work by compromising and respecting. As a result, your Git workflow will be more predictable, cleaner and more manageable when you have to resolve conflicts.
This simple guide has been refined over ten years and proven to keep git workflow very simple and manageable through many teams as they evolved with personnel changes. And as it says in the guide, there may be other git workflows - faster, more relaxed, fancier or more efficient - however, this way has proven safe and reliable.
Dear New Coding Colleague,
If you're working in a team, you'll need to agree on a few things, regardless of your opinion. It doesn't mean your opinion doesn't count. It doesn't mean you're wrong. However, for the good of the business, the interest of the products, the interest of the projects, the appeal of your team and the good of the future people that will replace you when you move on make things work by compromising and respecting.
One of the things you are required to agree on in our team is a git workflow. If you're an expert, we agree you're more than capable of doing your own thing. If you're not an expert, you can also do your own something. However, there's nothing worse than someone asking for your help with a git conflict or rebase mess, and you don't know what's what and how you got there. Or looking at a git log to get up to speed on recent changes, and it is an inconsistent stream of meaningless messaging.
Agree to use your clearest workflow, and many things will improve.
Sure, there might be more straightforward, faster, wiser or more fancy ways to get things done, but this continues to prove to teams that it works.
Thanks for your cooperation.
Love from your Coding Team.
1. Do Work
mkdir my-project && cd "$_" git checkout main git pull git checkout -b feature/my-work # do some work, edit your files git add changed-file-a.js git commit -m 'added my work'
2. Do More Work
git add changed-file-b.js git commit -m 'fixed the broken thing' git add changed-file-c.js git commit -m 'made the thing better'
3. Tidy up
Tidy up your commits by interactively (-i) rebasing your branch.
During the rebase you will reword the top commit and fix up other commits as appropriate.
(<n> is the number of commits to return - you know how many commits you've done, right? If not, git log)
git rebase -i HEAD~<n> # eg. git rebase -i HEAD~3
Get the latest from the primary.
git checkout main git pull
Rebase your Work on the latest main.
git checkout feature/my-work git rebase -i main
Resolve conflicts and:
git add my/resolved/file.js
git rebase --continue
If you get stuck:
git rebase --abort
To try again, or phone a friend, don't phone a friend until you've done this.
Bonus #1 - Code Review
Share your branch on the remote, go to Github/Gitlab, and create your pull request.
git push origin feature/my-work
Bonus #2 - Review Feedback
Use all previous workflows to apply updates to your branch from feedback in the pull request.
As you've already pushed your branch to the remote and re-tidied up, you must force-push a newly rebased & modified history to the remote.
Force pushing is dangerous as it will completely replace the remote copy of your branch with your local copy of your unit. If others have pushed to your remote branch, their commits will be lost. Before force-pushing, fetch and rebase your remote to collect any updates, just in case. As an added measure of protection, use the
--force-with-lease option, which makes sure the remote is in the expected state.
git pull --rebase origin feature/my-work git push --force-with-lease origin feature/my-work
That's it. Use the merge button in the pull request to merge to the main, squash and rename commits as necessary, and delete the feature branch.