Gitiquette

Some tips on how to make proper commit messages in git.

Transcript

1. gitiquette D. Yu
2. THIS IS NOT AN INTRODUCTION TO GIT.
3. THIS IS NOT THE FIRST TIME I’M DOING THIS TALK.
4. HAVE YOU EVER SEEN COMMIT MESSAGES THAT MAKE YOU GO WTF?!
5. Fix for bug #86. Let’s start with a classic.
6. • It doesn’t tell you anything. • More importantly, it doesn’t tell the rest of the team anything. • In two weeks, you will forget what bug #86 is. Why was that bad?
7. Turn the starboard hangar deck of the Battlestar Galactica into a gift shop. It should be ready for Admiral Adama’s retirement. We also revived the Admiral’s old viper so Lee can fly it. Lee probably wouldn’t want to do it, because he has daddy issues. But he’ll do it anyway because he’s a good soldier. Personally, I’m glad this old bucket of bolts is turned into a museum. If the Cylons decide to show their dumb faces again, the Galactica wouldn’t stand a chance. Our safety depends on the newer battlestars with really advanced electronics. And their vipers too. What? Spoilers? Hey, whatever. So say we all! Wall of text….
8. • If I see a gigantic wall of text, I probably won’ t read it because my attention span is Linux is the best OS ever. • If I do read it and forget some parts, I wouldn’t want to read it again. Why was that bad?
9. Reintroduce Starbuck as a girl in the revival. We’re sure this won’t upset anyone from the old school fandom, because it’s 2005 and we’re really into openness and acceptance. Really long first lines...
10. • Most tools won’t be able to display it properly • The recommended length for each line is 72 characters. • You obviously have a lot more to say. Why was that bad?
11. What does a good commit message look like? <what?> <why?> <how?> <where?>
12. What does a good commit message look like? Move old vipers from gift shop to port hangar. The cylons attacked and it seems they’re able to hack the newer vipers. The old vipers don’t have computers. The engineering team used their small cranes and put some of the vipers on trucks. For the smaller things, we carried them by hand. This closes item #86 on PivotalJira http://pivotaljira.com/items/86
13. In short… Most important things first. Go straight to the point. Format properly. Use paragraphs if the sentences are long. Use bullet points if the paragraphs are long.
14. Commit messages should be like skirts. Long enough to cover the important parts, but short enough to be interesting. Also, don’t forget to keep it classy.
15. ...someone does 10,000 lines in one commit BUT SOMETIMES...
16. ...you have a lot of unpushed commits that you just want to clean up. SOMETIMES...
17. ...you just want to rewrite your history. SOMETIMES...
18. Warning about rewriting history... Noticed how the previous slide said “your history”? Never EVER rewrite public history. If you pushed to a repository used by other people, don’t rewrite it anymore. It’s not your history anymore.
19. Which usually means force pushing... Do everyone a favor and alias `git push --force` to `rm -rf /` If you have to force push, usually there’ s another problem. Fix that problem.
20. I’m done with my mini rant. ANYWAY...
21. Reorder, combine, etc... INTERACTIVE REBASING
23. This is the only thing you have to remember. git rebase -i HEAD~4
24. -i is short for --interactive
25. Let's try to reorder some commits...
30. Let's try to combine some commits...
36. RTFM Long story short...
37. Hard, soft, mixed... RESET
38. git reset is really powerful, but... • we are not Spider-Man • it scares people • most people only know --hard • the documentation sounds too sciency... • ...which scares people
39. git reset --help NAME git-reset - Reset current HEAD to the specified state SYNOPSIS git reset [-q] [<commit>] [--] <paths>... git reset (--patch | -p) [<commit>] [--] [<paths>...] git reset (--soft | --mixed | --hard | --merge | --keep) [-q] [<commit>] DESCRIPTION In the first and second form, copy entries from <commit> to the index. In the third form, set the current branch head (HEAD) to <commit>, optionally modifying index and working tree to match. The <commit> defaults to HEAD in all forms.
40. Let's review how commits are made... • save your changes in your editor • add your changes to the staging area • commit your staged changes to your local repo • push your commit to a remote repo
41. Let's pretend we want to go back to cb5eb1d...
42. git reset --hard cb5eb1d
43. git reset --soft cb5eb1d
44. git reset cb5eb1d
45. Reset Summary hard == undo soft == uncommit mixed/default == unstage
46. Because `git add .` is too mainstream... STAGING
47. git add . Most people only do this...
48. git commit -am "Fix for bug #32767" Or worse...
49. Because you don't want to drive your teammates or your future self crazy! WHY?
50. Make it a habit to…. • not use commit -m • use your editor instead • stage changes by piece
51. By files! git add <filename>
52. Still not good enough. By hunks! git add -p
53. Still not good enough. By line! git add -e
54. For those times your boss wants you to drop whatever you’re doing to work on something else... STASHING
57. It's a lot like... “I want to keep you, but I’m not sure if I want to commit.”
58. I don’t always practice what I preach and I am just as bad as everyone else when making changesets. DISCLAIMER
59. END QUESTIONS?