Tag: CLI

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.

git bash showing 6 commits

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”!

ls and git ls-files not showing files 5 and 6

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!!

output of git reflog

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>`

git reset --hard commitID showing files 5 and 6 come back

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

git log showing all commits back

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

git visualization showing head and master at file 3

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.

using git reflog and git reset back to file 6 in 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";

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),

script pasted into a Git Bash command prompt

Press Enter,

 git messages shown as script is run

and enjoy your Git out of Trouble explorations!

git status showing a commit for each file

How to view a git log graph from the command line that looks like Visual Studio View History – 076

It feels like there are 100 different ways to do a git log. Here’s one possible way… I’m using the OpenLiveWriter repo to demo since it has lots of branching going on.

P.S. The way to exit these log commands is to press ‘q’ when the colon appears, if you are following along at home.

let’s start with git log –graph.

git log --graph command line

But it’s too wordy to show the graph.

Let’s try git log –graph –pretty=oneline

git log --graph --pretty=oneline

Better, but the long commit IDs are throwing everything off.

Let’s try git log –graph –pretty=oneline –graph –abbrev-commit

git log --graph --pretty=oneline --graph --abbrev-commit

And that’s about as close as I can get to a graph that looks like the graph in Visual Studio.

If you know of a better way, please share with the group! 🙂

How to amend changes to your code in your most recent commit – 074

Yesterday’s tip was about making changes to your commit message. Today’s tip is making changes to your code as well.

Hey my Git experts friends reading this! I’m not sure what the command line equivalent is, so can someone look at my section below on using the CLI and tell me why I have to use –allow-empty?

We’ll start with Team Explorer in Visual Studio and then rinse and repeat with what I think is the equivalent git command.

Amend using Visual Studio

It looks like Team Explorer will let you amend based on whatever changes are in the working directory, but just in case you only want to change one file, I’d suggest staging the file(s )you want to amend first. In a command line scenario, whatever files are in staging are the ones that will be amended. (See previous tips)

Actions button in Team Explorer

Click on the Actions button and select Amend Previous Commit.

Amend Previous Commit

And you’ll get a new commit ID.

new commit ID shown in TE info bar

Amend using Command Line

Full disclosure: I don’t know when to use the –allow-empty option. I also don’t know what the ramifications of using it are. It seems I need to use this option even though 1. the staged changes are different than those in the commit history and 2. I’ve specified a commit message. TBH I’m not sure what is going on here.

But this is my best guess at the command line equivalent of what Team Explorer is doing.

  1. make changes to your file
  2. use git add to add those changes to staging
  3. git commit –amend -m “new message” –allow-empty or git commit –amend –allow-empty (but I’m not sure)

The below screenshot shows what happens when I don’t use the –allow-empty option.

git commit --amend -m "new message" wants the --allow-empty even though changes are staged

and here’s what happens when I use the –allow-empty, which turns out to be the behavior I want (or as far as I know!)

git commit -m "update readme" --amend --allow-empty shows success

So yeah, if you know what is going on wrt to the –allow-empty option, please let me know!!

How to push a new branch to your repo on GitHub via the command line – 042

I’ve never thought about Feb 11 being the meaning of life day…

Let’s assume on your local repo, you’ve created a branch and made some changes to that branch. Now you want to push up to your repo. It doesn’t matter if your repo is a fork of someone else’s repo or if you created the repo from scratch.

Before I push my changes, I like to review the logs. This is totally optional, but a good sanity check from time to time to make sure you’re not sharing your email address.

To review your logs, use the command

> git log

viewing your logs in git that will go up to github

and I see my email address is using the noreply one from GitHub so I can still get credit for my contributions. (See upcoming tip.)

And now I can push these changes up by using the following command:

> git push origin windows-fix

and you can verify these changes in your GitHub repo.

your recently pushed branches: windows-fix

and if you switch to this branch (by clicking the branch name in the previous image), you’ll see the 3 commits listed there.

windows-fix branch showing the 3 commits

If you’re wondering why I’m doing this blog series, it is because I constantly have to look up these commands. That’s the problem you run into when you haven’t been paid to code in 10 years. I’m having to come up with other creative ways to grok this material. I always think this command is either git push <branch-source> <branch-destination> or git push <repo-destination> <repo-source> which neither is the case. The command is actually git push <remote-name> <branch-name> See github documentation. I always forget this because I think that master is the name of the local repo (from doing git push origin master all the time). But again, this isn’t the case. Master is the name of the default branch (and not the repo).

How to create a new branch on your forked GitHub repo via the command line – 041

Suppose you’ve forked a repo and have cloned a local copy. You’re ready to start making changes, but wait! first you’ll want to create a new branch first before making your modifications. (Don’t worry if you forget this step. I always do. Fortunately, you’re using Git now and there’s a way to do anything and everything it seems. I’ll cover how to get out of this state gracefully in a future tip.)

You could use two separate commands

> git branch <branch-name>

> git checkout <branch-name>

or use a shortcut that automatically creates a branch and switches to it using the –b switch:

> git checkout –b <branch-name>

as shown in the image below

git command to create and switch to a new branch

Suppose you’ve made a typo and misspelled windows as widnows.

You can fix this by renaming the current local branch using the following command:

> git branch –m windows

As seen in the image below.

renaming misspelled branch

Now you might be wondering why a –m switch and not a –rn switch. This is because –m stands for move, and since Git started on UNIX-based systems, Git uses a lot of the UNIX nomenclature. So to rename a file in a UNIX system, you need to move the file to its new name. Thanks to this SO answer.

How to clone your forked GitHub repository using via a command line interface – 040

It is time to get into coding examples from the command line!

In previous tips, you used either the Create new file or Edit file buttons on GitHub.com itself to make changes to a repo. Then you selected the Create a new branch for this commit option in either the Commit new file or Commit changes form to create a new branch (which will be used by a Pull Request).

In the upcoming days, you’ll see how to setup a branch in your local repo so you can submit a bug fix to the base repo as a Pull Request.

From your favorite Command line Interface (I’m using GitHub Desktop’s Git Shell that opens Git Bash – see yesterday’s tip), you’ll want to

  1. Clone the repo
  2. Create a branch (see tomorrow’s tip)
  3. Make your changes (see tomorrow’s tip)
  4. Push your branch back up to your GitHub repo (see the day after tomorrow’s tip)

But first, let’s clone the repo.

Go to the desired repo. For this example, I’m using saraford-tips/your-moment-of-github-zen

You can get the clone instructions from clicking the Clone or download dropdown button, and then coping the URL (either select the text inside the edit box or click the Copy to clipboard button).

Clone with HTTPS window showing URL

Now from the command line, run git clone <copied url>


Now cd into your repo, and you are all set locally! I always do a git status just out of habit.

showing git status from local cloned repo