Tag: CLI

How to practice getting into and out of a detached HEAD state via command line – 096

Yesterday’s tip went over the visualization of what happens when you are in a detached head state. Today’s tip now applies it to the command line.

Suppose you’ve initialized a git repository using the bash script from a previous tip. I’ve only used 3 files to be concise.

And you’ve did a git checkout <previous-commit-ID> to get into a state similar to Stephen King’s IT trailer. (don’t worry no videos here*)

Remember your training.

Optional: let’s do a git reflog to get that sense of security that all of our commits are still there. Even though the file 3 commit is “gone”, the reflog verifies all is well.

Now let’s get out of that detached head state by doing a git checkout master. Previously, I would have done git checkout <last-commit-ID> and freaked out that I was still in a detached head state.

And now all is good in the world again. We see master in blue. We see all 3 previous commits. And our git status isn’t like something from a Stephen King movie.

*As many of you know, I used to be a professional clown. Clowns don’t scare me, but wow seriously that trailer is scary!

How to practice getting into and out of a detached HEAD state – 095

I promised that this blog would be a pun-free zone, but I must recommend Terry Pratchett’s The Thief of Time. It’s the last book of the “Death” series. In fact, I recommend starting with Soul Music. Anyways I kept thinking of that creature as I wrote this tip.

So far, my two biggest lightbulb moments have come from learning about `git reflog` and this git visualization tool. Nothing came close to making sense until I combined those two.

Let’s use the visualization tool to practice getting in and out of a detached HEAD state.

First, let’s make a few commits…

Next let’s checkout to the previous commit. Note: it helps to type in the commit id correctly, so ignore the “can’t find commit id”

Notice in the image above indicates that we’re in a detached HEAD state. Previously, I would have panicked because my last commit (the one master is pointing to) wouldn’t show up in the git log. But now because of this visualization tool, I can see that master is still there and that HEAD is just pointing at the previous commit.

To get out of the detached head state, you’ll need to git checkout master. Previously, I would do git checkout commitID-master-is-pointing-to and still be in a detached state, frustrating me to no end.

Now you’ll see that HEAD is pointing to master and we’re no longer in a detached HEAD state.

Tomorrow we’ll go over getting into and out of a detached HEAD state via the command line.

How to recover from the "oh no! I did a git reset and now my files are gone!" – 087

If you don’t know about git reflog, your life is about to get much, much better. Prepare yourself. Git is about to make just a bit more sense.

Note: I use the git visualization tool at the bottom of this post, in case you want to jump straight to the “How on earth is this possible?! I give up. Git is just magic.”

Using yesterday’s tip, suppose you have a repo with 6 files each with their own commit.

Cool. Now let’s say you did a `git reset –hard <commitID for file4>` to reset back to file 4. Note: any flavor of git reset will work for today’s scenario, since we’re not making any changes in our working directory (or so I think).

To recap these past several days:

git reset changes history and should be avoided if you’ve already shared those commits with others (e.g. you use it when you haven’t pushed yet.)
git revert undoes a commit by creating a new commit with those changes uncommitted (wow, what a sentence. My apologies.)

Notice how the above image confirms the git log only shows the commits up to file 4.

In addition,`ls` and `git ls-files` shows how files 5 and 6 are “gone”!

will the real Git Log please stand up? please stand up. please stand up.

The command`git reflog` will show you the actual history of your git commands AND THEIR COMMIT IDS!!

what?! what?! what?!

The lightbulb moment for me was that git was keeping those commits around, and not to mention git is also keeping an actual log of everything going on alongside my repo’s git log.

Let’s get those files back.

You’re going to do another git reset, but this time, you’re going to change history by rolling forward instead of rolling backwards.

so you’ll do `git reset –hard <commit id for file 6>`

and all our files are back. In fact, if we do a `git log` we’re back to where we were at.

How on earth is this possible?! I give up. Git is just magic.

Let’s learn some magic tricks using the git visualization tool at http://git-school.github.io/visualizing-git/

alrighty. let’s rinse and repeat the setup

notice how the commits for files 4, 5, and 6 are there, but just dotted out (or whatever the official term is).

So we never “deleted” those commits. We just told git to hide them from ourselves, but not from git.

Now for the magic. We can do a reflog here in this tool.

Notice how HEAD and master pointers just move back to that commit ID. That’s it. These HEAD and masters pointers are just that… pointers.

This is why people say “don’t delete your .git folder and start over.” Your changes aren’t “gone”. They are just playing hide and sneak because you told them to.

Got to get back. Back to the past. Samurai Jack!!

How to write a Bash or PowerShell script to quickly create test repos – 086

TFW you learn something that saves you a ton of time.

Our GitHub services team has on-demand content for learning Git, including a Git out of Trouble section. On page 2 git-set-up they show you how to create a script to create several files, commit them to your repo, one file at a time.

I’m using Git Bash, so here’s the Bash script

for d in {1..6};
 do touch file$d.md;
 git add file$d.md;
 git commit -m "adding file $d";
 done

First, you’ll want to do `git init` otherwise, you’ll get yelled at by your shell for not being in a git repository.

Just copy and paste that into your shell (terminal or whatever),

Press Enter,

and enjoy your Git out of Trouble explorations!