個人的基本
ローカルで新しいブランチ作成
git branch <new branch>
ブランチ一覧を見る
git branch
ブランチ移動
git checkout <branch name>
ローカルのブランチ削除
git branch -d <branch name>
ローカルのブランチをリモートブランチにpush
git push origin <branch name>
originは省略できませんねー。お願いします。これでgithubに新しくブランチができます。 ちなみに、originはブランチ名ではなく、リポジトリ名です。つまり、githubのリポジトリをoriginで指定しています。
ファイルの差分を確認
git diff <filename>
作業していると、どのような変更を加えたか忘れてしまうこと多いと思うんですけど、これがあると、最後のコミットからどのような変更が加えられたのかが 一瞬でわかります。
個人的中級
## リポジトリの特定のブランチをクローン
git clone -b <branch_name> <repository_url>
issue branchをmainにマージ
まずmain branchに移動。その後、merge
git checkout main
git merge issue
コンフリクトが起こったらその個所を直してコミット！！
個人的上級
プルリクの送り方
前提として、何かしらのossを開発しているものとしましょう。まず、プルリクエストっていう概念は、gitではなく、github上のものなので、ローカルではできませんね。じゃあどうやるか？それを今から説明していくぜ。 まず、github上でforkします。forkしたものをローカルにcloneします。cloneしたものに変更を加えます。そして、githubにプッシュします。で、github上でフォークされたリポジトリから、コピー元となったリポジトリ (これをベースブランチと呼ぶらしいです)にプルリクエストを送るわけですね。 変更メッセージを指定して、レビュアーを指定して、Create pull requestをクリックすればプルリクエストの作成が完了するんですね。そうすると、プル陸タブにプル陸が表示されるようになるんだよね。 れびゅあーに指定できるのは、リポジトリのコラボれーた （共同編集者） となっているアカウント。
ちなみに、企業でいわれているコードレビューっていうのはこのプルリクエストを送る作業のことなんだと思います。 だから、去年のインターンの面接で「コードレビューをしてもらったことはありますか？」って聞かれたときにはい、あります、先生に見てもらってここをこうした方がいいとか、そういうアドバイスをもらいました、って言った俺は、意味が分かっていなかったわけですね。
mergeには3種類ある
- create a merge commit ：もっとも一般的
- squash and merge
- rebase and merge : ブランチを一直線にする
特定のブランチorタグをcloneする
git clone リポジトリ名 -b ブランチorタグ名
いちばんやさしいgit&Githubの教本を読んで新しく学んだこと
forkはgithub上でリポジトリをコピーすること。
git clone はリモートリポジトリをローカルのリポジトリにコピーしてくること。forkはgithub特有の単語だということ。
もともと主にリリースバージョンとして使われるブランチ名はmasterってブランチという名前だったが、人権問題からmaster/slaveっていう言葉を使うのがよくない、っていうムーブメントが2020に起こって、mainブランチに変わったという運びらしい。まったく、面倒くさいけどその過程もまあ、面白いよね。
短期的に使う作業用のブランチのことを「トピックブランチ」というみたいです。まあ、何か新しい機能を既存のソフトに付け加えたいときとかは、トピックブランチを作って、マージするっていうのがもういつもの流れですね。
git checkout <branch_name> があるけど、これと同じ機能を持つコマンド、git switch<branch_name>もあるので、忘れずに
プルリクエストは「github」が提供している機能！これ大事です！はい。
pullとfetchは違う。pull = fetch + merge。だから、ただリモートブランチをとってきたいだけの時はgit fetchで持ってこよう。ローカルに反映されていないように見えるが、ちゃんと反映されているので。
やはり、コンフリクトは人間が手動で直さないといけないところです！mergeするときに発生します。直してマージしましょう。
新卒研修を経ての学び
ブランチの切り方
まず、設計が終わった段階で、コンポーネントごとにIssueを立てる。んで、イシューには番号がつくからそれでどの機能を実装しているかをわかりやすくする。 まあ結局機能ごとにブランチを切るのだが、こんな感じになる。
git checkout -b feature/#IssueNumber_Verb_Objecteive
って感じです。よろピクミンです。
そもそもどんなブランチがあるか？だけど、まあまずmainブランチがあるよね。これはもう本番用だよね。 次にdevブランチ。これはリリース前の一応動く状態のコードを置いておくところだよね。うん、そうですね。ここを基準にfeatureブランチをどんどん切っていく感じになるね。 そうですね。で、featureブランチで特定の機能の実装が終わったらdevブランチにマージしていくって感じで開発が進んでいきます。よろピクミンですね。
プルリクの出し方とコードレビューの仕方
プルリク出すのやったことなかったから難しいって思っていたけど、全然そんなことなかったんだよね。マジで。ただ単に切ったブランチをリモートで編集して、それをgithubにpushしてgithub上でそのブランチをどのブランチにマージするかを決めるだけ。バカ簡単やん、っていう。レビュアーとかを選んで、レビューしてもらってって感じですね。
その他、勉強になったこと
git status
で今のブランチの状態がわかります。状態ってのはファイルの変更箇所とかだね。これはgit diffのブランチ版。どこが変更されたのかが一瞬でわかるっていう便利ツールだね。
- 一括ステージング
git add <ディレクトリ>
で、ディレクトリ以下で変更が加わったファイルが全てステージングされる。これは結構便利だと思った。