How to Git Well

Throw a rock in any general direction, and you will hit yet another Git workflow. This one is mine, based on working with Git for 10+ 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 that it's nothing more than 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 set up 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: 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 do a git push and it will already know where to push to. Same with git pull.
5. DO YOUR WORK
   • Commit early and often. I recommend committing every time you get something to 'done' or at least working, but make a WIP (work in progress) commit anytime you need to switch tasks or want a waypoint for what you’re working on.
6. Make a 'final' commit, if you haven’t already.
7. Rebase your feature onto the current version of master (this reduces merge conflicts)
   • git rebase origin/master
   • git rebase -i origin/master if you want to get fancy and pick and choose commits interactively
8. Fix any merge conflicts, if any.
   • FIX, FIX some more, FIX again
   • git add . or git add /file(s)/that/were/changed
   • git rebase -–continue
9. 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
10. 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
11. Rest, reflect on what you have accomplished, and then start over again from step 4.

Here is what the cycle looks like:

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 there is a merge of a significant amount 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 fewer surprises you will have to deal with 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).