Git與GitHub使用注意事項

Git使用注意事項    

⒈保持原子性的提交

每次提交的間歇盡可能地短，以幾個小時的開發工作為宜。例如在更改 UI 界面的時候，可以每完成一個 UI 界面的修改或者設計，就提交一次。在開發功能模塊的時候，可以每完成一個小細節功能的測試，就提交一次，在修改 bug 的時候，每修改掉一個 bug 并且確認修改了這個 bug，也就提交一次。我們提倡多提交，也就能多為代碼添加上保險。

⒉對提交的信息采用明晰的標注

不論是在本機中使用本地庫，還是未來推送到遠程庫，如果提交不明確的標注不僅僅會讓自己懷疑當初提交的目的，也會讓項目組中其他的成員感到很無奈，項目經理無法很清晰的掌握工作進度，無法清晰的把握此次提交的概要信息。在有必要的情況下也不能明確的的回到指定的歷史記錄。所以，在做提交工作時，要填寫明晰的標注，能夠概要的描述所提交文件的信息，讓項目組其他成員在看到標注后不用詳細看代碼就能了解你所做的更新。

GitHub使用注意事項

⒈推送之前先拉取

GitHub拉取的原則是要隨時拉取，隨時推送。當完成了一個小功能，能夠通過編譯并且自己測試之后，謹慎地推送。

如果在修改的期間別人也更改了相同的文件，那么推送就可能會產生沖突，這種情況就需要同之前的開發人員聯系，兩個人一起協商解決沖突，解決沖突之后，需要兩人一起測試保證解決沖突之后，程序不會影響其他功能。

⒉不要推送不能通過編譯的代碼

代碼在推送之前，首先要確認自己能夠在本地編譯。如果在代碼中使用了第三方類庫，要考慮到項目組成員中有些成員可能沒有安裝相應的第三方類庫。項目經理在準備項目工作區域的時候，需要考慮到這樣的情況，確保開發小組成員在簽出代碼之后能夠在統一的環境中進行編譯。

⒊不要推送自己不明白的代碼

代碼在推送進入到GitHub之后，你的代碼將被項目成員所分享。如果提交了你不明白的代碼，你看不懂，別人也看不懂，如果在以后出現了問題將會成為項目質量的隱患。因此在引入任何第三方代碼之前，確保你對這個代碼有一個很清晰的了解。

⒋提前協調好項目組成員的工作計劃

項目經理應該合理分配工作計劃。每個成員在準備開始進行某項功能的修改之前，如果有可能，先跟工作小組的成員談談自己的修改計劃，讓大家都能了解你的思想，了解你即將對軟件作出的修改，這樣能盡可能的減少在開發過程中可能出現的沖突，提高開發效率。同時你也能夠在和成員的交流中發現自己之前設計的不足，完善你的設計。