In my last post I Suck at Git I mentioned that I’d post some other git-gotchas in the future. I love this workflow, courtesy of Colin, my goto for all things git.
Have you ever made changes to files in an existing git project, committed them, and realized you intended to commit the changes to a different branch?
Here is the scenario. At Ello, we use a simple branching model. You’re probably familar with it.
master is kept clean, ideally only production ready code sees the light of
master. When working on bug fixes or features we create topic or feature branches. A typical flow starts with a fresh pull from master.
Followed by creating a feature branch.
Next, all the code that Makes America Great Again is written, the tests are written, they’re submitted as a pull-request, reviewed, updated, and finally submitted for acceptance testing, approved and merged.
This is the typical flow. It works great. Most of the time.
But what if someone (finger pointed at myself) gets a little ahead of himself and forgets to create a topic/feature branch? What if they write some tremendous code and immediately commit it directly to master?
1 2 3 4 5 6 7 8
After realizing that there are two commits in master that I intended to commit to
sd/feature/make-america-great-again I need to fix things. It turns out that the fix is pretty simple. There are several approaches to the problem but I really like this one.
- create a new branch
- checkout master
git reset HEAD~the requisite number of times
- move on with your life
After executing the offending commits.
1 2 3 4 5 6
Crisis overted. Thats pretty much it. You’re now in the position you inteded to be in the first place. Working on a feature branch, having commited a couple of changes. No harm, no foul.