My One-Way Git Workflow (or, How to Git Well)

by Andrew

There are a lot of git workflows out there. This is mine, based on working with Git for 10-something years now. It makes use of git rebase, so turn away now if you’re scared of rebasing (and then go read this and realize it’s just another tool). BONUS: be sure to check out my handy git helpers too!

  1. Find your ‘origin’ repo
  2. Fork the origin repo to create your own repo
    • If using Bitbucket, it will automatically setup your repo to ‘sync’ with ‘origin’ unless you uncheck ‘keep in sync’
  3. Clone your fork to your local machine, where ‘origin’ will refer to your fork.
  4. Create a feature branch off of your local master
    • git checkout –b feature-branch-name replacing “feature-branch-name” with whatever name you want to give your branch
    • Good practice: make your branch names unique and specific to the task or feature you’re working on. “branch-1” is not a useful branch name, “time-travel-feature” is better, “adding-unlimited-undo-in-cms” is best.
    • Optional: immediately push the new, empty feature branch to your fork’s remote endpoint using git push –u origin feature-branch-name. This sets up ‘tracking’ so that every time you push going forward you don’t have to specify where, you just do git push and it will already know where to push to. Same with git pull.
    • Commit early and often. I recommend committing every time you get something to ‘done’ or at least working, but WIP (work in progress) commits are recommended anytime you need to switch tasks or just want a waypoint for what you’re working on.
  6. Make a ‘final’ commit, if you haven’t already.
  7. Switch to your local master branch and pull down the latest changes to it.
    • git checkout master
    • git pull
  8. Switch back to your feature branch and rebase it onto the latest master.
    • git checkout feature-branch-name
    • git rebase master
  9. Fix any merge conflicts, if any.
    • git add . or git add /file(s)/that/were/changed
    • git rebase –continue
  10. Having resolved any conflicts, push up your feature branch again, forcing your remote to overwrite whatever is already there (because rebasing will change the branch’s history and thus change its SHA checksum).
    • git push –f
  11. Create a pull request from your feature branch back up to the original ‘origin’ repo’s master branch.
    • i.e. fork/feature-branch-name -> origin/master
  12. Rest, reflect on what you have accomplished, and then start over again from step 4.

The cycle can be illustrated like this:

OriginMaster -> ForkMaster -> LocalMaster -> LocalFeatureBranch -> ForkFeatureBranch -> OriginMaster

Bitbucket will auto-sync OriginMaster and your ForkMaster if you’re using Bitbucket. Then you have to pull down any updates from ForkMaster to your LocalMaster. Then, you switch to your LocalFeatureBranch and rebase it onto the latest changes in LocalMaster. Then you push up to ForkFeatureBranch, where you create a Pull Request from there to the OriginMaster, and the cycle starts over again.

Good practice: any time you hear that a significant amount of new work has been merged into the ‘origin’ repo’s master branch, it’s a good idea to update your local master and rebase your feature branch. The more you keep your feature branch up-to-date with the latest changes, the easier merge conflicts will be to solve, and the less new stuff you’ll be surprised by as you work.

If you haven’t checked it out yet, go here for my handy git helpers that make this workflow super easy, fast, and intuitive (from the command line).