Git

Last time I checked, git was the most used command in my history. Git is one of the first software I install on a new machine, with Vim.

Here’s all the stuff I collected about Git, that helped me better understand it and learn to use it properly.

References

• Pro Git
• Git magic

Tutorials (beginner)

• First steps (GitHub)
• Git for beginners
• Enfin comprendre Git (really complete introduction, in French)

Tips & tricks

• Part 1
• Part 2
• Part 3
• Git tips from the trenches

Deepening

See how it works in the background

• A hacker’s guide to Git
• Git from the inside out
• Git from the bottom up
• Cheat sheet about Git states

Reimplementing Git

• Introducing Gitlet
• Git in six hundred words
• Gitlet

Workflow & branching

• A successful Git branching model
• Comparing workflows
• Using git-flow to automate your git branching workflow

The Kitty way

• How I use Git

Other interesting stuff

• Debugging in Git with blame and bisect
• 30 Git CLI options you should know about
• Git rebase, le couteau suisse de votre historique (French)
• Abandon your DVCS and return to sanity (keep in mind DVCS are not perfect)
• Getting solid at Git rebase vs. merge (excellent article, exactly my workflow)
• How to undo (almost) anything with Git

Commit messages

• A note about Git commit messages
• How to write a Git commit message

Personal notes

• Use ' and not Markdown ` for consistency with default Git messages, like Merge branch 'foo'.

• For URLs, according to commit messages in Git itself and the Linux kernel, either skip a line and indent the URL with 4 spaces:

  Some message:
  
      https://www.codejam.info/
  
  Another sentence.
  

  Or use link references like this:

  Some message referencing a link [1] in a sentence, and maybe even
  another link [2].
  
  [1] https://www.codejam.info/
  [2] https://git.codejam.info/
  

GitHub

• GitHub cheat sheet (also see their list of Git resources)

Handling patches and pull requests

• Care and operation of your Linus Torvalds (originally on kernel.org)
• Gerrit code review - signed-off-by lines
• What is the sign-off feature in Git for?
• “Merge pull request” considered harmful

Especially, the part about “slightly modifying patches” in the first three links:

If you are a subsystem or branch maintainer, sometimes you need to slightly modify patches you receive in order to merge them, because the code is not exactly the same in your tree and the submitters’. If you stick strictly to rule C, you should ask the submitter to rediff, but this is a totally counter-productive waste of time and energy. Rule B allows you to adjust the code, but then it is very impolite to change one submitter’s code and make him endorse your bugs. To solve this problem, it is recommended that you add a line between the last Signed-off-by header and yours, indicating the nature of your changes. While there is nothing mandatory about this, it seems like prepending the description with your mail and/or name, all enclosed in square brackets, is noticeable enough to make it obvious that you are responsible for last-minute changes. Example:

Signed-off-by: Random J Developer <random@developer.example.org>
[lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>

This practice is particularly helpful if you maintain a stable branch and want at the same time to credit the author, track changes, merge the fix, and protect the submitter from complaints. Note that under no circumstances can you change the author’s identity (the From header), as it is the one which appears in the changelog.

So, in summary:

Commit summary

Longer description of the commit.

Closes #42.

[email@domain: fix summary]
[email@domain: fix summary that can be longer and span on multple lines
if needed, though it's still not capitalized nor have a period]

Clone the Linux kernel Git repository and search for \[.*@ to see how it’s used.