tl;dr
- GitとGithubは完全に別物(GUIがあることからGithubに目が行きがちだが、Gitの基本を学ぶのが良い)
- 学んだことは, Staging, Commit (Githubへのmerge), 機能を足していくときはどんどんbranchを作って分けていくようにします
- コードを書いて機能を追加していくときには、Branchをどんどん分けていく。そうしないと間違いが起こったときに戻りづらく、レビューもしづらい ex. feature-A, feature-B ... etc.
基本的なコマンド
| COMMAND | ACTION |
|---|---|
| Shortcuts | |
| git init | gitを初期化 |
| git status | 各ファイルの状態などを確認 |
| git add * | add FILENAME にてfileをstagingする |
| git commit | stagingしたファイルをコミットする。メッセージページを抜け出すのは Esc > :wq! |
| git commit -m "COMMENT" | メッセージページに入らずに、そのままコメントを書けるパターン |
| git push | remote (Github)にpushする |
| git fetch | remote (Github)をlocalに持ってきて、差異を判別する |
| git merge BRANCHNAME | 上記fetchしたbranchをローカルのbranchにMergeする |
| git pull | fetchとMergeを一気にやる。個人開発で内容把握しているとかでない限りは、fetchして確認した方が良さそう |
| git log | git の過去ログを確認 |
| git log graph | git の過去ログをグラフ状態で確認。閉じるにはq |
| git reflog | git の過去ログを消えてしまったものも含め確認 |
| git diff | ファイルのUpdate箇所をチェック |
| git diff HEAD | HEADが現在あるファイルとの違いをチェック |
| git checkout BRANCHNAME | 指定したbranchに移動 |
| git branch | 存在するbranchを確認 |
| git checkout -b BRANCHNAME | 新しくbranchを作成し、そこに移動する |
| git reset OBJECT | 指定した過去のOBJECTに状態を戻す。Defaultは(--mixed)となり、戻る地点までのCommitはStaging前の状態に戻る。ローカルファイルは変更されない |
| git reset --soft OBJECT | 指定した過去のOBJECTに状態を戻す。--softの場合、pointerが指定したObjectまで戻るが、Commitやローカルファイルはそのまま |
| git reset --hard OBJECT | 指定した過去のOBJECTに状態を戻す。--hardの場合、戻る地点までのCommitはStaging前の状態となり、ローカルファイルも変更される |
| git reset HEAD~NUMBER | git resetの書き方違い。現在のHEADから数えて何番目に戻るかを数字で指定できる |
| git revert | git resetと似ているが、違いとして、resetは戻ることにより、logを消す。revertは消さない。通常はrevert推奨とのこと |
今回やってしまったこと
今回そもそもどういう事象が起こって、Gitを調べてみることになったのかをメモ的に残します。
今回起こっていたこと
test branchを作ってコードを書いていたはいいが、そのままずっとtest branchを更新し続けました
今回起こっていると思っていたこと
Githubにてtest branchをmergeしていたため、Localでもmergeされているものだと思ってしまっていた。そのため、git logを見たときにmainが想定した場所に存在せず、混乱してしまいました
修正後
-
git resetを使い、追加機能ごとにbranchをわけました。実際は練習用に個人開発しているだけなので、無理やりmergeすることも可能だったが、せっかくの勉強の機会と思い理想と思う形まで変更しました。 - 途中、
conflictが発生し、解決しないといけなくなりました。機能ごとに疎の状態で開発することが大切なんだと感じました。Object Oriented Programingのカプセル化にも通ずるものがあると思いました。
Last comments
- 今回、意図せずしてGitを学習することになりましたが、今までなんとなく使っていたコマンドの意味がわかったのは良かったです。
- またこれまで使っていなかった
branchや名前だけ知っていたconflictについて学べたのも有意義だったと思います。 - 機能ごとに分けることによって、レビューもしてもらいやすく、またコードを書くときもどの機能を追加しているのか、意識しやすくなるため、個人開発でもやるべきだと思いました。