初めに
gitを使い始めて一年間で使ったコマンドたちをメモしてきた
その中でも、「あーこいつらには助けてもらったぜ」といった主力コマンドたちを紹介していく。
ここで紹介するコマンドを理解して覚えておけば、ある程度後は調べてやっていけると思う。
と、その前にgitを使うに当たってgitbashかsourcetreeを使って操作することが多いと思う。
まだ新卒でどちらにも慣れていないならgitbashを使うのをおすすめする。
理由は、以下の点だと思う。
- OSが変わったりしたらSourceTreeなどGUIが使えなかったりするので1から覚えなおす必要がある
- gitbashを使った操作の方が早いし、自由度が高い
- gitbashの方が情報が多い
最低限覚えておくべきGitコマンド
現状確認
git status
ログ確認
git log
リモートを更新
git fetch --prune
リモートのdevelopからhogehogeブランチをチェックアウト
git checkout -b hogehoge origin/develop
リモートのdevelopブランチをfeatureブランチにpull
// featureブランチへ
git checkout feature
// developをpull
git pull origin develop
ローカルのfeatureブランチ削除
git branch -D feature
//ローカルブランチのfeatureが付いたブランチを一括削除したい場合は以下のような感じでスクリプトを組むと楽
git branch | grep feature | xargs git branch -D
リモートのfeatureブランチ削除
//(空のブランチをpushするイメージです)
git push origin :feature
ワークツリーを見たいとき
git log --graph --date-order -C -M --pretty
現在のブランチと対象ブランチの差分確認
git diff {対象ブランチ}
ブランチ名の変更
git branch -m <変更後のブランチ名>
修正中のファイルを元に戻す
git checkout {ファイル名}
ステージングのファイルをローカルに戻す(addしたのを元に戻す)
git reset HEAD {ファイル名}
直前のコミットに忘れていた修正を反映させたい
git add .
git commit --amend
問題の解決編
今までで何度か遭遇した問題と解決策をまとめておく。
コミットしたけどしなきゃ良かった
解決策
以下のどれかを選択し、実行すればよい
// HEADだけを元に戻す
git reset --soft HEAD~
// HEADとインデックスを元に戻す
git reset HEAD~
//1つまえのコミットまでインデックス、ワーキングツリーも含めて元に戻す
git reset --hard HEAD~
commit直後にコミットメッセージの誤字が発覚した
解決策
(以下のコマンドを打てば、直前のコミットメッセージが出来るのでvimで修正し反映する)
git commit --amend
commit後に不要なファイルがコミットに含まれていたことが発覚した
解決策
(hoge.txtをリポジトリから削除)
// リポジトリのキャッシュから対象のファイルを削除
git rm --cached hoge.txt
// .gitignoreに反映
vim .gitignore
featureブランチをdevelopにマージしようとしたらconflictが起きていた
解決策
// 1.developブランチに切り替えて最新の状態に
git checkout develop && git fetch && git pull
// 2.featureとdevelopブランチのconflictを解決するためにマージ
git merge feature
// 3.IDEやvimでconflictの修正
// 以下のようにconflictの結果が出るので、不要なソースを削除しあるべき状態に修正する
// <<<<<<<HEAD
// [ローカルブランチのコード]
// =======
// [マージするブランチのコード]
// >>>>>>>2384792
// 4.conflictの修正が終わったら
// 問題なければconflict修正を反映させて終了
git commit -m "conflict修正"
// conflict修正を元に戻したい時は、なかったことに
git merge --abort
// 5.conflictの修正をfeatureブランチに反映
git push origin develop:feature
featureブランチで開発中に、一旦hogeブランチの動作確認をしなければいけなくなった
解決策
// 1.一次的にfeatureブランチの修正を退避(修正中はブランチの切り替えができない)
git stash
// 2.退避されたことを確認
git stash list
// 3.hogeブランチに切り替えて動作確認を実施
git checkout hoge
// 4.featureに戻り、退避していた修正を元に戻す
git checkout feature && git stash pop
ちょこちょこ開発していくうちにコミットログが汚くなってきたのでgitログを綺麗に整理
(開発/テスト実装/レビュー修正 など単位ごとにコミットログをまとめるとわかりやすい)
解決策
// 1.1行でコミット履歴を表示してログを確認
git log --oneline
// 2.編集したいコミット履歴分をリベース
// (以下のコマンドはHEADから3つ目までのコミットログを対象にリベースをしています)
git rebase -i HEAD~3
// 3.編集画面でコミットログの修正
// (vimが立ち上がり以下のような画面が表示される)
// pick fa7f98a ほげほげ
// pick 8fffer8 ぴよぴよ
// pick 6fa8f7f がうがう
// ほげほげに全てのコミットを入れたい場合は、こんな感じ
// pick fa7f98a ほげほげ
// s 8fffer8 ぴよぴよ
// s 6fa8f7f がうがう
// 4.編集が終わったら修正を反映
// 修正を反映させて終わりたい場合は
git rebase --continue
// ミスって何もしなかった時に戻したい場合は
git rebase --abort
// 5.最後に修正をpush
// (コミットログが変わるので強制pushでやらないとだめ)
git push -f origin feature
最後に
gitを使っていて、注意されたこと、意識しておけば良かったことをまとめておく。
おそらくこの記事を読んでいるGit新卒のみなさんも注意されたりする内容だと思う。
- gitコミットの前はdiffを見て、本当に反映したいものだけを修正しているか確認する
- 案外不要な修正や誤字をdiffで確認することで未然に防げる
- 自分が実行したコマンドは必ずメモを取っておく
- マジで分からなくなったら先輩に相談もできる。それに同じことを何度も調べるのって馬鹿らしい
- 修正と関係ない場所は、絶対にコミットにいれない
- 最初は結構修正する必要のない箇所を修正してしまい、そのままステージング環境へあげてしまったりする。気を付けよう
- なにをしてくれるコマンドなのか理解しないまま使わない
- ネットで調べるといろんなコマンドが出てくる。とりあえずネットにあったから!で使っていてもその場しのぎに過ぎない
- コミットログは極力きれいにする
- 自分も上手くできていないが、出来るだけ「戻したい単位」でコミットログを切れるとわかりやすい
- 自分で何をするか調べてから、これであっているかの確認を先輩にする
- ただ聞くは成長しない。確認のために聞くのが良い