gitバージョン管理ソフトウェアの以前のチュートリアルでは、gitを使用するための基本的な基本コマンドを次のように学習しました。また、Github.comを使用してリポジトリを確立し、プロジェクトコードをウェブサイトにプッシュする方法も説明します。
次に、GitHub（およびgit）を本来の方法で実際に使用し始めます。使用済み：プロジェクトに安全に一方の側で変更を加え、正しいことが証明されたら元のプロジェクトにマージします。または、少なくとも悲惨なことではありません。
これで、gitはプロジェクトの各バージョンを、コミットしたときとまったく同じようにコードのスナップショットとして保存することを理解しました。基本的に、プロジェクトの進行に合わせてバージョンのタイムラインを作成し、災害が発生した場合に以前のバージョンにロールバックできるようにします。
gitとGitHubがこのタイムラインを管理する方法は、特に1人以上がプロジェクトで作業し、変更を加えています—ブランチを使用することです。ブランチは基本的に、一意の名前を持つ一意のコード変更のセットです。各リポジトリには、1つ以上のブランチを含めることができます。メインブランチ—すべての変更が最終的にマージされてマスターと呼ばれるブランチ。これはプロジェクトの公式の作業バージョンであり、github.com / yourname / projectnameのプロジェクトリポジトリにアクセスしたときに表示されるものです。
マスターをいじらないでください。他の人が作業しているときにグループプロジェクトのマスターブランチに変更を加えると、その場での変更が波及して他のすべての人に影響を及ぼし、すぐにマージの競合、しだれ、衣服の貸し出しが発生します。とイナゴの疫病。とても深刻です。
マスターが混乱しないように重要なのはなぜですか？一言：マスターブランチはデプロイ可能です。それはあなたのプロダクションコードであり、世界に展開する準備ができています。マスターブランチは安定することを目的としており、テストされていないものやビルドを壊すものをマスターにプッシュしないことは、オープンソースソフトウェアの社会契約です。 GitHubが機能する理由は、マスターからの作業が常に安全であるためです。
ブランチアウト
代わりに、マスターから作成されたブランチを使用して、実験、編集、追加、変更を行います。 、承認されて機能することがわかったら、最終的にそのブランチをマスターにロールバックする前。次に、マスターが更新されて、すべての新しいものが含まれます。
プロジェクトで新しい作業を開始したり、既存のものを変更したりするには、安定したマスターブランチからブランチを作成します。前のチュートリアルで作成したサンプルプロジェクト、古き良きstudious_octo_carnivalで作業を続けましょう。コンピュータでバージョンを開いて、ディレクトリにcdしてください。
ステップ1：インベントリを作成します。
新しいブランチを作成する前に、他の既存のブランチを確認します。 。私たちはマスターについて知っていますが、私たちのプロジェクトの協力者が何をしているのか、いたずら好きなサルを誰が知っていますか？したがって、ターミナルに「git branch -a」と入力すると、既存のすべてのブランチを表示できます。これにより、ローカルワークスペースにないブランチも含め、このプロジェクトのすべてのブランチを表示するようにgitに指示されます。
これにより、以下のコード例に示す出力が返されます。外観はOSとターミナルアプリケーションによって多少異なる場合がありますが、情報は最終的には同じです。出力の最初の行の「master」の横にあるアスタリスクは、現在そのブランチにいます。 2行目は、originという名前のリモートに、masterとも呼ばれる単一のブランチがあることを示しています。 （リモートはこのプロジェクトのGitHubリポジトリであることを忘れないでください。）
ステップ2：新しいブランチを作成する
ブランチの表示方法がわかったので、ブランチを作成しましょう。マスターブランチ、つまり元のプロジェクトがあることを覚えておいてください。次に、プロジェクトの新しいバージョンであるブランチを作成して、コンピューター上でローカルで操作したり変更を加えたりします。プロジェクトの元のバージョンであるマスターは、GitHub上で安全に無秩序なままです。新しいブランチには、作業中に何をしようとしているのかを思い出させるために、わかりやすい名前を付けています。この場合、単純な「Hello World」になりますので、hello_octoと呼びましょう。
この新しいブランチを作成するには、「git checkout -bbranchNameHere」と入力します（この場合、 「gitcheckout-bhello_octo」）。
「hello_octo」という名前のブランチを他に誰も作成していないと仮定すると、gitは「新しいブランチ「hello_octo」に切り替えました」を返します。 （その名前のブランチがすでに存在する場合、gitは代わりに「致命的： ‘hello_octo’という名前のブランチがすでに存在します」と通知します。大したことではありません。新しい名前のバリエーションでもう一度gitcheckout -bを実行してください）
git checkoutコマンドを使用して、2つのブランチ間を行ったり来たりすることもできます。 「gitcheckoutbranchName」と入力して、そのブランチに切り替えます。したがって、「git checkout master」を使用するとマスターに移動し、「git checkouthello_octo」を使用するとhello_octoブランチに戻ります。
「gitcheckouthello_kitty」など、存在しないブランチに切り替えようとすると、gitはそれが失敗したことを通知します：
gitは現在どのブランチにいるのかをどのように知るのですか？Gitは常にあなたの行動を監視し、HEADと呼ばれる特別なポインターを保持します。コンパスの針が常に北を指すように、HEADは常に現在使用しているローカルブランチ。
（gitコマンド「gitbranchbranchNameHere」を使用してブランチを作成し、git checkoutでブランチに切り替えることもできます。ただし、 「gitcheckout-b branchNameHere」の「-b」は、ブランチを作成し、それに切り替えます。新しいブランチに変更することを覚えていないため、エラーメッセージとフラストレーションを生成する新しいgitコーダーの数はわかりません。 iを作成した後t。したがって、私たちはgit checkout -b、mmmkay？）
作業ブランチに変更を加える
これで複数のブランチができました—変更を加える作業ブランチと私たちのマスターブランチは安全に無秩序なままです—私たちは仕事に取り掛かることができます。このシナリオでは、「hello_octo」ブランチを使用して変更を加えてテストし、それらをGitHubのマスターブランチにプッシュバックします。
必ず自分のファイルにアクセスしていることを確認してください。古き良きgitブランチ-aを使用して、マスターではなく作業ブランチを作成します。
ステップ3.「hello_octo_world」という名前の新しい空のファイルを作成します。
（この空白のファイルはデモンストレーション用であるため、ファイル拡張子の名前/タイプがないことを心配する必要はありません）。
新品なので、そうです。現在、このファイルはブランチにのみあります。 「ls」コマンドを使用して表示します。
ただし、作業ブランチhello_octoにいることを思い出してください。私たちはこの新しいものを作成しました。マスターはhello_octoがないことについて何も知りません。これは、ここで作業ブランチで行っている意地悪な変更から安全に隔離されているためです。これは、私たちが始めたのと同じ静かに変更されていないマスターです。
ステップ4：新しいファイルをステージングして作業ブランチにコミットします。
今がその時です。新しいファイルをステージング（追加）して、作業ブランチにコミットします（おなじみですか？）。これにより、この新しいエンティティが作業ブランチにアタッチされ、最終的にマスターに移動する準備が整います。このファイルはhello_octoブランチに存在します。上で見たように、現在マスターブランチには存在しません。
この時点で、ブランチへの変更のスナップショット。実際のプロジェクトでは、より多くの変更と作業が行われる可能性があります。 行われなければ。今がこれを行うときであり、論理的なポイントで途中でコミットを行います。 GitHubでは、コミットは連続した保存を表すことに注意してください。各コミットには、コミットメッセージが関連付けられています。これは、そこで何をしたのか、その理由を具体的に説明する説明です。コミットメッセージは変更の履歴をキャプチャするため、将来、あなたや他のプロジェクトの貢献者は、あなたが何をしたのか、そしてその理由を理解できます。
ブランチ間のコードのマージ
最終的にすべての変更と追加が完了し、すべてが機能します*。マージするときが来ました。興味深い部分は、マスターブランチに戻った後です（これは、「git checkoutmaster」で行います）。「Hello_octo_world」は欠落しているように見えますが、そうではありません。現在、作業中です。ブランチと私たちはマスターブランチにいます。これは、gitのブランチを理解する上で中心的な役割を果たしているため、もう一度お見せします。
今：この演習では、「hello_octo_world」は、開発ブランチでのすべてのテストに合格し、本番環境で使用する準備ができているファイルへの変更（またはまったく新しいファイルの追加）を表します。ブランチ間でコードを移動するプロセス（多くの場合、開発からプロダクション）はマージと呼ばれます。
非常に重要です。マージするときは、マージするブランチにいる必要があります。基本的に、gitに「新しいことを確認しますか？ここに持ってきても大丈夫です。」
ステップ5：作業ブランチの変更をマージする
この場合、「hello_octo_world」がある作業ブランチからマージするためです。ファイルが存在します。マスターブランチには、マスターにいる必要があります。
マスターブランチになったら、mergeコマンドを実行するだけです。これを行う最良の方法は「」と入力することです。 git merge –no-ff “—追加の” –no-ff “は、マージ前にすべてのコミットメッセージを保持することをgitに指示します。これにより、将来の変更の追跡が容易になります。
GitHubに戻る
最後に行う必要があるのは、GitHubに私たちが一緒に遊んでいることを知らせることです。ここでローカル開発環境をマスターしてください。
つまり、gitpushの時間です。これを取得しました！
git出力は、ローカル環境の開発ブランチからマスターブランチへのマージを確認します。これで、リモートサーバーに「マスター→マスター」がコピーされました。
これで完了です。マスターとは別の作業ブランチを正常に作成しました。変更を加えました。ステージングしてコミットしました。次に、それらをマージしました。ローカルの作業環境でマスターに戻ります。最後に、すべてをGitHubにプッシュして、プロジェクトのすべてのバージョンがどこでも同じになるようにします。
最後の注意
いくつかのクリーンアップhello_octoブランチが正常にマージされたため、不要になりました。マージされたブランチを削除するには、「git branch -dbranchName」と入力します。
心配ありません：まだマージされていないブランチを誤って削除しようとすると、gitはエラーをスローします。
だから！これまで、非常に単純化されたサンプルプロジェクトを使用してきました。この時点で最も重要なことは、gitワークフローを理解して同化することだからです。現実の世界では、マージにはこれ以上のことがたくさんあります。たとえば、マージに競合があるためにエラーメッセージが表示された場合はどうなりますか？心配はいりません。新しいgit-sterです。
宿題：サンプルプロジェクトでさらにいくつかの新しいファイルを作成（「タッチ」）し、変更、ステージング、コミット、そして最後にそれらのマージを練習します。戻る。HEADが指している場所、つまり現在のブランチが何であるかを理解するように注意してください。作業ブランチにのみ変更をコミットします。
覚えておいてください：しないでください。混乱しないでください。マスター。