お帰りなさい｡
前回のビデオに引き続き､ より高度なワークフローとGet and GitHubについてお話ししましょう｡
さて､ ここまでは､ Marcyも私も､ こちらのブランチマスターで作業していたところです｡
どういう意味ですか？
ブランチと書いてありますが､ ここにはマスターしかありませんね｡
そして､ そのやり方に1つ問題があることにお気づきでしょうか｡
つまり､ 勤務初日でタイトルを変更しただけの場合です｡
でも､ もしかしたら､ その変化さえも望んでいなかったかもしれません｡
もしかしたら､ それが私たちのブランディングを壊し､ アプリを壊してしまうかもしれません｡
でも､ Masterに変えるのはとても簡単にできました｡
マーシーも知らなかったのかもしれない｡
その変更点を追記しました｡
そして､ それは大きな問題ですよね｡
私たちがプロダクションと呼ぶ､ ユーザーが目にするものには入れたくないのでしょう｡
もし､ 当社のウェブサイトが壊れるようなことがあれば､ Facebookのような大企業であれば､ たとえ数時間のバグであっても､
数百万ドルの収益が失われることになりかねないのです｡
そこで､ より現実的なワークフローとして､ ブランチングを使ったものをご紹介します｡
どういうことか､ お見せしましょう｡
ジェドが本当に得意としていることを､ こちらでビジュアル化しました｡
これまでは､ マスターと呼ばれるものを作っていました｡
それがmasterブランチです｡
masterブランチを権威と考えましょう｡
これが､ 私たちのアプリやウェブサイトの正しい姿なのです｡
そして今までは､ クールな背景のタイトルを付けたら､ まあ､ 背景ジェネレーターからクールジェネレーターになったんですけどね｡
そして､ マーシーが大文字に変えてから､ ここに行き､ 端から端まで一直線に進んでいったんです｡
でも､ さっきも言ったように､ それはちょっと問題ですね｡
そこで､ より良い方法として､ ブランチングと呼ばれるものがあります｡
タイトルを変更したい場合は､ ブランチを作成して､ 例えば､ little featureと呼ぶだけにします｡
そして､ masterブランチに影響を与えないように､ そのブランチで勝手に作業しているだけなんです｡
ユーザーが見るもの
と｡
完成して､ マーシーが確認し､ テストして､ チームの全員がOKを出したときだけ､
マスターに戻すんです｡
そして､ こちらの大きな機能を見ていただければわかると思いますが､ 自分のブランチで長い時間続けて､
終わったときだけ｡
masterへのマージと呼ばれる作業を行います｡
今日はその方法を紹介します｡
これを最後に､ 私たちの例を思い出してください｡
マーシーのコンピュータにはすべてのファイルがあり､ 私のコンピュータにもすべてのファイルがあります｡
二人ともワークステーションを設置しています｡
ターミナルに表示される master の意味がわかったと思います｡ この後のノートで､ どのブランチにいるのかを表示させる方法を説明します｡
でも､ お互いがMasterの上にいることがわかる｡
それは私のパソコンです｡
そして､ マーシーのパソコンもマスターに｡
お互いに最新のGitHubを利用するようにしたいですね｡
だから､ マーシーがゲットプルをやって､ 私もゲットプルをやるんです｡
なぜなら､ マスターで作業しない方が良いワークフローだからです｡ これは一般的に良いヒントですが､
マスターで作業しないで常に分岐させるようにしましょう｡
もし､ 私がBranchを手に入れたら､ それを見せてくれるでしょう｡
ブランチは1つだけで､ それはmasterです｡
しかし､ それにプラスアルファすることができます｡
私たちは､ 新しい､ あるいは小さな機能を手に入れることができます｡
そして今､ もし私がブランチを手に入れたら｡
私はリトルフィーチャーを持っていますが､ マスターは現在マスターなのでハイライトされていますね｡
だから､ 私がリトルフィーチャーブランチに行く方法は､ Get check outと言うんです｡
小さな機能｡
そして､ リトルフィーチャーブランチに切り替えると､ リトルフィーチャーブランチになりました｡
そこで､ マスターから分岐して､ 小さな機能を作りました｡
ちょっとした変化を生み出そう｡
小特集で､ 現在のCSSの背景のタイトルを変更して､ これが背景ですと言うことにしています｡
ここなら安全だ｡
そしてまた､ 前回のビデオで行った簡単なワークフローでステータスを取得するのです｡
なるほど､ そうなんですね｡
ええ､ インデックスがあるんです｡ htmlを変更しました｡
晴れるから見えるようになる｡
では､ この変更を行ったので､ get addを行いましょう｡
そしてまた､ すべてがうまくいったかどうかを確認するために､ ステータスを取得するのです｡
そうですね｡
インデックスをコミットする準備が整いました｡ htmlでコミットすると､ コミットメッセージが変更されたテキストが表示されます｡
完璧です｡
それをクリアしよう｡
そしてまた､ 私たちが行うべき変更を GitHub に知らせるために､ プッシュを取得します｡
だから､ 私たちはプッシュすることにしています｡
わかりました｡
GitHubにアクセスして､ 何が起こったか見てみましょう｡
黄色いバーが表示され､ 「最近ブランチをプッシュしました」と表示されているのがわかります｡
ここで画面のボタンをクリックすると､ compare､ pull､ requestとなるわけです｡
タイトルを変更し､ マーシーに「マーシー､ テキストを変更したよ」と知らせることができます｡
いかがでしょうか？
そして､ Create Pull Requestをクリックします｡
そして､ 私のPRができ､ ここにmerge pull requestsと書かれているのがわかると思います｡
さて､ 図に戻ると､ この小さな機能を作って､ 「Hey Marcy, I'm just done this
new change」と言います｡
いかがでしょうか？
Masterにマージしても問題ないでしょうか？
そして､ おそらくここで起こることは､ Marcyがこのプルリクエストを見に来ることでしょう｡
プルリクエストのタブにあるのがわかると思います｡
だから､ 彼女はそれを見て､ 「ああ､ アンドレはこの変化をやったんだ」と分かるようになるのでしょう｡
彼女は変化に目を通す｡
そして､ 彼女は､ うーん､ もし彼女がこれを好きなら､ 良さそうだ､ と言うかもしれませんね｡
彼女はレビューを開始するをクリックすることができます｡
そして､ ご存知ですか？
彼女はこれが好きなのか､ それとも承認するつもりなのか｡
さて､ マーシか私か｡
通常､ 自分自身のプール要求をマージすることはありません｡
チームの誰かがやるんです｡
今ならマージと言えばいいのか｡
引っ張る｡
要求､ 確認する｡
マージする｡
そして､ そこにあるのは
チームによっては､ ブランチを後から削除するのが好きなところもあるので､ ここで削除をクリックすればいいのです｡
コードに戻ると
まあ､ 削除しただけなので､ もう枝はないんですけどね｡
しかし､ 私のマスターでは､ もし私がインデックスに行くなら｡ html なるほど､ これが背景なんですね｡
だから､ マーシは自分のプロジェクトに出向いて､ 「引っ張ってこい」と言えるようになったのです｡
そして､ もう一度｡
彼女は最新の情報を持っています｡
では､ 起こりうるコンフリクトについてお話します｡
さて､ マーシーが何かを変えようとしているときに､ 私も同じものを変えてしまい､ マージコンフリクトが発生したとします｡
どうなるか見てみましょう｡
例えば､ Marcyが新しい機能を作りたい場合､ これを1つの大きな機能と呼ぶことにしましょう｡
そして､ 彼女はチェックアウトを取るか､ ブランチを取るか､ と言うでしょう｡
大きな特徴です｡
彼女は言うだろう､ 大きくチェックアウトするように｡
特徴
そして､ ブランチを取得すると､ ここに新しいブランチがあることがわかります｡
それをクリアしよう｡
そして､ 「タイトルが変わってしまったので､ 背景色や背景ジェネレーターに戻したい」と､
ここで言うでしょう｡
だから､ 彼女はそれを変えたのです｡
ゲットアドを行ったそうです｡
コミットメントを取得する｡
旧タイトルに戻す｡
完璧です｡
そして､ 彼女はゲッツプッシュをするつもりだ｡
あ､ 実は最初にそこをクリアしておこう｡
そして､ 私たちはプッシュを受けるのです｡
初めてだと「上流がない」とこのようなエラーが出ることがあります｡
ここで渡されるコードをコピーするだけです｡
完璧です｡
今､ 戻れば｡
発電機に戻る｡
こっちには大きな機能のプルリクエストがあるんですね｡
また､ 複数のコミットができることを示すために､ Marcyが､ ああ､ これは私だ､ と決めたとしましょう｡
マーシーは､ ここで感嘆符をつけることにした｡
彼女はまた､ これを保存していると言えばいいのです｡
それは明らかです｡
彼女はGet Addと言うだろう｡
コミットメントを取得する｡
あなたはこれをよくやるので､ しばらく会社で働くと本当に､ getが上手になり､
彼女はAdded X exclamationと言うでしょう｡
おっとっと｡
だから､ 私がやりたいのは､ コミットすることです｡
コミットする｡
エクスクラメーションを追加しました｡
そして､ 彼女は再びプッシュされるでしょう｡
そして､ 助けを求めに戻ろう｡
貧乏くじを引くと､ 実は両方とも古いタイトルに戻して､ 感嘆詞をつけることになるんです｡
そして､ こちらでは､ 両方の変更がプルリクエストに必要な変更を作成していることがわかります｡
アンドレ
だから､ この世論調査の依頼があるうちは
とりあえず､ Let's just call it conflictという新しいブランチを立ち上げることにしたんだ｡
そして､ コンフリクトをチェックアウトする｡
そして今､ コンフリクトブランチに｡
変わろうと決心する｡
これは､ ちょうどクールジェネレーターを完全に除去するためです｡
それを保存しておく？
もう一度｡
自分のステータスとインデックスを確認する｡ htmlファイルが変更されました｡
そこで､ この間にマーシにプルリクエストをマージしてもらう｡
だから､ 彼女はそれをマスターに入力したのです｡
彼女のプルリクエストが入りました｡
そして今､ 私が自分のコンフリクトに戻り､ ステータスを得ることができたとします｡
そして､ これらを追加する必要があります｡
だから､ "Add "して "Commit "する｡
ここでは短いメッセージにとどめます｡
確認するだけでいい｡
そして今､ 私が師匠に戻ったら｡
あ､ やらなきゃいけないんだ｡
チェックアウトして､ もう一度マスターしてください｡
変更をプッシュする前に､ 最新バージョンのマスターがあることを確認したいのです｡
だから､ 何も変えていないんです｡
コンフリクトを起こさない
だから､ 最新情報を得るためにゲットプルをするんだ｡
そして今､ 私はチェックアウトを受けに行く｡
コンフリクトブランチ
そして､ このコマンドゲットもできるんです｡
マスターをマージします｡
だから､ マスターであれば何でもコンフリクトに融合させろと言ってるんです｡
マーシが大特集を組んでくれたので､ マージしてくれました｡
これでMasterは大きなフィーチャーブランチを手に入れたわけです｡
また､ 別のブランチを作成し､ コンフリクトブランチでの作業も自分で行っています｡
そして､ conflictブランチはmasterのことを何も知らないのです｡
だから､ 今Masterにあるもので､ Marciが手がけた大きな機能も含めて､ それを取り込んで､
競合がないようにしよう､ と言っているんです｡
だから､ そうしているんです｡
そして､ ああ､ 私はコンフリクト・マージ・コンフリクトとインデックスを手に入れたんだ｡ htmlファイルです｡
では､ 実際にサブライムテキストをクリックすると､ よく見えるようにこれを開いてみましょう｡
まいったなぁ｡
この変な構文が出るんです｡
最初は圧倒されますが､ 何が起こっているのかがわかりやすいのです｡
ヘッドが私の分岐点であり､ ここで最後まで私はもうHなものは持っていないのだと示しています｡
しかし､ masterブランチにはバックグラウンドジェネレーターがあります｡
マーシーに､ 「マーシー､ バックグラウンド・ジェネレーターのタイトルはそのままでいいかい？
そして､ 彼女は､ そうだ､ あれは正しいことだったんだと言うだろう｡
背景は変えないでください｡
まあ､ その場合は､ この行を削除すればいいんですけどね｡
そして､ これを削除してください｡
そして､ 保存する｡
今､ 私が手に入れたら｡
現在の状況
なるほど｡
こちらは修正済みの状態です｡
もう一度､ 小さくして見てください｡
だから､ これをクリアにするんだ｡
このままでは､ 変更を加えたので､ 再度追加を行い､ コミット修正とマージを行わなければなりません｡
を忘れてた｡
もう一度やってみよう｡
と｡
マージの不具合修正
ここをクリアして､ ステータスを手に入れましょう｡
何も約束しない､ 掃除する
そして､ もしプッシュされたとしても､ またこのエラーが出ます｡
でも今回は､ もしプッシュ型のオリジンコンフリクトが起きたら､ それを見せたいんです｡
動作するようになりました｡
GitHubに戻りましょう｡
どんなものがあるのか見てみましょう｡
コンフリクトブランチを見てみると､ 何も変わっていないことがわかります｡
だから､ 完全に空っぽなんです｡
今と変わりはないんです｡
だから､ マーシーは､ 「おい､ このPRをするつもりだったのか､ 空っぽだぞ」と言うんです｡
だから､ PRにこのメッセージが表示されるから､ 続けられるんです｡
そして､ これがGETで見ることのできるワークフローとほぼ同じです｡
この後､ コマンドを残しておきます｡
でもね､ あなたと一緒に仕事をして､ いくつかのコマンドを覚えて､ 何か作業するたびに必ずブランチを作るという視覚的なモデルさえあれば､
とてもとてもいいんです｡
そのタイトルには､ 今作っている機能を書きます｡
そしてたまに､ 他の開発者やチームメイトが行ったアップデートを見逃さないために､ master をプルして自分のブランチに
master をマージしたくなるものです｡
機能が完成したら､ get pushでプルリクエストを作成し､ そのプルリクエストにコメントを追加して､ 人々があなたのファイルの変更をレビューするようにします｡
また､ 少し変更してほしいということであれば､ again, get, add, get commitをすればいい｡
最後に変更を加えて､ マージ､ プル､ リクエストすることができます｡
そして､ それが終わると､ 今度はチームのみんなが新しいマスターになるんです｡
だから､ チームの他のみんなも引っ張ってきてほしいんだ｡
慣れるまで少し時間がかかりますが､ チームの全員が同じファイル､ 同じプロジェクトで作業していることを確認し､
エラーを起こさずに､ 全員がうまくコラボレーションできるようにするための､ 本当に素晴らしいワークフローです｡
そして､ それだけです｡
ご参考になれば幸いです｡
次回作でお会いしましょう｡
バイバイ｡