しばらく何も書いてなかったので書きます
今回はgitで
100億人ぐらいが書いていると思われるgitの入門記事です。
「何をしたいか」に対してgit上でどういう操作をすればいいかを書きます
コマンドとかは最近はGUIでgitの操作をできるような環境もあるので省きます(というか、その辺りは各々ググってください)
やりたいこと：自分の環境にコードを持ってくる
すでに走っているプロジェクトがあったとして、サーバーにあるソースコードを自分の環境に持ってくる必要があります。
その時に使うのがClone(クローン)です。
やりたいこと：操作の履歴を残す
開発している時に、「あれ？昨日はどんなコードだったんだっけ？」と思う時がくると思います。そんな時のために自分の書いたコードの履歴を記録しておかないといけません。
その時に使うのがCommit(コミット)です。
Commitはあくまで「自分の作業内容をローカルに保存する」行為です。サーバー側には反映されません。
この記事を読んでる人に覚えておいて欲しい内容として「いつコCommitするか」があります。
以下の通りです
・トイレに行く前にCommitしてください
・お昼休憩の前にCommitしてください
・コーヒーを飲む前と飲んだ後にCommitしてください
要するにいつでもコミットしていいです。というか、事あるごとにCommitしましょう。
５分に1回鳴るタイマーを用意してその度にコCommitしてもいいです。
ちなみに、Commitをする時にはコメントを残せます。将来のためにコメント書いときましょう
やりたい事：操作の履歴をサーバーに反映させる。
ローカルで編集した内容をサーバー側に反映させることで他の人が見ることができたり、他の人がそのコードを自分自身の環境に持って行って検証したりすることができるようになります
そんな時に使うのがPush(プッシュ)です。
「いつpushするか」ですが、Commitする時に同時にpushしてください。以上！
やりたい事：昔の状態に戻したい
「昨日はちゃんと動いてたのに、今日は動かない・・・」。なんて時にはソースコードを指定したところまで巻き戻したくなりますよね
そんな時に使うのが「CheckOut(チェックアウト)」です。
CheckOutすると、過去のコミットに戻れます。どこのコミットに戻りたいかを選んでCheckOutしてください
やりたい事：他の人の編集を自分の環境に反映させたい
他の人がバグを修正してpushしたのであれば、それを自分の環境に取り込み自分の環境でもバグが出ないようにしたいですよね。
そんな時に使うのが「Pull(プル)」です。これをすると、他の人の変更を自分の環境に取り込むことができます。
この時、他の人が触ったところと自分の触ったところが重なっている場合、警告が出ます。この場合、自分か他人かのどちらかのコードを選んで修正します。
やりたい事：他の人がどれぐらいコードを触ったか確認したい
他の人がどんな作業をしたかを知りたいですよね
そんな時に使うのが「fetch(フェッチ)」です。
これを使うと他の人がgit上で行った作業を確認できます。ただし、自分の環境には何も影響を与えません。
やりたい事：他の人に影響を与えずに開発がしたい
あなたが書いたコードにバグがあり、それをpushしてしまったらどうなるでしょうか？
あるいは、コンパイルが通らないコードをpushしてしまったらどうなるでしょうか？
そんな時に使うのが「Branch(ブランチ)」です。「ブランチを切る/作る」なんて表現を使います。
これをすると、オリジナルと別のバージョンが作成されます。そのため、あなたがpushをしてもこのバージョンに反映されるため他の人には影響を与えません。
この別バージョンのことを「ブランチ」と呼びます。
ブランチを切るという作業は、要するに「派生バージョンを用意する」ことです。なので、ブランチを切る時は「どのバージョンの派生バージョンを用意するか」を指定しなければいけません。
作ったブランチからさらに別のブランチを切ることもできます。
やりたい事：自分が触りたいバージョンのソースコードを自分の環境に取り込みたい
例えば、先輩の触っていたバージョン(=ブランチ)ではあるバグを修正するということを行っていたとします。
それを引き継ぐことになった場合に、そのバージョン(=ブランチ)を丸っと自分の環境に持って期待ですよね。
そんな時に使うのが「checkout(チェックアウト)」です。
これを使うと別のバージョン(=ブランチ)に飛ぶことができます。
やりたい事：他のバージョンの変更を自分のところに取り込みたい
オリジナルのバージョンから自分はAバージョン、先輩はBバージョンを作ったとします。
Bバージョンで変更したバグの修正内容を自分のバージョンにも取り込みたいですよね
そういう時に使うのが「Pull(プル)」です。さっきも出てきましたね。
実はPullでは「どのバージョン(=ブランチ)から変更を取り込むか」を決めることができます。
ブランチを指定してPullすると今の自分のブランチとPullするブランチの差を自動的に検出して、差分を取り込んでくれます。
ここでも修正箇所が重なっていると警告が出ますので、どちらを優先するかを決めてコードを修正します。
やりたい事：自分のバージョンでの変更を他のところに反映させたい
これまでのPushでは、あくまで自分が触っているブランチしか更新させることができませんでした。
せっかくバグを潰したんですから、自分の触っているブランチで変更した内容を他のブランチに反映させたいですね
そんな時に使うのが「Merge(マージ)」です。
他のところに反映させるわけですから、Mergeの際には「どのブランチに反映させるか」を指定してあげる必要があります。
この時も衝突が発生する場合がありますが、このタイミングで衝突が起こるのを避けることができます。
その方法は、「Mergeの前にそのブランチからPullする」です。こうすることで今からMergeしようとしているブランチとの衝突箇所をチェックでき、衝突を避けることができます。
また、自分の書いたコードがMerge先のブランチに混ぜるとうまく動かない可能性もあります。そういったことを避けるために、Merge先のブランチからPullすることで自分のブランチの状態を「Merge先のブランチに対してMergeを行った場合と同じ状態」にして検証をして問題がないかどうかを確認してMergeする方がいいです。
やりたい事：Mergeする時に他の人にチェックしてほしい
自分だけでマージするのではなく、他の人に「この内容でMergeして問題ないか？」を見てもらった方がいいですね。
そんな時に使うのが「MergeRequest(マージリクエスト)」 または「PullRequest(プルリクエスト)」です。
GitLabとGitHubで用語が違うだけでやってることは一緒です。
「誰にチェックしてもらいたいか」を指定してRequestを投げると、指名された人が変更内容をチェックし、問題なければマージをしてくれます。
開発の流れ
ここまでの内容をまとめて、開発の流れを見ていきましょう
1.環境構築の際にサーバーにあるソースコードを自分の環境にCloneします
2.あなたにタスクが割り振られます。他の人に影響が出ないように、そのタスク専用のBranchを作ります。今回は「develop」という名前のブランチから「bug-fix-hogehoge」という名前のBranchを切りました。
3.作ったBranchで作業をするために、そのBranchにCheckOutします。
4.あなたはその環境で作業をします。事あるごとにCommitとPushを行います。
5.ようやく作業が終わりました。developブランチにMergeしたいところではありますが、他の人がdevelopブランチを触っているかもしれません。まずはfetchして、変更内容を見て見ましょう。
6.fetchしたところ、developブランチに変更があったみたいです。developブランチから自分のbug-fix-hogehogeブランチにpullしてきて、問題がないか確認して見ましょう。
7.pullをして見たところ、衝突が発生していたみたいなので、エラーが起きないように修正しました。
8.修正をしてテストをしてみると、ちゃんと動きました。一安心ですね。「developブランチからpullしてきましたが、あくまでも衝突箇所の修正はbug-fix-hogehogeブランチで行っている」のでちゃんとcommitとpushをして起きましょう。これで、bug-fix-hogehogeブランチの状態は「現時点でのdevelopブランチに自分の行なった作業内容をマージしても大丈夫な状態」になりました。
9.developブランチにbug-fix-hogehogeブランチの内応をマージします。念のため、Mergeによってdevelopブランチに対しておこる変更を確認しましょう。
10.問題なさそうですね。先輩に対してMergeRequest/PullRequestを投げましょう。これであなたのタスクは終わりです。次のタスクがあなたを待っています。2に戻りましょう。もし、先輩からダメだしを食らったら3に戻りましょう。