70
61

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

1年間開発して使ったgit commandまとめ

Posted at

よく使うgitのcommandをまとめてみました。まとめるのに使ったコマンドは下記の通り

history 1 | sed -e 's/^ *[0-9]* *//g' | sed -n -e '/^git/p' | sort | uniq -c | sort -k1 -n

なお、SourceTreeを併用しているため、SourceTreeでやりにくいコマンドがメインです。1年間で使ったコマンドが下記26個というのは多いのか少ないのか

1位: 600回 git checkout ブランチ名

ブランチを切り替える

1人で開発してるわけではないので、master/develop/feature/hotfix/releaseのブランチを行ったり来たりする必要性があります

2位: 382回 git rebase -i HEAD~数字

コミットをまとめる

メンバーの共有財産であるレポジトリをかっこ悪いコミットで汚さないようにマージリクエストを出す前には綺麗にまとめましょう

3位: 374回 git push --force-with-lease origin git rev-parse --abbrev-ref HEAD

現在のブランチをoriginに強制pushする

rebaseしまくってるので、強制pushしまくってみたいですねw

4位: 351回 git rebase ブランチ名

別ブランチの変更を取り込む

mergeで取り込む方法もありますが、rebaseで取り込んだ方が歴史が綺麗になるので私はこっちを使っています

5位: 261回 git pull

remoteの変更点を取得する

開発する前にはとりあえず変更を取り込んでおくことは大事です。これをしておかないとコンフリクトしたりとややこしい><

6位: 243回 git branch

ブランチを確認する

間違えてmasterブランチやdevelopブランチを変更してしまわないようにチェックしましょう

7位: 237回 git stash

変更を一時退避する

rebaseする前やpullする前に必要になることがあります

8位 132回 git stash pop

git stashで一時退避した変更を戻す

stashした回数に比べて半分ぐらいという不思議・・・git stashをreset代わりに使ってしまっているんでしょうね

9位: 124回 git checkout -b 新しいブランチ名

新しいブランチを作成して切り替える

新規開発を始める際には基本的なコマンドです

10位: 108回 git push origin git rev-parse --abbrev-ref HEAD

現在のブランチをoriginにpushする

強制pushする必要性が無いならば、こっちを使ったほうが安全でいいです

108回 git reset

git reset HEAD~数字 HEADから数字分前のコミットへとresetする
git reset HEAD@{数字} git reflogで管理されているHEADから数字分前の状態へとresetする
git reset --hard origin/ブランチ名 originのブランチへとresetする(主に強制pushされた場合にlocalとoriginの歴史の食い違いを解消するために用いました)
git reset コミットハッシュ 特定のコミットへとresetする

git resetがあるからちょっと危険なことをしても大丈夫みたいな安心感はありますね

74回 git fetch

remoteの変更点を取得する。ただし、pullと違ってmergeはしない

主な使いみちとしてはpullできない状態(強制pushされた場合)で、git fetch && git reset --hard origin/ブランチ名という感じに取り込む場合ですかね。後はただ単にcheckoutするためとか。

59回 git commit -m "コメント"

変更をコミットする

少ないのはSourceTreeに頼っているからです。GUIある方がaddとかdiffとかがわかりやすいです。

43回 git rebase --continue

rebaseを続ける

git rebaseでコンフリクトした場合に解消して続きを実施する場合に用います

43回 git clone リポジトリのURL

リポジトリを複製する

cloneするのは最初だけなので回数は少ないですね

39回 git blame ファイル名

ファイルの変更履歴を確認する

主に不具合のあるコードが確認された場合にいつからだろうか(犯人は誰だw)と確認するために使います。他にもよくわからないコードを書いた本人に尋ねるためにも使います(コミットログも確認できます)

35 git cherry-pick コミットハッシュ

ハッシュで指定したコミットを取り込む

主にdevelopやmasterに不具合が混入した時にhotfixを作成するために用いました

35回 git diff

git diff 変更点を確認する
git diff ファイル名 指定したファイルの変更点を確認する
git diff --no-prefix HEAD > パッチファイル名 HEADからの変更部分のパッチを作成する

diffはSourceTreeで確認するのがわかりやすいんですが、たまに使っていたようです。

35回 git add ファイル名

指定したファイルを変更内容として追加する

commitと同様にほとんどSourceTreeで作業していたので回数が少ないです

34回 git rebase --abort

git rebaseを中止する

コンフリクトが酷い場合にやり直すために用いました

31回 git merge ブランチ名

指定したブランチの変更をマージ取り込みする

mergeは嫌いなのでほとんどrebaseで取り込んでいます。これが必要なのは開発にgitlabを用いており、gitlab上でmergeができない時の手動マージ処理のためですね。

17回 git status

作業ツリーの状態を表示する

これもSourceTreeで確認するのがわかりやすいです。コマンドはほとんど使わないです

12回 git reflog

gitの全ての操作ログを表示します

間違えてreset --hardしてしまった時やブランチを削除してしまった時など、通常のgit操作で戻せない時に助かります

6回 git revert

git revert コミットハッシュ 通常のコミットを戻す
git revert -m 1 コミットハッシュ マージコミットを戻す

develop/masterに取り込まれたコミットを戻す時に使いました

3回 git gc

gcコマンド

2回 git log -p ファイル名

指定したファイルの変更履歴をたどる

git blameと似たような使い方で、何か不具合が見つかった時にどのような経緯なのかを確認する時に使いました

70
61
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
70
61

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?