GitHub での開発では、特に試行錯誤を行う場合に、非常に多くのブランチを作成することが必要になる場合があります。幸いなことに、このプラットフォームを使用すると、仮想ワークスペースを整理し、不要なブランチをトリミングしてコミット履歴を整理し、重要なことに集中し続けることが簡単になります。
この記事は、GitHub でちょっとした整理を行うのに役立ち、Git ブランチとその削除に関するいくつかのヒントとテクニックを提供することを目的としています。
Git でのブランチの削除
Git でブランチを削除するのは複雑ではありませんが、ブランチの場所によって手順が少し異なる場合があります。ローカル Git ブランチを削除する方法は次のとおりです。
削除したいブランチに移動します。
ターミナル
を開いて
git ブランチ
を実行し、すべてのブランチを表示します。
削除したいブランチにいる場合は、
git checkout [other_branch_name]
を使用して切り替えます。
git Branch -d [branch_name]
を使用してブランチを削除します。 -d フラグを使用すると、マージされていないブランチが削除されないようにすることができることに注意してください。
リモート ブランチの削除は少し異なります。
git Pushorigin –delete [branch_name]
を使用します。
git Branch -a
を使用してすべてのブランチをリストし、正しいブランチを削除したことを再確認します。
ブランチを削除する理由
Git のブランチの削除は、さまざまな理由から開発者が頻繁に行うことです。
プロジェクトのクリーンアップ
機能ブランチをメイン ブランチまたは開発ブランチに正常にマージした後、その機能ブランチが冗長になることがよくあります。これは、デジタル形式でのプロジェクト完了後のワークスペースのクリーンアップと考えてください。
最終製品の準備ができたので下書きやスケッチが必要なくなるのと同じように、Git では、このクリーンアップによって乱雑さが軽減され、アクティブなブランチに集中できるようになります。たとえば、アプリで新機能をリリースし、「新機能」ブランチをマージしたばかりの場合、マージ後にブランチを削除すると、ブランチ リストの関連性が維持され、管理しやすくなります。
間違いと実験
他の種類のプロジェクトと同様に、すべてのアイデアが開発でうまくいくわけではありませんし、すべてのブランチが機能の成功につながるわけでもありません。場合によっては、ブランチが誤って作成されたり (間違った名前で「git checkout -b」と入力したり)、短期間の実験に使用されたりすることもあります。
これらのブランチが積み重なって混乱し、プロジェクトが乱雑になる可能性があります。それはすべて、コーディングの学習と実験において自然な部分です。新しいライブラリを試すためにブランチを作成することもできます。それがあなたの期待に沿わないなら、それを保持しておく理由はありません。
チームを順調に進める
チームで作業しているとき、特に複数の人がさまざまな機能に取り組んでいるときは、リポジトリをクリーンで整理された状態に保つ意欲がさらに高まります。古いブランチや無関係なブランチは人々を混乱させ、エラーを引き起こす可能性があります。
これらのブランチがなくなると、チームの全員が同じ認識を持つ可能性が高くなります。また、誤って古いコードを操作してしまうリスクも回避できます。 Web アプリケーションに取り組んでおり、「login-update」や「new-ui」などの完成した機能のブランチがまだ残っていると考えてください。誤解を招く可能性があります。これらの枝を剪定すると、作業したいものを簡単かつ安心して見つけることができます。
ベストプラクティスとヒント
ブランチを削除するときは、次のヒントを考慮してください。
削除前のバックアップ
ブランチの削除ボタンを押す前に、まずブランチをバックアップすることが賢明です。ブランチがもう必要ないのに、なぜそれが必要なのでしょうか?なぜなら、そのブランチにまだ必要なコードや特定の実装があったことに、少し遅れて気づくことがあるためです。
git Branch [backup-branch-name] [branch-to-delete] のように、別の名前でブランチのコピーを作成することでバックアップを作成できます。こうすることで、そのブランチに再度アクセスする必要がある場合でも、すべてを安全に保管できます。
強制削除は慎重に使用してください
「-D」フラグは Git ツールキットの強力な機能ですが、使用には注意が必要です。このコマンド (git Branch -D [ブランチ名]) に大文字の -D (強制削除) を指定すると、ブランチが強制的に削除されます。警告を表示する小文字の -d コマンドとは異なり、このコマンドはマージされていない変更を無視し、データを永続的にパージします。
このコマンドは、ブランチの変更を保持する価値がなくなったと確信している場合、またはマージが失敗して最初からやり直したい場合に便利です。ただし、使用する前に必ず再確認してください。
リモート参照のクリーンアップ
ブランチをリモートで削除した後、そのブランチを誤って参照しないように、そのブランチへのローカル参照をクリーンアップする価値があります。コマンド「git fetch –prune」はまさにそれを行います。これは、ローカル Git に対して、存在しなくなったリモート ブランチへの参照を削除するように指示し、ローカル リポジトリを最新の状態に保ち、無関係なブランチとの混乱を回避します。
よくある落とし穴とその回避方法
ブランチの削除には、特に何かを削除するつもりがなかったために決定を急いだ場合、いくつかの落とし穴がある可能性があります。そうした落とし穴のいくつかと、それに陥ることを避ける方法を見てみましょう。
失われた仕事
Git でブランチを削除する際の最大のリスクの 1 つは、貴重な作業が失われることです。これは通常、変更を他の場所に完全にマージまたは保存する前にブランチを削除した場合に発生します。単純なエラーが原因である可能性もありますが、技術的な問題が原因である可能性もあります。たとえば、インターネット接続に問題があるか、コンピューターのバグが考えられます。
これを避けるために、ブランチからのすべての価値のある変更またはコミットがメイン ブランチまたは開発ブランチに反映されたことを再確認してください。 git log [ブランチ名] を使用してコミット履歴を確認し、何を保持する必要があるかを確認できます。実験的なものやメインブランチの準備ができていないものに取り組んでいる場合は、タグ付けやスタッシングなど、別の方法で保存することが良い解決策になる可能性があります。アイデアのスケッチと同様、今は必要ないかもしれませんが、後で役立つ可能性があります。
チーム内の混乱
チームの一員として作業している場合、特にチーム メンバーが変更に気づいていない場合、ブランチを削除すると他のチーム メンバーが混乱することがあります。グループ プロジェクトに取り組んでいるときに、使用する予定だったツールが誰かに削除された場合、ワークフローが大幅に混乱する可能性があります。
したがって、何かを削除する前に、チームのメンバーに相談して、削除してもよいかどうかを確認してください。ブランチをパージすることにした場合、特に他の人が同じブランチを使用または監視する可能性がある場合は、チームに通知してください。これには、問題トラッカーやチームチャットなどのツールが役立ちます。
また、各ブランチの目的と削除しても安全かどうかを説明する、ブランチの命名規則 (たとえば、「feature/」、「bugfix/」など) を用意しておくとよいでしょう。ブランチを廃止する必要があると考えた場合は、そのブランチはもう役に立たないので片付けてもよいことを他の人に知らせてください。
Git の整理整頓
クリックする前に考えれば、Git ブランチを削除するのは簡単です。そうしないと、誤って削除したために重要な作業が失われることになり、非常にイライラする可能性があります。開発者のチームで作業している場合は特にそうです。しかし、ここで効果的なコミュニケーションが重要になります。
ブランチの削除で失敗したことはありますか? Git でブランチを処理するためのその他のヒントはありますか?以下のコメントセクションであなたの考えやヒントを共有してください。