My stuff in the file index.html was working a minute ago, and now it's not. This is when I really wish I could hold up a snapshot of my broken index.html to what it looked like on a previous commit.
Duh! That's the whole point of Git! And Beyond Compare can show it all in a GUI.
Step One: Run git log, to see a list of all of your restore points. (Pause and reflect a moment on how you ought to compose more useful commit messages.)
Find the commit number (seven digit hash thing). Copy it.
At this point you could tell Beyond Compare to show you your most recent work that was saved to disk (your working tree) and compare it next to your most recent commit. To do that, you don't need to type in the hash number. Just type
git difftool index.html If you just say diff instead you will get lots and lots of spaghetti text. By saying difftool you are telling Git that you are a civilized programmer and want a stylish GUI to display your two diff views in.
If you have a specific rollback point in mind you would say something similar to
git difftool 37528a6 -- index.html.
Sometimes you want to see the difference between one old commit and another. The syntax for that would be the two commit numbers:
git difftool 37528a6..ee82721. By not saying the name of the file, you are telling Git you trust her to show a whole bunch of files that have changed. When you say something like
git difftool 37528a6..ee82721 Git will often say something like "Do you wish to see 1 of 7, Y/n? Do you wish to see 2 of 7, Y/n..." Et cetera. Each one of those will open up one at a time in Beyond Compare.
If you only wanted to see your readMe.md, you would add that to the above command, separated by a floating doubledash:
git difftool 37528a6..ee82721 -- readMe.md
Maybe the simplest Git command syntax of all is for telling Git, "Hey, I just want to know how many things I have changed since my most recent commit. Simply do this `git difftool index.html` The two, nearly daily needs for this command are (1) you've forgotten all the things that you added and are having trouble writing an accurate commit message or (2) you broke your code that was working fine a minute ago and just want to peek at what you changed since the ultimate commit.
My command for my bug turned out to be
git difftool 534f28a -- index.html By only telling Git one hash number, I tell Git to assume that I want to diff the 534f28a versus my most recent save to my tree (not my most recent commit to the repo). This tells git "Open Beyond Compare, which I previously set as my difftool option" and then it tells which old commit to look at (534f28a), and finally, if you don't tell it which file, it may give you everything and the kitchen sink. So you use a double dash to keep the filename separate from the rest of the line, and type the filename. Mine was index.html.
There's my mistake! It's a missing comma (right after "bulb-land").
You can edit right in this view. Either type into the pane and then press the (tiny) save button, or with a little clicking you can move entire code blocks in from the other side of the diff. Again, remember to hit the save button.
If you go into your IDE/editor at this point, Beyond Compare will be smart enough to say 'change detected; reload?'.
By the way, instead of randomly Googling Stack Overflow or the GitGuys, or OhSh*tGit you will double your efficiency by typing
git SOMECOMMAND --help This built-in Git documentation is excellent and eclipses most supplements for searchability and clarity, I think. I admit that Linux-man-pages have a bad rep. This is not that kind of man page.
When you type
man gitdiffcore you will get a pretty nice help file. Search terms in that file by opening it, typing a simple slash and the word you want to see -- and followed by an 'm' to skip to the next occurance of the word. Type 'h' for a list of commands to bop around inside the help file. To quit the manpage help file type 'q'.
When you type
git log --help all kinds of helpful syntax advice. For example, an explanation of when to use a floating double dash (not touching any word) syntax in Git. Below:
[--] <path>... Show only commits that are enough to explain how the files that match the specified paths came to be. See History Simplification below for details and other simplification modes. Paths may need to be prefixed with -- to separate them from options or the revision range, when confusion arises.
git log --help also describes the syntax in git log for how to control the length and format of the log. From the man page:
--notes[=<treeish>] Show the notes (see git-notes(1)) that annotate the commit, when showing the commit log message. This is the default for git log, git show and git whatchanged commands when there is no --pretty, --format, or --oneline option given on the command line.