Tag: git

How to practice not freaking out when you see (master|MERGING) by using git merge –abort – 102

I feel that a lot of Git tutorials forget what that raw, primal panic feels like when you see your branch name change to (master|MERGING). For me personally, 80% of the panic comes from not knowing “how do I get out of this state?! How can we pretend this never happened??”

Today’s tip is about how to get into and out of a merge conflict state, without creating any actual conflicts! I say no conflicts because the easier the setup, the easier it will be to practice, and eventually you’ll build up enough muscle memory to stay calm in future situations.

I have a branch called mybranch3 that simply contains a new file (e.g. touch myfile.txt). If I did just a `git merge –no-commit mybranch3` git would apply a fast-forward, so you have to add the –no-ff. I guess the fast-forward check take precedence in the git world.

The –no-commit tells Git not to automatically do a merge commit, but rather, let you manually do the merge commit, as we’ll see in tomorrow’s tip.

You could do a `git status` to figure out how to finish the merge (e.g. `git commit -m “merging mybranch3″`), but today’s tip is about practicing, “I’m taking my ball and going home.” You show Git who’s boss!

You’ll want to run the command `git merge –abort`

and as you see from the `git log –oneline`, nothing was merged in from mybranch3. (the readme commit was my initial commit. I guess saying initial commit would have made more sense.)

P.S. this was my original vision for this series: take each option of each git command, play with it, try to break it, and blog about it. And it’s still my vision! But got to get through some of the more conceptual stuff first. I also want to get to the internal plumbing of trees, blobs, etc. Maybe in December 😉

How to know that a merge creates a git commit whereas a fast-forward does not – 101

I’m using several resources to teach myself Git: Ed’s Git for Visual Studio O’Reilly course, the Pro Git book, this particular Git Visualization tool, and the Git for Humans book. (If I’m missing a good intermediate resource, lmk!) As I study a concept in one course, I’ll go back and re-read that section in another book or course to see if there are any surprises that I didn’t catch the first time.

As I started re-reading the section on merging in Git for Humans, it hit me that I had missed one important difference between a git merge and a fast-forward – the merge commit!

I’ll use the Git Visualization tool to demo:

When you do a fast-forward merge, the commits from the feature branch (source branch?) are simply added to the master branch (target branch?), as soon in Tip 92 – how to do a fast forward merge

However, if we’re doing a real merge (e.g. there are conflicts that have to be resolved or you pass in the –no-ff option as we’ll have to do with this visualization tool), you’ll see that a new commit, called a merge commit, is added.

I guess Farris had it right (source)

I saw that movie when I was in elementary school. I promised myself when I got into high school I would take a day off and do all the things in that movie. The float scene was possible because of growing up in New Orleans, but the baseball part would have been challenging. I think the closest I’ve ever come to doing something like Farris Bueller was driving to Nintendo HQ (right by the gym I used to go to in Redmond), jumping out of the car, and screaming, “YES I MADE IT!” in homage to all those times as a little kid I entered to win a trip to Nintendo HQ via all those Nintendo Power magazines.

How to make a commit in a detached HEAD state – 098

And one more quote from the same stack overflow answer, “it will still allow you to make commits (which will update HEAD), so the above short definition is still true if you think of a detached HEAD as a temporary branch without a name.”

What? We can still make commits? in a detached HEAD state?

Let’s be brave and give it a try in the visualization tool.

If we do a ‘git commit’ in the detached HEAD state, the visualization tools shows a commit being made to the side.

P.S. Have I proclaimed my love of this git visualization tool yet today?

So what on earth now? we have this thing floating out in nowhere. Well, we know it is a nameless branch… and we know we can merge branches… let’s try to merge it!

First, we’ll checkout master.

Then we’ll do the merge and verify the git log.

and thus conclude my mathematical proof I truly have no idea how people are able to keep track of these one-off commits or whatever is going on in git without visualization tools. QED.

How to think about what the HEAD thingy actually is in Git – 097

My learning preference is through hands-on experimentation. I like taking things apart, putting them back together, or trying to break stuff. So let’s break apart this HEAD thingy.

According to this SO answer, it is a file.

saraf@TheBlueDog ~/Source/Repos/scrap/detachedHeadPractice (master)
$ cat .git/HEAD
ref: refs/heads/master

and that file contains some content. I’d assume “ref” means reference, and “master” is the master branch we’ve been playing with. I’m not sure what “refs/heads/master” actually stands for, but I’ll figure that out later.

I keep hearing HEAD referred to as a pointer. This would make sense if it is a file that only contains the location(?) where to point to. That answers the literal question.

But what does the HEAD pointer do?

According to this stack overflow answer, “HEAD is a reference to the last commit in the currently checked-out branch.” Considering we have master checked out, that makes sense. Doing a git log would show all the commits in the repo. If we switched to a branch and did a git log, we’d see all the commits for that branch.

But what about the detached HEAD state from yesterday?

Continuing with the same stack overflow answer, “A detached HEAD is the situation you end up in whenever you check out a commit (or tag) instead of a branch.”

Yep, we saw that yesterday. HEAD is pointing at the 2nd commit, whereas master is pointing at the 3rd.

visualization tool showing a detached HEAD state

Now I had to re-read this line from the same stack overflow answer, “In this case, you have to imagine this as a temporary branch without a name; so instead of having a named branch reference, we only have HEAD.”

A temporary branch without a name??

Okay, what I think is happening is that if you were in a detached state (as shown above) and did a git log, you’d only see 2 commits, not 3. Since you are seeing 2 commits, you are still technically on a branch. It’s just that this branch doesn’t have a name.

In other words, a Git pointer never points to just a single commit. A git pointer points to the last commit in that series of commits (which I guess is where the temporary nameless branch concept comes from). Which now begs the question… what’s really a git branch?