This trick is for people who don't double-check what they're writing. If you pressed the Enter key too early, there's a way to modify the last commit message, using the git commit command with the --amend option:

$ git commit --amend -m "New commit message"

Please note that with the --amend option, you are actually redoing the commit, which will have a new hash; if you already pushed the previous commit, changing the last commit is not recommended; rather, it is deplorable and you will get in trouble.

Working on source code in a team, it is not uncommon to need to look at the last modifications made to a particular file to better understand how it evolved over time. To achieve this result, we can use the git blame <filename> command.

Let's try this inside the Spoon-Knife repository to see the changes made to the README.md file during that time:

As you can see in the preceding screenshot, the result reports all the affected lines of the README.md file; for every line you can see the commit hash, the author, the date, and the row number of the text file lines.

Suppose now you found that the modification you are looking for is the one made in the d0dd1f61 commit; to see what happened there, type the git show d0dd1f61 command:

The git show command is a multipurpose command, it can show you one or more objects; in this case we have used it to show the modification made in a particular commit using the git show <commit-hash> format.

The git blame and git show commands have quite a long list of options; the purpose of this paragraph is only to point the reader to the way changes should be traced on a file; you can inspect other possibilities using the ever useful git <command> --help command.

The last tip I want to suggest is to use the Git GUI:

With the help of GUI, things are much more easy to understand.

The cherry picking activity consists of choosing existing commits from somewhere else and applying them here. I will make use of an example to better explain how you can benefit from this technique.

Suppose you and your colleague Mark are working on two different public branches of the same repository; Mark found and fixed an annoying bug in the feat1 branch that affects even your feat2 branch. You need that fix, but you can't (or don't want to) merge his branch, so how can you benefit from his fix?

It's easy; get the commit that fixes that bug and apply it to your current branch, using the git cherry-pick command:

$ git checkout feat2
$ git cherry-pick a1b2c3

That's all! Now the commit a1b2c3 performed by Mark in the feat1 branch has been applied to the feat2 branch and committed as a new x4y5z6 commit, as shown in the following screenshot:

The git cherry-pick command behaves just like the git merge command. If Git can't apply the changes (for example, you get merge conflicts), it leaves you to resolve the conflicts manually and make the commit yourself.

We can even pick commit sets if we want to by using the <starting-commit>..<ending-commit> syntax:

$ git cherry-pick feat1~2..feat1~0

With this syntax, you are basically picking the last two commits from the feat1 branch.