Git最佳實踐建議
一個commit應該對應一次相關的修改內容。比如說，修復兩個不一樣的bug應該使用兩次不同的commit。越小（修改內容）的commit能使開發人員更容易理解程式碼的修改或者在回退版本的時候更容易回退。
經常commit
經常使用commit能夠使你的commit（裡的修改內容）越小，並且能使你commit相關的修改 ，多次commit允許你推送自己程式碼到遠端分支上的頻率增加，能有效的減少merge程式碼時出現的程式碼衝突問題，因為多次 commit能使你的同事的程式碼庫得到及時的更新。
不要commit一半的工作
當開發任務沒有完整的完成的時候，不要commit。這不是說每次commit都需要開發完成一個非常完整的大功能，而是當把功能切分成許多小的但仍然具備完整性的功能點的時候，開發人員需要完整完成這個功能點之後才能commit。必要時可以使用stash命令對修改進行記錄。
commit之前的測試
保證你所開發的功能是完整無誤的。在commit程式碼之前的對程式碼充分測試是非常重要的，可以避免有問題的程式碼被其他開發人員使用。
使用commit message
commit message的開頭應該簡要說明該次修改。然後換行詳細描述一下兩個問題的細節：
- 該次修改的目的？
- 這次修改和之前的實現有何不同之處？
版本控制不是備份系統
版本控制系統雖然具備了備份的功能，但開發人員不能把VCS當成一個備份系統。開發應該多關係每次commit；使用版本控制，目的是為了使每次修改有跡可循，而不是當成備份系統直接更新檔案的內容。
使用分支
分支是git中一個很強大的功能。使用分支能夠很好的幫助開發避免混淆不同的開發直線。開發應該在開發流程中廣泛使用分支，對應不同的開發任務（比如新功能，bug修改，想法……）
協同工作基於某個工作流程
git的特性給開發人員提供了許多不同的開發流程：主分支、主題分支、merge/rebase、git-flow……。使用什麼樣的工作流程取決於你的專案、你的開發任務、部署流程和（更重要的）你的或者你同事的個人喜好。但只要你開始進行開發的時候，團隊要統一使用一個公用的工作流程，確保每個開發能夠遵守。
# Git最佳實踐建議(for English)
COMMIT RELATED CHANGES
A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits. Small commits make it easier for other developers to understand the changes and roll them back if something went wrong. With tools like the staging area and the ability to stage only parts of a file, Git makes it easy to create very granular commits.
COMMIT OFTEN
Committing often keeps your commits small and, again, helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. That way it‘s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having few large commits and sharing them rarely, in contrast, makes it hard to solve conflicts.
DON‘T COMMIT HALF-DONE WORK
You should only commit code when it‘s completed. This doesn‘t mean you have to complete a whole, large feature before committing. Quite the contrary: split the feature‘s implementation into logical chunks and remember to commit early and often. But don‘t commit just to have something in the repository before leaving the office at the end of the day. If you‘re tempted to commit just because you need a clean working copy (to check out a branch, pull in changes, etc.) consider using Git‘s «Stash» feature instead.
TEST CODE BEFORE YOU COMMIT
Resist the temptation to commit something that you «think» is completed. Test it thoroughly to make sure it really is completed and has no side effects (as far as one can tell). While committing half-baked things in your local repository only requires you to forgive yourself, having your code tested is even more important when it comes to pushing/sharing your code with others.
WRITE GOOD COMMIT MESSAGES
Begin your message with a short summary of your changes (up to 50 characters as a guideline). Separate it from the following body by including a blank line. The body of your message should provide detailed answers to the following questions:
- What was the motivation for the change?
- How does it differ from the previous implementation? Use the imperative, present tense («change», not «changed» or «changes») to be consistent with generated messages from commands like git merge.
VERSION CONTROL IS NOT A BACKUP SYSTEM
Having your files backed up on a remote server is a nice side effect of having a version control system. But you should not use your VCS like it was a backup system. When doing version control, you should pay attention to committing semantically (see «related changes») - you shouldn‘t just cram in files.
USE BRANCHES
Branching is one of Git‘s most powerful features - and this is not by accident: quick and easy branching was a central requirement from day one. Branches are the perfect tool to help you avoid mixing up different lines of development. You should use branches extensively in your development workflows: for new features, bug fixes, ideas…
AGREE ON A WORKFLOW
Git lets you pick from a lot of different workflows: long-running branches, topic branches, merge or rebase, git-flow… Which one you choose depends on a couple of factors: your project, your overall development and deployment workflows and (maybe most importantly) on your and your teammates‘ personal preferences. However you choose to work, just make sure to agree on a common workflow that everyone follows.