コンベンションGit仕様
誰もがブランチの命名、タグ付け、コーディングのルールに従う必要があります。各組織には独自の仕様またはベストプラクティスがあり、多くの提案が無料でオンラインで利用できます。適切な仕様をできるだけ早く選択し、チームでそれに従うことが重要です。
同時に、チームメンバーによってGitレベルは異なります。一般的なGit操作を実行するためのチームの仕様に準拠する一連の基本的な手順を作成して維持する必要があります。
Commitizenは、コミットメッセージをフォーマットするためのツールです。つまり、git commitは変更後にメモを書くのと似ています。npmがcommitizenをインストールしたので、git commitの代わりにgit czを使用できます。コミットするたびにコミットのタイプを選択できるため、コミットテキストが読みやすくなります。
マージは正しく競合します
各チームメンバーは、個別の機能ブランチで開発する必要があります。しかし、別のブランチが使用されている場合でも、誰もがいくつかの共通ファイルを変更します。変更をマージしてマスターブランチに戻す場合、通常、マージは自動化できません。同じファイルに異なる変更を加えたときに、異なるユーザー間の競合を手動で解決する必要がある場合があります。これが、Gitマージの扱い方を学ぶ必要がある理由です。
最新のエディターには、Gitマージの競合を解決するのに役立つ機能があります。たとえば、変更を保持するか、別のブランチからの変更を保持するか、またはすべてを保持するかなど、同じファイルの各部分をマージするためのさまざまなオプションが提供されます。エディターがこれらの機能をサポートしていない場合は、コードエディターに変更する時期かもしれません。
git rebaseを使用して競合をマージします。つまり、次の手順を頻繁に実行します。
git pull --reabase origin master
// 改完冲突后重新提交代码
git add .
// 重新提交不要写提交信息
git rebase --continue
// 退出
git push origin feature-todo -f
// 再次提交到远端需要强推
これらの手順は、機能ブランチの履歴を書き換えます（これは悪いことではありません）。まず、機能ブランチでマスターブランチのすべての現在の更新を取得します。次に、機能ブランチでのすべてのコミットがブランチの履歴の先頭で書き直されるため、ログに順次表示されます。途中でマージの競合を解決する必要がある場合がありますが、これは困難な場合があります。ただし、これは機能ブランチにのみ影響するため、競合を解決するのに最適なタイミングです。
「純粋なマージ」戦略（git pull origin master）を使用する場合、masterブランチの履歴には、同時に開発されたすべての機能の送信が散在します。このような無秩序な歴史を検討することは困難です。正確な提出時間は通常それほど重要ではありません。見やすい履歴ログを用意することをお勧めします。
複数のメッセージを組み合わせる
機能ブランチで開発する場合、小さな変更でもコミットとして使用できます。ただし、各機能ブランチが50のコミットを生成する必要がある場合、新しい機能が継続的に追加されると、最終的にマスターブランチのコミット数が不必要に拡大します。一般的に言えば、各機能ブランチはマスターに1つまたはいくつかのコミットを追加するだけです。これを行うには、複数の送信されたメッセージを、より詳細な情報を含む1つまたは複数の送信にマージする必要があります。これは通常、次のコマンドで実行されます。
git rebase -i HEAD~20
// 合并20个提交
git commit --amend
// 编辑完之后执行退出
最後に、ブランチのGitコミット履歴が書き直されたため、リモートブランチを強制的に更新する必要があります。
ラベルを使用
テストが完了し、masterブランチからオンラインにソフトウェアを展開する準備ができている場合、または何らかの理由で現在の状態をマイルストーンとして保持したい場合は、Gitタグを作成できます。いくつかの変更と対応するコミットを蓄積したブランチの場合、ラベルはその時点でのブランチのスナップショットです。タグは、履歴のないブランチとして、またはタグが作成される前のコミットを直接指す名前付きポインターとして見ることができます。
git tag v1.0.0 -m "1.0.0版本"
さらに、署名付きタグがプロジェクトに役立つ場合は、それらの使用を検討してください。
Gitタグに対応するソフトウェアバージョンが顧客に配布され、顧客が問題を報告した状況を考えます。コードベースのコードは開発中である可能性がありますが、お客様の問題を正確に再現して修正するには、Gitタグに対応するコード状態にフォールバックする必要があります。新しいコードで問題が解決したこともありますが、常にそうであるとは限りません。通常、特定のタグに切り替えて、そのタグからブランチを作成する必要があります。
git checkout v1.0.0
// 切换到分发给客户的标签
git checkout -b bugfix-todo
// 创建新的分支用于重现 bug
Gitは、習得に時間がかかる複雑なツールです。これらのプラクティスを使用すると、チームがGitを共同開発に使用するのに役立ちます。