2018年に生活するためのソフトウェアを作成する場合、自信を持って「Gitに精通している」と言えます。 Linus Torvaldsによって作成されたツールは、バージョン管理の代名詞になりました。間違いなく、Gitの最も優れた機能の1つは、分岐とマージの苦痛を取り除く方法です。 Gitでブランチを作成する方法はいくつかあります。この投稿では、それらのいくつかを確認します。次に、Gitの分岐モデルと一般的な分岐について少し考察します。

マスターからの分岐の作成

当然のことながら、branchコマンドを使用してGitでブランチを作成します。他の多くのGitコマンドと同様に、「branch」は非常に強力で柔軟性があります。ブランチの作成に加えて、ブランチの一覧表示と削除にも使用でき、さらにカスタマイズできます。パラメータの幅広いリストを使用してコマンドを実行します。まず、ブランチを作成する最初の方法から始めます。 「my-app」という名前の新しいフォルダを作成し、それを入力して、新しいGitリポジトリを開始するとします。これは、まさにその方法です。

mkdir my-appcd my-appgit init

これで、新しい空のGitリポジトリができました。しかし、空のリポジトリは退屈です。では、「HelloWorld！」と書かれた新しいマークダウンファイルを作成するのはどうでしょうか。

echo Hello World! > file.md

「gitstatus」を実行すると、ファイルが追跡されていないことを示すメッセージが表示されます。

ただし、追跡されていないファイルもクールではないので、追跡しましょう：

git add file.md

最後に、最初のコミット：

git commit -m "First commit"

これで、コミットが1つだけのブランチが1つあるリポジトリができました。これは、世界で最もエキサイティングなことですが（実際にはそうではないため）、コミットがまったくないリポジトリを持つよりも確かに退屈ではありませんよね？さて、何らかの理由でファイルを変更する必要があるとしましょう「コンテンツ。しかし、あなたはしません」そうする気がします。何かがうまくいかず、ファイルの美しく手付かずのコンテンツをどうにかして台無しにした場合はどうなりますか？ （ええ、私はそれが「Hello World！」を含む単なる愚かなファイルであることを知っていますが、あなたの想像力の素晴らしい力を使用して、ファイルをはるかに複雑なプロジェクトのプロキシと考えてください。）このジレンマの解決策もちろん、新しいブランチを作成します。

git branch exp

これで、実験用に「exp」という新しいブランチができました。 。異なるバージョン管理システム、特に集中型システムの使用に慣れている人の中には、ブランチが同じ「コンテンツ」を持っていると言う人もいます。ただし、Gitについて話すとき、これは完全に正確ではありません。特定のコミットを指す参照のようなブランチを考えてください。

コミットからブランチを作成する

何らかの理由で、単一のコミットを追加せずに実験をあきらめたとします。新しいブランチにコミットします。マスターに戻ってexpブランチを削除しましょう：

git checkout mastergit branch -d exp

これで、単一のブランチに戻りました。実行中の作業をシミュレートするために、いくつかのコミットを追加しましょう。

この「作業」をすべて実行した後、何らかの理由で、そこに戻って時間を遡る必要があることを想像してみてください。ファイル内の2行だけで、それ以降は新しい変更を作成します。ただし、同時に、すでに行った進行状況を保持する必要があります。つまり、過去のコミットからブランチを作成する必要があります。これをどのように行いますか。 ？Gitでは、各コミットに一意の識別子があるため、「git log」コマンドを使用してこれを簡単に確認できます。特定のコミットに基づいて新しいブランチを作成するには、そのハッシュをパラメータとしてブランチコマンドに渡すだけです。

git branch new-branch 7e4decb

余談ですが、ほとんどの場合、ハッシュ全体を必要とすることすらありません。最初の5〜6文字で十分です。

タグからブランチを作成する

