Git Workflow easily solved in 4 simple steps

Bulletproof Git Workflow is a small 4 step guide. This small Git workflow guide is a set of constraints that keeps you in a safe working area of Git.

bulletproof git workflow banner image

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 just 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, 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 easier when you have to resolve conflicts.

This simple guide has been refined over 10 years and proven to keep git workflow very simple and manageable through many teams as they evolved over time with personnel changes. And as it says in the guide, there may be other git workflows - faster, cooler, fancier or more efficient - however this way has proven to be safe and reliable.

The Agreement

Dear New Coding Colleague,

Look, if you're working in a team, you'll just 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 good of the products, the good of the projects, the good 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, fine, and we agree you're more than capable to go ahead and do you own thing. If you're not an expert, you can also go ahead and do your own thing. However, there's nothing worse that 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.

Simply agree to use the clearest workflow you can, and many things will be better.

Sure there might be simpler, faster, smarter or more fancy ways to get things done, but this way 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 master
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 fixup other commits as appropriate.

(<n> is the number of commits to go back - you know how many commits you've done right? If not, git log)

git rebase -i HEAD~<n>
# eg. git rebase -i HEAD~3

4. Sync

Get latest from master.

git checkout master
git pull

Rebase your work on latest master.

git checkout feature/my-work
git rebase -i master

Resolve conflicts and:

git add my/resolved/file.js

...

git rebase --continue

...until done.

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 and go to Github/Gitlab and create your pull request.

git push origin feature/my-work

Bonus #2 - Review Feedback

Use all of the previous workflow to apply updates to your branch from feedback in the pull request.

As you've already pushed your branch to the remote, and you've re-tidied up, you will need to 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 branch. This means that if others have pushed to your remote branch, their commits will be lost. Before force-pushing, fetch and rebase on 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

Done

That's it. Use the merge button in the pull request to merge to master, squash and rename commits as necessary, and delete the feature branch.