0
0

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 3 years have passed since last update.

【git】日常的に使うgitコマンドとそれを使う理由(?)のまとめ

Posted at

はじめに

自分が日常的に使っているgitコマンドとそれを使う理由(?)のようなものを備忘録がてらまとめる

なお、チーム開発かつGitHubやBitbucketなどを利用することを想定している

変更をステージング

$ git add [ファイル名]

全ての変更を一括でステージング(あまり使わない)

これはあまり使うべきでないかと(個人的な意見)
そのコミットに含めるべきでない変更点までコミットしてしまう危険性があるため

$ git add .

コミット

コミットメッセージは英語でも日本語でも良いので基本的につける

$ git commit -m "コミットメッセージ"

リモートのhogeブランチにプッシュ

たまにプッシュに失敗することがあるが、リモートリポジトリの権限が原因であることが多い気がする
リポジトリをいじれる権限が与えられているか、sshkeyが追加されているか、など確認すれば解決は難しくないはず

$ git push origin hoge

rebaseした後はローカルとリモートのブランチで整合性がとれないため、強制プッシュする必要あり
(rebaseについては後述)

$ git push -f origin hoge

リモートのhogeブランチをプル

プッシュと同じく、失敗することがたまにあるが、原因はプッシュできない場合とおそらく同じ

$ git pull origin hoge

ローカルにあるブランチ一覧の確認と現在いるブランチの確認

$ git branch

ローカルブランチの削除

例えば、feature/hogeブランチをリモートにプッシュし、そのブランチがリモートでdevにマージされた場合、ローカルのfeature/hogeブランチは不要になる
不要なブランチは削除する必要あり

$ git branch -D feature/hoge

最新のコミット確認

$ git show

ログ確認

基本的に見やすくなるためのオプションをつけて使う

# オプションなし
$ git log

# 見やすくするためのオプション
$ git log --graph --oneline

ブランチの分岐点を修正する

rebaseを使う
rebaseは共同開発でめちゃくちゃ使う
developブランチに対してrebaseすることが多いかと

※厳密には、rebase=ブランチの分岐点を修正、ではないので注意

# 現在のブランチをdevelopブランチにrebaseする
$ git rebase develop

rebaseを使う場面

基本的な開発は以下の流れで進むと思う

  • developブランチからfeature/hogehogeなどといったブランチを切って作業する
  • 作業終了後、developブランチにマージするようなプルリクエストをGitHubやBitbucket上で作成する
  • プルリクが承諾されたらいよいよマージ

このマージされる段階で、feature/hogehogeブランチはdevelopブランチの先端から生えている必要がある
もし先端から生えていない(つまりfeature/hogehogeブランチを作成したときよりもdevelopブランチが進んでいる)場合、rebaseが必要になる

コミットをまとめる

こちらでもrebaseを使う

# 最新のコミットとその1つ前のコミットをまとめる
$ git rebase HEAD~~

上記のコマンドを叩くと、vimエディタが開き、下記のようなものが表示されるかと

pick コミットID コミットメッセージ
pick コミットID コミットメッセージ

上記を下記のように修正

pick コミットID コミットメッセージ
s コミットID コミットメッセージ

コミットメッセージを編集する画面に移るので、編集すればOK

参考
rebase -i でコミットをまとめる - Qiita

一時退避、stash

別のブランチに移動して作業したい
でも、現在のブランチでの変更はコミットしたくないし、変更点を他のブランチに持っていくこともしたくない(addする前の変更点はブランチ移動すると一緒に持っていくことができてしまう)

そんな時にstashを使う
名前やメッセージをつけてstashすると管理しやすいかと

# 現在stashされているものの一覧確認
$ git stash list

# 名前というかメッセージをつけてstashする
$ git stash save [メッセージ]

# stashしたものを戻し、stash一覧から削除
# nはstashした際に自動的に振り分けられる番号、stash listで確認できる
$ git pop stash{n}

後からgitignoreを適用させる

.gitignoreファイルに無視したいファイルを記述しても、すでにgit管理下にある(追跡されている)ものは無視してくれない
このような場合、対処法は2パターン

その1

# キャッシュを全て削除(git管理下から全て削除)する方法
$ git rm -r --cached .

その2

# .gitignoreファイルの内容を反映させる方法
$ git rm --cached `git ls-files --full-name -i --exclude-from=.gitignore`

上記のいずれかをやった後、addしてコミットすればOK

参考
あとからまとめて.gitignoreする方法 - Qiita

さいごに

rebaseコマンドを使う部分に関しては、誤解を生むような表現を用いている可能性が高く、また、本記事通りのコマンドを使っても上手くいかない場面も多いかと思うので、別途調べていただければ

修正点や追加点などあれば随時更新する

0
0
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
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?