Gitの経験が少しある場合は、Gitに精通している必要があります。タグの概念。タグを使用して、特定のコミットが何らかの方法で重要または特別であることを示します。たとえば、タグは通常、製品の実際のバージョンを示すために使用されます。アプリケーションでしばらく作業していて、バージョン1.0をリリースするときが来たと思います。通常は、必要に応じてバージョン番号を上げ、それらの変更をコミットしてから、その特定の時点にタグを追加します。タグを作成するには、通常、次のようなものを実行します。

git tag -a v1.0 -m "First major version"

「-a」パラメータは、これが実行されることを示します注釈付きタグになります。軽量タグとは対照的に、これは本格的なGitオブジェクトであり、コミッターの名前と電子メール、タイムスタンプ、メッセージなどの情報が含まれています。これでタグが作成されました。これは、履歴のこの特定のポイントが特別で名前が付いていることを示しています。いいね。 1.1バージョンの一部となる変更を作成してコミットし、通常どおり作業を続けることができます。バグレポートが届くまで。1に更新された一部のクライアント。製品の0バージョンは、インポート機能が意図したとおりに機能していないと言っています。理論的には、マスターブランチのバグを修正してデプロイできます。しかし、クライアントは、テストされていない可能性のある不完全な機能を受け取ることになります。 -番号。それで、あなたは何をしますか？答え：メジャーバージョンを示すために作成したタグから新しいブランチを作成します。そこで問題を修正し、ビルドしてデプロイします。その後、これをマスターにマージして、次のリリースに修正が含まれるようにする必要があります。 。それについてどうしますか？簡単：

git branch <NAME-OF-THE-BRANCH> <TAG>

より具体的には、前の例を使用します：

git branch fix-bug-123 v1.0

その後、通常どおり新しいブランチをチェックアウトできます。さらに良いことに、すべてを1つのステップで実行できます。

git checkout -b fix-bug-1234 v1.0

分離されたヘッド状態でブランチを作成する

過去にさかのぼりたいと思ったことはありますか？Gitではこれが可能です…少なくともリポジトリ内のファイルに関しては、ハッシュがわかっている場合はいつでもコミットをチェックアウトできます：

git checkout <SHA1>

それを実行すると、Gitは奇妙なメッセージを表示します：

You are in "detached HEAD" state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

チェックアウト時コミットすると、特別な状態になりますcご覧のとおり、「切り離されたHEAD」です。この状態で変更をコミットすることはできますが、それらのコミットはどのブランチにも属していないため、別のブランチをチェックアウトするとすぐにアクセスできなくなります。しかし、これらのコミットを保持したい場合はどうすればよいでしょうか。当然のことながら、答えは使用することです。新しいブランチを作成するには、もう一度「checkout」コマンドを実行します。

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

もちろん、これで、最後の2行を1つのコマンドとして：

git checkout -b new-branch-to-keep-commits

とても簡単ですよね？

できるから…「すべきではない」

Gitの分岐モデルは、そのセールスポイントの1つです。これにより、他のソース管理システムでの苦痛で遅いプロセスが簡単になります。 Gitは大衆向けのブランチの民主化に成功しましたが、深刻な危険があります。Gitでのブランチの安さのために、一部の開発者は、非常に長寿命のブランチで作業したり、ワークフローやブランチモデルを採用したりして、統合を遅らせるという罠に陥る可能性があります。すりおろし。私たちは業界としてそこにいました。私たちはそれをしました。それは機能しません。代わりに、非常に短命なブランチを採用するワークフローを採用してください。 「ものを壊したり、同僚を無駄にしたりすることを恐れずにコーディングできる安全なサンドボックスがあります」。しかし、「部分的に完成した機能を備えたコードをデプロイするにはどうすればよいですか？」という質問がありますか？その場合、それは救助のための機能フラグです。Gitブランチは強力なツールです。それらを賢く使用し、乱用しないでください。また、「十分でない場合は、継続的デリバリー/継続的インテグレーションと、自由に使える専用ツールを含む機能フラグを採用して、アプリケーションを次のレベルに引き上げることができます。