git: merge a single commit
Posted by Wes in 
Sometimes, you have one commit you want to get into production, but it’s located after other changes that you’re not ready to merge in yet. How can you get that single git commit into a different branch?
First, you have to know the SHA of the commit you want:
git checkout branch-with-commit-on-it git log
Highlight and copy the SHA of the commit you want to grab.
git checkout master # -n => don't commit, just merge changes so we can review and commit ourself git cherry-pick -n [The commit’s SHA-1 Hash] # review git diff –cached # commit if all is well git commit -a -m “merge SHA1 ..."
If you’re feeling confident, you can skip the -n and merge the single commit in directly and save a minute.
Note, this isn’t a merge, so it’s possible you could have some conflicts down the road when you merge the original commit into this branch. You’re creating a brand new commit object.
Git: Commit Early, Commit Often
Don’t Be Afraid of Commitment
The phrase “save early, save often” was a mantra of early computer science. It’s good advice, but it’s only half the story. If you’ve ever sat down for a fast and furious coding session only to realize hours later that you removed something important, you know the frustration of not being able to get it back. It can mean hours lost.
Getting in the habit of regular commits has a number of benefits. First, you can go back to any previously committed version if your coding goes off-track. You can reference earlier parts of your work even if you don’t need to revert to them. Best of all, it an actually have a positive impact on your code itself.
Better Code through Committing
Just as Test-Driven Development influences us to write a larger number of shorter/simpler methods, frequent committing pushes us to think of atomic changes. Atomic in this context means the smallest possible self-sufficient change. Consider this snippet from git log:
commit b0e77532b5a8cf236d95f1b3324aabc194568c60 Author: Wally Date: Tue Feb 29 23:58:05 2011 -0600 added comments to blog posts
This is an example of a commit done at the end of a feature. Lots of code has probably gone into this, and if you wanted to see any of the steps along the way, you’re out of luck. It’s also not very easy to see what was changed in the app.
An Example of Frequent Commits
Now look at this version:
commit e8bba8ad1a4b5c1353c328b505bfa2a9f4816d07 Author: Alice Date: Tue Feb 29 14:58:05 2011 -0600 added edit/delete links to each comment if user has permissions commit 8bba8ad1a4b5c1353c328b505bfa2a9f4816d07e Author: Alice Date: Tue Feb 29 13:58:05 2011 -0600 allowed admins to edit/update/delete any comments commit bba8ad1a4b5c1353c328b505bfa2a9f4816d07e8 Author: Alice Date: Tue Feb 29 11:58:05 2011 -0600 restricted edit/update/delete actions to user's own comments commit ba8ad1a4b5c1353c328b505bfa2a9f4816d07e8b Author: Alice Date: Tue Feb 29 11:36:20 2011 -0600 created controller/views commit a8ad1a4b5c1353c328b505bfa2a9f4816d07e8bb Author: Alice Date: Tue Feb 29 10:03:31 2011 -0600 made comments nestable in the model commit 8ad1a4b5c1353c328b505bfa2a9f4816d07e8bba Author: Alice Date: Tue Feb 29 9:39:24 2011 -0600 defined activerecord associations among users, posts, and comments commit ad1a4b5c1353c328b505bfa2a9f4816d07e8bba8 Author: Alice Date: Tue Feb 29 08:38:01 2011 -0600 added base comment model and migrations
You can clearly see the evolution of this feature, and it makes sense. Not only can you step back (if user permissions were implemented incorrectly, for instance) but Alice was “forced” to think about each logical step of her development process, instead of jumping in head first. It’s engineering 101 – break a problem in its atomic elements, and attack each of those.
Incidentally, this can also help explain to coworkers, bosses, and clients why a seemingly simple task took longer than expected. As you squirm and attempt to justify what you know is an elegant solution, you might not remember all the steps that got you there.
Git remembers.
Git Branching After the Fact
We have a pretty simple Git work flow here at Databasically: Just work in master. There are a couple reasons for this: we’re not a large team, and we have a very rapid (i.e. daily) release cycle. I had been used to creating branches for every new feature, so when I found out we primarily work on the “master” branch, I was a bit shocked.
I know what you’re thinking, “But what if you go down a path and realize you need to branch in order to put in a ‘hotfix’, or you find out the story is more involved than initially thought?”: you just create a branch after the fact. Here’s how to do it in just a few easy steps:
Step 1: Know where you are and where you want to go
The first thing you need to know is where you are and where you want to go.
In the case (completely contrived example) above, I need to add a fix to what is in production (SHA: fa87cd9). So I want to roll everything back and start working from that hash point.
Step 2: Create a new branch
Now that we know where we want to go, we need to first create a new branch. We create a branch in order to force Git to remember our current line of work. In some ways, you can think of Git branches as inodes in Unix/Linux: as long as a file descriptor [branch] is pointing to an inode, it can’t be fully deleted [reset]. To do this, we’re just going to issue the “git branch <branch name>” command.
I should note that before you do this, make sure you’re clean. “Add” and “commit”, or “stash”, what you’re currently working on.
So here, I created the branch “hotfix” and you can see that HEAD, master, and hotfix are all pointing to the same SHA. You can make sure your branch exists, by issuing the “git branch” command. Now, we can make our changes in master and push to production.
Step 3: There is No … step 3
This means you, Bruce.
Step 4: Reset Master
Now that we have a branch (created in step 2) we’ll reset HEAD to our chosen hash. We do that using git’s “reset” command:
git reset --hard fa87cd9
The log will look something like this:
After making our change and committing, our log looks like this:
Now we can push that into production and get back to what we were working on.
Step 5: Rebase and Merge
Step 5a: Rebase Master
In order to get back to what we were working on, we need to first rebase the changes we made in master into production. To do that, first checkout hotfix and run git rebase master
git checkout hotfix git rebase master
By rebasing master, we replay those changes made in master onto our “hotfix” branch. Our hotfix branch should now look like this:
Notice where HEAD and hotfix are, and notice also where master is. It is now safe to merge everything back to master – and without leaving those unsightly branch paths.
Step 5b: Merge
First things first: check out master. Next: merge hotfix
git checkout master git merge hotfix
You output will look something like this:
And your log will look like this:
And everything is caught up. At this point you can delete the hotfix branch:
git branch -d hotfix
Conclusion
This model works well for us, but I’m sure as we grow we’ll likely have to adopt more involved models such as the “A successful Git branching model” used by nvie.com. As we grow and modify our processes, we’ll be sure to let you know what we find to work and what we find which doesn’t.
Further Reading
Notes:
In this post, I have been calling “git log” with my alias “git lol” here is the details of the alias:
log --graph --decorate --date=local --pretty=format:'%h %cd (%an) %s%d'
git: pull is not possible because you have unmerged files.
I saw this error message the other day and I had no clue what it meant. I’d never seen that error before!
For reference, I was trying to pull from a remote branch and got the error message:
Pull is not possible because you have unmerged files.
A google search revealed this commit (d38a30df7dd54c5c6883) to the git source on January 12, 2010.
The error messages have been updated to be much clearer. Before, you’d get “needs merge” or “error building trees” errors, which didn’t really mean much.
In this case, I was pulling in many commits and had a conflict partway through. I just needed to resolve the files, add/delete them, commit the result and then continue with the pull.
“warning: updating the current branch” when pushing to a git repository
I pushed some changes after updating git on my server to git 1.6+ and now I get this:
$ git push origin master ... warning: updating the current branch warning: Updating the currently checked out branch may cause confusion, warning: as the index and work tree do not reflect changes that are in HEAD. warning: As a result, you may see the changes you just pushed into it warning: reverted when you run 'git diff' over there, and you may want warning: to run 'git reset --hard' before starting to work to recover. warning: warning: You can set 'receive.denyCurrentBranch' configuration variable to warning: 'refuse' in the remote repository to forbid pushing into its warning: current branch. warning: To allow pushing into the current branch, you can set it to 'ignore'; warning: but this is not recommended unless you arranged to update its work warning: tree to match what you pushed in some other way. warning: warning: To squelch this message, you can set it to 'warn'. warning: warning: Note that the default will change in a future version of git warning: to refuse updating the current branch unless you have the warning: configuration variable set to either 'ignore' or 'warn'.
Woah! After some research, this is because I didn’t set up my remote folder as “bare”. A non-bare repository has a working copy attached to it, and this warning is telling you that said working copy exists and is currently checked out to the branch you’re trying to push to.
This is bad, because if you were pushing to a co-worker’s machine, then when they go to commit or run a diff, things will go awry. In this case, I just didn’t set up the repository correctly (it was the first one I’d done!) so I wasn’t in danger of losing anything.
The fix is to use --bare:
git init --bare or git clone --bare
Capistrano deploy error "fatal: unable to create '.git/index.lock': File exists"
This isn’t specific to capistrano, necessarily, but I ran into it deploying.
fatal: unable to create '.git/index.lock': File exists
read more
git: You asked me to pull without telling me which branch …
Received this error when trying to pull from a remote origin:
You asked me to pull without telling me which branch you want to merge with, and 'branch.master.merge' in your configuration file does not tell me either.
git: failed to push some refs
I’m really digging git, but its error messages are less than helpful at times.
git push origin master error: failed to push some refs to origin
Most likely, there are changes in the remote repo that you need to pull first:
git pull origin master
Resolve any conflicts, then you can push to the remote git repo.
I’m not sure why “failed to push some refs” couldn’t include “(do you need to pull?)”
Visualizing git history
I’ve been using git for version control on a new project. Instead of needing a connection to the server (as CVS and SVN do), changes are stored locally.
Every once in a while, I want to poke back the history. git ships with a graphical repository viewer, but I like gitx better.
git makes branching off to try something super easy, which is quickly becoming one of my favorite features. I can create a branch quickly, try something out, switch away and come back later if I want.
Using gitx to view my repository history, I can quickly find where branches diverged and it’s just kinda neat to look at.