こんにちは、弱弱エンジニアのやまうちです。
完全に未経験でWEB系開発の会社に転職しました。
なのでそもそも、弱弱にすら到達しておりませんが、言い続けていれば夢は叶うって聞いたので言ってます。
「成功する秘訣は、成功するまで続けること」
これと一緒です。
今回初投稿にて語る内容はGitです！
GitのGの字くらいは知ってたし、一応使ったことはありました(使えるとは言ってない)がGitは沼です。
まだまだ勉強中ですが、チーム開発の超超基礎の部分を復習しながら理解を深めていきます。
ということで自分語りをしたい気持ちを抑えて本題に入っていきましょう！
想定読者
- 未経験でエンジニアを目指してる方
- 新人ときの気持ちを思い出したい方
- やまうちを応援してくれる方
- 暇な方
新人がGitにどんな気持ちで触っているのか知ってください！ｗ
Gitでのチーム開発を復習
一旦軽く雑談。
Gitって便利なんですよ。
チーム開発では特に力を発揮します。
弱弱エンジニアの僕でもわかります。
コミュ障とは程遠い優しい先輩たちが、嫌な顔ひとつせず色々教えてくれるわけです。
その時はふむふむと思いながら聞いてるし、理解しているつもりでも
少し違う状況になると「ん？どういう手順だ？」ってなるんで、やっぱり理解していないんですよね。
基礎では戦えても応用になると手も足も出ない。
弱弱の証です。
ということで
「こんなときはこうする！」
「こうだから！！」
っていうのを新人の僕と学んでいこう！
実際にブランチをイメージしながらやっていきましょう
一旦プロジェクト内容の確認
今回のプロジェクトは会社のHPを作ることにしましょう。
必要なファイルはこれです。
- top.html(トップページ)
- contact.html(お問い合わせページ)
- style.css(上記2ファイル用のCSS)
Aさんはトップページを担当し、Bさんはお問い合わせページを担当します。
CSSはなぜかすでに用意されているので担当者はいません。
が、たまに中身を少しいじります！！←__ここ重要__
プロジェクト始動
AさんとBさんはそれぞれmasterブランチを元に、topブランチとcontactブランチを作成します。
こんな感じです。
top ●
／
master ●
＼
contact ●
同じ位置のmasterブランチからそれぞれtopとcontactに派生しています。
基本的にmasterブランチでは作業しません。
元々CSSファイルは用意されているので、AさんBさんともにサクサク作業を進めていきます。
ここでプチ問題発生！
デザインに軽微な変更発生！！
CSSの変更が必要になりました。
CSSの変更はAさんが担当します。
CSS編集用にブランチを作成しましょう。
css_a ●
／
top | ●
| ／
master ●
＼
contact ●
こんな感じになります。
ちなみにここで__新しい知識が必要__になります！
スタッシュを理解しよう！
それは__スタッシュ__！！！
今回、何気なく新しいブランチを作成しました。
しかし実際は新しいブランチを作成するにあたってこんな手順を踏んでいました。
-
topブランチをスタッシュ(退避)させる -
masterブランチをチェックアウト -
css_aブランチを作成 -
css_aブランチをチェックアウト
それではひとつひとつ確認していきましょう。
1. topブランチをスタッシュ
今回の確認ではここがメインです！
このときすでにtopブランチでは作業を進めていました。
基本的には__今している作業から別の作業に切り替える際は、今の作業を一度コミット__します。
しかしコミットはある程度区切りのいいタイミングでします。
とはいえ別の作業をしなくてはいけないタイミングが、必ずしも区切りのいいタイミングとは限りません。
そんなとき便利なのがスタッシュです！
スタッシュをすることで、今していた作業を一旦退避することができるので、別の作業に取り掛かる環境をつくることができるんです。
おそらくこの辺りは、やってみないと中々ピンとこない部分だと思います。
ですのでこれを覚えておきましょう！！
「今している作業を中断して別の作業をする際は、
キリが良ければコミット、キリが悪ければスタッシュをしてから別の作業をする！」
以上！
2. masterブランチをチェックアウト
1の手順をしたら、次にmasterブランチをチェックアウト(選択)します。
なぜmasterブランチをチェックアウトするかと言うと、css_aブランチをmasterブランチから派生させるためです。
↓こうじゃなくて↓
css_a ●
／
top ●
／
master ●
＼
contact ●
↓こうだということ↓
css_a ●
／
top | ●
| ／
master ●
＼
contact ●
理由としては、今回のプロジェクトではこれがルールだからです！(今決めた)
ですので一度masterブランチをチェックアウトするわけです。
3. css_aブランチを作成
これはもうそのままの意味です！ｗ
4. css_aブランチをチェックアウト
作成したからにはチェックアウトしましょう！ｗ
※3→4の流れはgit checkout -b css_aのコマンドだと同時に行われます。
こんな流れでcss_aブランチを作成しておりました。
マージを理解しよう！
さて、Aさんはcssファイルの編集を完了させました。
作業を完了させたら以下の流れが必要です。
- 編集したcssファイルをインデックスに追加
-
css_aブランチをコミット -
css_aブランチをプッシュ -
css_aブランチをmasterブランチにマージ(プルリクエスト)
さて流れの確認です。
1. 編集したcssファイルをステージングエリアに追加
ステージングエリアに追加...？？？
となっている方に朗報です。
コマンドで言うところのgit addです。あのgit addです！
このコマンドは見たことがある方が多いと思います。
ようするに__このファイルをコミットしますよ__ということを登録する感じです。
今回はcssファイルを編集して、cssファイルをコミットしたいのでcssファイルをステージングエリアに追加します。
2. css_aブランチをコミット
ここで遂にコミットをします。
コミットをすることで、Gitに登録ができます。
Gitに登録をしないことには、Git上に記録として残りませんので、コミットは必ずしましょう！
3. css_aブランチをプッシュ
次に「css_aブランチをプッシュ」の説明をしたいところですが、ここで一つ新しい知識が必要です。
それは__ローカルリポジトリ__と__リモートリポジトリ__です。
ローカルリポジトリとリモートリポジトリについて
まずリポジトリとは？って話ですが、こちらのサイト（ https://wa3.i-3-i.info/word15664.html ）曰く
ファイルなり、プログラムなり、設定情報なり、何らかの「保管場所」をカッコ付けて言った表現
らしいですｗ
ということでローカルリポジトリはローカル(自分のとこ)の保管場所。
リモートリポジトリはリモート(みんなが使うクラウド上)の保管場所です。
ですので基本的な流れとしては
- 自分で編集したファイルの変更をローカルリポジトリに記録する
- ローカルリポジトリに記録したものを、リモートリポジトリにも記録して共有する
ざっくりですがこんな感じになります。
では本題に戻りまして、css_aブランチをプッシュについて説明します。
2.でコミットを行いましたが、このコミットはローカルリポジトリ上で行われただけであって、
みんなが共有して使うリモートリポジトリには一切反映されていません。
ではどうするかと言いますと、__プッシュ__です。
そう、__プッシュ__です！
※大事なことなので2回言いました
プッシュしたことによって、リモートリポジトリのcss_aブランチもローカルで更新した内容と同じ状態になります。
4. css_aブランチをmasterブランチにマージ(プルリクエスト)
プッシュして終わりではありません。
元々css_aブランチはmasterブランチから派生したブランチです。
よってcss_aはあるべき場所に帰ります。
「俺自身がmasterブランチになる事だ」
※イメージ画像↓
チョサクケンダイジ
別にmasterブランチになるわけではないですが(おい)、masterブランチに合流させます。
これで__cssの編集がされたmasterブランチが完成__します！
ちなみに(プルリクエスト)とありますが、これはマージをするにあたって別の人にマージしても大丈夫かどうかの確認をしてもらいます。
チーム開発ですので、しっかり確認作業が入るわけです(ﾟ∀ﾟ)b
プルを理解するの巻
さてプルを理解するために、もうひとつストーリーを追加していきましょう！
といいながらストーリーは使いまわしますｗ
内容は・・・、またまた軽微なデザイン変更だ！！！
次はBさんにcssファイルの変更を任せるとするZE☆
ということでBさんにもこの流れで作業してもらうとしましょう。
-
topブランチをスタッシュ(退避)させる -
masterブランチをチェックアウト -
css_bブランチを作成 -
css_bブランチをチェックアウト
実はこれには罠があります。
ちなみに今のリモートリポジトリはこんな感じです。
css_a ● － ● ←cssファイル更新
／ ＼
top | ● ｜
| ／ ｜
master ● － － － － ●
＼
contact ●
ちょっとわかりずらいですが、css_aがcssファイルの更新を終えmasterにマージされています。
●印はコミットされたという印です。
topとcontactはまだ一度もコミットしていないので、状況は変わっていません。
ということでもう一度これを確認。
-
topブランチをスタッシュ(退避)させる -
masterブランチをチェックアウト -
css_bブランチを作成 -
css_bブランチをチェックアウト
これの問題点は2と3の流れにあります。
3で新しくブランチを作成していますが、ブランチを作成する際は派生元(今回でいうとmaster)のブランチを最新の状態にしてブランチを作成する必要があります。
ですので正しい流れはこうなります。
-
topブランチをスタッシュ(退避)させる -
masterブランチをチェックアウト -
masterブランチをプル -
css_bブランチを作成 -
css_bブランチをチェックアウト
これをした場合としなかった場合のリポジトリを確認してみましょう。
↓ますがしなかった場合↓
css_a ● － ● ←cssファイル更新
／ ＼
top | ● ｜
| ／ ｜
master ● － － － － ●
| ＼
contact | ●
＼
css_b ●
更新前のmasterブランチからcss_bが派生しています。
↓こっちがした場合↓
css_a ● － ● ←cssファイル更新
／ ＼
top | ● ｜
| ／ ｜
master ● － － － － ●
＼ ｜
contact ● |
＼
css_b ●
例によってわかりずらいですが汗、意図は伝わるでしょう！！？？！？！
そのmasterからcss_bのブランチが作られるかという部分が違ってきます。
なぜこういった違いができるのかを説明します。
今回は新しく追加された「masterブランチをプル」という部分に絞って説明していきます。
3. masterブランチをプル
まずプルについて簡単に説明します。
リモートリポジトリにある更新内容を、ローカルリポジトリにも反映させる。
こんな感じです。
よくわからん！って思った方はググってくださいｗ
再掲ですが3でmasterブランチをプルする前のリモートリポジトリです。
css_a ● － ●
／ ＼
top | ● ｜
| ／ ｜
master ● － － － － ●
＼
contact ●
では現在、これからcssファイルを編集するBさんのローカルリポジトリはどうかというとこうです。
master ●
＼
contact ●
非常にシンプルです。
BさんのローカルリポジトリにとってAさんが作業している、topブランチやcss_aブランチは関係ないんですね。
しかし勘違いしてはいけない点もあります。
__ブランチは関係なくても、更新内容は関係ある！！__んです。
そう、ブランチは関係なくても、更新内容は関係ある！！
※大事なことなので(ry
ですのでこの時点で、Aさんがcssファイルを編集した結果が反映されているmasterブランチがありますので、これをプルする必要があります。
そうするとBさんのローカルリポジトリがこうなります。
master ● － － － － ●
＼
contact ●
masterブランチが最新の情報をGETしました！
そしてこのmasterブランチからcss_bブランチを作成することでこうなります。
master ● － － － － ●
＼ ｜
contact ● |
＼
css_b ●
これで作業する準備が整いました！！
あとは作業をして、上の方でも説明した
- 編集したcssファイルをステージングエリアに追加
-
css_bブランチをコミット -
css_bブランチをプッシュ -
css_bブランチをmasterブランチにマージ(プルリクエスト)
これをして、また作業する！
こんなことを繰り返しながらプロジェクトが進んでいきます。
そんなこんなでプロジェクトは進んでいく
なんとなくは知っていましたが、プロジェクトをチームで進めていくにあたってGitは非常に重要な存在です。
便利な半面、難しさも日々感じております。
まだまだ使いこなすには時間が掛かりそうです(¯―¯٥)
なんだかpull、fetch論争的な感じのこともあるみたいですが、
まずpullとfetchのそれぞれの使いわけを正確にできるかというと出来ない！
と自信を持って言える自分がいるので、先は長そうです汗ｗｗ
覚えることが鬼のようにあって日々四苦八苦しておりますが、強強エンジニアになるべく頑張ります。
2週間に1記事くらい書けたらいいなぁって感じですのでよろしくお願いしますm(_ _)m