Git 使用の常識

一。関連する変更のみをパッケージ化してコミットする（COMMIT RELATED CHANGES）

commit は関連する変更のパッケージ化であるべきです。例えば、2 つの異なるバグを修正する場合は、2 つの独立した commit にすべきです。このような細かい commit は、他の開発者が変更を理解しやすくし、エラーが発生した際に簡単にロールバックできるようにします。Git のステージングエリアとステージング機能は実際にはファイルの一部に過ぎないため、粒度の細かい commit を簡単に作成できます。

二.頻繁にコミットする（COMMIT OFTEN）

頻繁にコミットすることで、各 commit が十分に細かくなり、関連する変更のみをパッケージ化してコミットするのに役立ちます。さらに重要なのは、他の人と頻繁にコードを共有できることです。これにより、誰もが変更を定期的に統合しやすくなり、merge 衝突を回避できます。逆に、いくつかの大きな commit しかなく、共有も少ない場合、merge 衝突の処理が困難になります。

三.未完成の作業をコミットしない（DON'T COMMIT HALF-DONE WORK）

完成したコードのみを commit すべきです。commit 前に大きな機能モジュール全体を完了させる必要があるわけではありません。むしろ、機能モジュール全体の実装を論理ブロックに分割し、頻繁に早めに commit するだけです。決して���日退社前に習慣的に commit してはいけません。commit したい理由がクリーンな作業領域が必要なだけ（あるブランチをチェックするため、または変更をプルするためなど）であれば、commit ではなく Git の stash コマンドの使用を検討できます。 You should only commit code when it's

四.コミット前にテストする（TEST CODE BEFORE YOU COMMIT）

完了したと思って急いで commit してはいけません。本当に完了しており、（既知の）副作用がないことを確認するために徹底的にテストすべきです。未完成品をローカルリポジトリに commit しても自分にとって面倒なだけですし、push したり他の人とコードを共有する際には、コードがテスト済みであることを保証することが非常に重要です。

五.コミットメッセージを丁寧に記入する（WRITE GOOD COMMIT MESSAGES）

commit 情報は、行った変更の簡潔な（50 文字以内を推奨）要約から始め、要約と以下の情報本文を空行で区切ります。情報本文は以下の質問に詳細に回答すべきです：

1. この変更の理由は何ですか？

2. 以前の実装との違いは何ですか？

git ネイティブ情報と一致させ、git merge などの場合は、命令法、現在時制で記述し、過去時制や三人称単数形は使用しないでください。

六.バージョン管理システムはバックアップシステムではない（VERSION CONTROL IS NOT A BACKUP SYSTEM）

ファイルをリモートサーバーにバックアップすることは、バージョン管理システムにとって大きな副作用ですが、VCS（バージョン管理システム）をバックアップシステムとして使用すべきではありません。CVS を使用する際は、commit のセマンティクスにより注意を払うべきです（関連する変更のみをパッケージ化してコミットする を参照）。単にファイルを詰め込むだけのことはしないでください。

七.ブランチを多用する（USE BRANCHES）

ブランチこそが Git の最も強力な機能です。これは偶然ではありません：高速なブランチ操作は最初からコア要件でした。ブランチは開発プロセス中の各作業が混同し合うのを避けるための完璧なツールであり、開発ワークフローで広く使用するべきです：新機能の追加、バグ修正、新しいアイデアの試行……

八.ワークフローに合意する（AGREE ON A WORKFLOW）

Git はさまざまなワークフローをサポートしています：long-running branches、Topic branches、merge または rebase、git-flow……どれを選択するかは多くの要因に依存します：具体的なプロジェクト、全体の開発、開発ワークフロー、そしておそらく最も重要なのは、チームメンバーの好みです。どれを選択しても、誰もがワークフローに合意していることを確認してください。

九.ヘルプドキュメント（HELP & DOCUMENTATION）

コマンドラインヘルプを簡単に取得できます：git help

十.無料オンラインリソース（FREE ONLINE RESOURCES）

• Git Tower：http://www.git-tower.com/learn

• Github 簡易ガイド：http://rogerdudler.github.io/git-guide/

• Git 公式サイト：http://www.git-scm.org/

• 《Pro Git》：百度網盤、500+ ページの PDF、高度な機能が必要な場合は参照できます

参考資料

• Git Tower：Version Control Best Practices