はじめに
開発実務でgitを使用するようになり、毎回調べながら操作するのに時間を取ってしまうため、使用する機会が多いgit操作をまとめたいと思います。
エンジニアとして実務を始める方、エンジニア志望で勉強されている方に有益な情報となれば幸いです。
作業の流れ
チーム開発の基本的なgit作業の流れは下記のようになります。
実務でよく使用するgit操作まとめ
変更を取り込む
git merge:変更を取り込む
- 別ブランチの変更を取り込むときに使います
- マージコミットとしてコミットが1つ増えることが特徴です
featureブランチをmainブランチにマージする際はこのようになります。
git checkout main
git merge feature
git rebase: 変更履歴をきれいに残しながら、変更を取り込む
- 現在のブランチの内容が、指定したブランチに取り込まれます
- 変更履歴を、指定したブランチの根本に付け替えるイメージで、rebaseする際にコミットが作成されません
- 変更履歴を保持しながら変更を取り込みたいときに使います
featureブランチの内容をmainブランチの上に載せるときはこのようになります
git checkout feature
git rebase main
rebase前後のgitツリーはこのようになります
/* rebase前 */
A--B--C------F--G(master)
\
D--E(feature)
/* rebase後 */
A--B--C------F--G(master)
\
D--E(feature)
変更を元に戻す
git reset: ローカルや他に人が触らないブランチの変更をキャンセルする
- 変更(コミット)のキャンセルを行うことができます
- そもそも前のコミットがなかったかのように、ブランチのポインタを元に戻してくれます
- コミットがなかったように変更されてしまうため、ローカルや他の人が触らないブランチの変更をキャンセルするときに使います
hardはローカル履歴が残りませんが、softはローカル履歴を残しながらコミットを取り消すことができます。
例えば、直前のコミットをローカル履歴を残しながらキャンセルするときはこのようになります。
git reset --soft HEAD^1
git revert:他の人も使っているリモートにあるリポジトリのブランチの変更をキャンセルする
- 変更(コミット)のキャンセルを行うことができます
- 巻き戻したいコミットの上に新しいコミットができます
- 新しいコミットは、コミット内容を巻き戻す変更が含まれます
例えば、最新のコミットのキャンセルを行いたい時はこのようになります。
git revert HEAD
コミットを移動する
git cherry-pick: 現在の位置(HEAD)の下に一連のコミットをコピーする
- 特定のコミットを別のブランチに載せたい時に使用します
// Aのコミットと Bのコミットを現在の位置の下にコピーする
git cherry-pick Aのコミットid Bのコミットid
コミットをまとめる
git rebase
- 不要なコミットをしてしまった場合にコミットをまとめることができます
例えば、最新のコミット2つをまとめたいときはこのようにします。
/* 最新コミットから2つ目までのコミットを確認 */
git rebase -i HEAD~2
- vimなどのエディタが開きます
- まとめたいコミットを、`pick`⇒`s`に修正します
- コミットメッセージを再度修正します
これでコミットが1つにまとまるようになりました。
過去の変更を修正する
git tag: コミットに恒久的なマークを付ける
- ブランチのように参照でき、永久的な印をコミットに付けることが可能です
- ブランチと違い、コミットを新たに作ってもタグは動きません
このようにタグを付与します。
/* C1にタグV1を付与する. */
git tag v1(タグ番号) C1(コミットid)
リモートブランチの内容をローカルブランチに取り込む
git fetch: リモートリポジトリからデータを取得する
git fetchの動作は下記2つあります。
- 引数を付けないと、リモート上に存在する全てのブランチのコミットをダウンロードします
git fetch
- 下記例では、リモートのfooブランチに移動して、ローカル上に存在しないコミットを全てローカルのorigin/fooブランチにダウンロードします
/* git fetch <remote> <place> */
git fetch origin foo
- 下記例では、<source>がリモート上の場所になり、<destination>がそのコミットを置くローカル上の場所になります
/* git fetch origin <source>:<destination> */
git fetch origin foo:bar
git pull: リモートブランチの内容をローカルブランチに反映する
リモートの内容をリモートブランチに取り込んで、ローカルブランチにmergeすることができます。
処理としては、下記操作を行ったことになります。
- 下記例では、git fetch origin foo; git merge origin/fooと同じ働きをします
/* git pull <remote> <place> */
git pull origin foo
- 下記例では、git fetch origin foo:bar; git merge barと同じ働きをします
/* git fetch origin <source>:<destination> */
git pull origin foo:bar
git pull –rebase
リモートの内容をリモートブランチに取り込んで、ローカルブランチにrebaseすることができます。
処理としては、下記操作を行ったことになります。
/* git fetch origin foo + git rebase foo */
git pull --rebase origin foo
リモートトラッキングを行いながら、新しいブランチをチェックアウトする
リモートトラッキングとは
方法としては2つあります。
①git checkout -b を使う
/* origin/mainのリモートブランチを追跡する、fooブランチを作成する */
git checkout -b foo origin/main
②git branch -uを使う
/* origin/mainのリモートブランチを追跡する、fooブランチを作成する */
git branch -u origin/main foo
ローカルブランチの内容をリモートリポジトリに反映する
git push
- 引数を付けないと、現在チェックアウトされているブランチの変更がリモートブランチに反映されます。
git push
- git pushに引数を付けると、リポジトリの <place> ブランチに移動し、すべてのコミットを取得します
- その後、リモートの <remote> にある <place> ブランチへ移動し、存在していないコミットをリモートのリポジトリに反映します
- つまり下の例だとローカルのmainブランチの変更をリモートのmainブランチに反映することができます
/* git push <remote> <place> */
git push origin main
引数で、<source>と<destination>を指定すると、pushするコミットがどこから来て(source)、どこへ行くのか(destination)を指定できる
/* git push origin <source>:<destination> */
git push origin foo:main
最後に
いかがでしたでしょうか?
今回紹介した操作を使えば大体の操作が可能になると思います。
もし知らない操作があれば是非使ってみて下さい!
Git: もう怖くないGit!チーム開発で必要なGitを完全マスター
コメント