「[[.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

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS