If you spend much time helping people with word processor programs, you’ll find that many people don’t really use much of the product. They type, change fonts, save, and print. But cross-references? Indexing? Largely, those parts of the program go unused. I’ve noticed the same thing with Git. We all use it constantly. But do we? You clone a repo. Work on it. Maybe switch branches and create a pull request. That’s about 80% of what you want to do under normal circumstances. But what if you want to do something out of the ordinary? Git is very flexible, but you do have to know the magic incantations.
For example, suppose you mess up a commit message — we never do that, of course, but just pretend. Or you accidentally added a file you didn’t want in the commit. Git has some very useful ways to deal with situations like this, especially the interactive rebase.
Identify a Commit
If you haven’t realized it, every version of your project in Git boils down to a commit. Branches and tags are just “pointers’ to commits. In addition, commits point to their parent commit. So, suppose you have the following sequence of commands:
mkdir project
cd project
git init
touch readme.md
git add readme.md
git commit -a -m "First Commit"
So far, this is pretty standard stuff. Next, we are going to make our first change, and we’ll simulate an emacs backup file. This will be the first change we will commit.
touch hackaday.txt
touch hackaday.txt~
git add hackaday*
git commit -a -m "Add hackaday.text"
Oops. We have two problems here, but for the sake of the example, suppose we only noticed the typ ..
Support the originator by clicking the read the rest link below.
