I’d like to share something about git I learned the hard way in the wild.
Branch often, complete often, merge often. Branch a lot, they are really cheap. So in order to follow this, you need to figure out a way to split your feature into a reasonable amount of branches(think sequentially), complete feature step by step(branch by branch, pull request by pull request), then merge them back into your team’s main development branch. This greatly helps with code review, because there will be less codes to review each time. This will leads to more code reviews, and more code reviews is a good thing, because it helps your teams understand each other better, particularly each other’s subtle coding styles(in other words, how do your teammates think).
Write good commit messages. I mean, really good commit messages. They could be really useful. So how do you do it? Read this and this. Good(short, concise, summarized) commit messages could literally serve as some sort of documentations.
Once you decided to write good commit messages, you will immediately understand how useful
git rebase -iis. So basically this tool allows you to checkout the branch, do a bunch of hacks, write all kinds random commit messages for yourself, but in the last tidy them up as if you wrote all these codes in one breath like a poem. However, you shouldn’t rely too much on this technique, and goes too wild. A general strategy I took is hacking everything first, then committed chuck by chuck, then lastly do a bit rebasing. As git is not a tool to document the process about how did you put together your codes, but a way to communicate with your follow peers.
If you really messed up commits or use commits as intermediate sync mechanism between different laptops, you may find
git reseta useful tool to restart writing all commits & messages but keep the changes. Combining this technique with branching, a whole lot of fancy stuff could be done. For example, you could work some stuff in your own branch, later
git reseteverything, taking changes to your desired branch, then writing some appropriate commit messages, last lastly push the desired branch into Github or your own git server.
Assuming you have done above, then you will discover
git logis really useful, try using
git log -p,
git log --pretty=onelineand
git log --stat. You will feel these commands suddenly make sense, a lot of sense.
Special thanks to Ted and Wei-liang for sharing their thoughts and knowledge with me.