Git最佳實踐建議

COMMIT相關的修改

一個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.