「[[.NET 開発基盤部会 Wiki>http://dotnetdevelopmentinfrastructure.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>Gitコマンド]] *目次 [#u284e616] #contents *概要 [#n92e3326] -Git pull | アトラシアン Git チュートリアル~ https://www.atlassian.com/ja/git/tutorial/remote-repositories#!pull --git fetch commandとそれに続く git merge commandをひとつにまとめたcommand --以下を一つにまとめたcommand ---git fetch command ---git merge command --rebaseを用いたpull git pull --rebase <remote> --- --[[rebase]]フラグは履歴の直線性を確保してmerge commitを減らす場合に使用する。 ---= 変更作業は皆が変更を完了したものをベースとして行いたい場合に使用する。 ---開発者の多くはmergeよりrebaseを選択する傾向がある。 ---SVN における svn update コマンドに近い。 -初心者でもわかる!リベースの使い方を解説します~ | Git編:一歩踏み出すフロントエンド入門~ http://liginc.co.jp/web/tool/79390 --rebaseを用いたpull git pull --rebase <remote> ---commit履歴がわかりやすくなる --rebaseのinteractiveモード git rebase -i <commit> git rebase --interactive <commit> ---commitメッセージを後から変える ---commitの順序を後から変える ---2つ以上のcommitを1個に統合する ---一度commitした内容を編集する *mergeとrebase [#x478e335] -[Git] 使い分けできていますか?~ マージ(merge)&リベース(rebase)再入門 - The Powerful Code~ http://powerful-code.com/blog/2012/11/merge-or-rebase/ --merge~ featureブランチでの変更のみを統合後に確認する際には都合が良い $ git checkout master $ git merge bugfix --rebase~ 履歴をシンプルにする(履歴の一本化、マージコミットを生成しない)。 $ git checkout bugfix $ git rebase master *使い方 [#ue38c4da] -初心者でもわかる!リベースの使い方を解説します~ | Git編:一歩踏み出すフロントエンド入門~ http://liginc.co.jp/web/tool/79390 **commit履歴がわかりやすくなる [#a23b1e7b] -local branch --<base-branch> に、現在のfeature branchの全commitを適用 git rebase <base-branch> -- = git checkout <branch> && git rebase <base-branch> git rebase <base-branch> <branch> -remote branch -- rebaseを用いたpull~ = git fetch <remote> && git rebase <remote> git pull --rebase <remote> **rebaseのinteractiveモード [#kee7d862] 現在のbranchにある<commit>以降のcommit(commitとmerge commitを含まない)を取り上げて、エディタが立ち上がる。 git rebase -i <commit> git rebase --interactive <commit> 以下のコマンドが使える。 -pick:commitを採用 -reword:commitを採用するがcommitメッセージを変更 -edit:commitを採用するがファイルを修正する -squash:一個前のcommitと合体させる -fixup:commitメッセージを変更しない点以外squashと同じ -exec:shellでコマンドを実行する ***commitメッセージを後から変える [#ld4e5ff7] -直前のcommitメッセージを変える git commit --amend -複数前のcommitメッセージを変える~ interactiveモードで、pickからreword(r)に書き換える ***commitの順序を後から変える [#t32627cd] ・・・ ***2つ以上のcommitを1個に統合する [#jb7088d2] -直近2つのcommitを1個のcommitにする reset --soft -1つ前のcommitと結合する~ interactiveモードで、pickからsquash(s)に書き換える ***一度commitした内容を編集する [#w133372b] edit *注意、使い分け [#w6f53474] -Git - リベース~ https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%AA%E3%83%99%E3%83%BC%E3%82%B9 --公開repositoryにpushしたcommitをrebaseしてはいけない(commit IDが変わる) --mergeとrebase、単純にどちらがよいとは言い切れない。 --良いとこ取りをするなら、pushしていないlocalの変更だけrebaseし歴史をきれいに保つ。 -[Git] 使い分けできていますか?マージ(merge)&リベース(rebase)再入門 - The Powerful Code~ http://powerful-code.com/blog/2012/11/merge-or-rebase/ **mergeを利用する方法の特徴 [#hf8222d1] ***良い点 [#h2c1c6fd] -比較的、簡単な操作 -統合されるブランチのコミットを改変しない -統合後もブランチの情報を分離して保持(後から確認するのが容易) ***悪い点 [#a4ff79dc] (特に、複数人が並行して同じブランチ上で作業をする際には、) -多数のブランチの情報が残存したり、 -マージコミットが散在したりすることで、 履歴が複雑化する原因になる **rebaseを利用する方法の特徴 [#ob006be1] ***良い点 [#ma11e4c1] 不要なコミットが入り込むことがないので、直感的かつシンプルに履歴を保つ ***悪い点 [#c03c9201] -競合発生時の対処手順が、比較的、複雑 -統合されるブランチのコミットを改変するので注意が必要 *参考 [#j99386d7] -Git pull | アトラシアン Git チュートリアル~ https://www.atlassian.com/ja/git/tutorial/remote-repositories#!pull -初心者でもわかる!リベースの使い方を解説します~ | Git編:一歩踏み出すフロントエンド入門~ http://liginc.co.jp/web/tool/79390 -Git - リベース~ https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%AA%E3%83%99%E3%83%BC%E3%82%B9 -サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ --5. rebase -i でコミットをまとめる【チュートリアル3 コミットを書き換えよう!】~ http://www.backlog.jp/git-guide/stepup/stepup7_5.html --6. rebase -i でコミットを修正する【チュートリアル3 コミットを書き換えよう!】~ http://www.backlog.jp/git-guide/stepup/stepup7_6.html