

master からマイブランチを作成して作業、そしてmasterにマージされています。  
master は別途開発されているので更新が進んでいきます。

この時、masterの最新状態をマイブランチに反映させたい時は「masterをマージする」という流れで良いのでしょうか。  
実際にやってみたところ、bitbucketのプルリクエストには 「マイブランチ → master」と表示されています。

「masterに追いつく」というニュアンスでいるのですが、検索ではそのような表現が見当たらたなかったので考え方として違っているのか、マージしていいのか、疑問になっているところです。

それともmasterがマイブランチをマージした時点でマイブランチを閉じて、  
新しい変更を加える度にmasterから新規ブランチを作成したほうがいいのでしょうか。

抽象的な質問でスミマセン。よろしくお願いします。


CC BY-SA 3.0
2015-02-12T04:31:41.163
6358
2015-02-13T06:51:20.180
2015-02-13T03:53:55.067
7980
7980
question
git
git で master に追いつく？ブランチは都度closeするべき？


開発フローにもよるかもしれませんが、

[code]

    git checkout master
    git pull origin master
    git checkout my-branch
    git rebase master
    
[/code]

とすることで、`my-
branch`の出発点を`master`の最新コミットに置き換えることができます。普通にマージするとマージ処理で1コミットが必要になるのと、後からログを見た時に汚くなってしまうので、個人的には`rebase`を使うのが好きです。

またブランチの寿命については質問に書かれている通り、その都度作りなおしたほうが簡潔かと思います。`master`に取り込まれたブランチは削除して良いです。


CC BY-SA 3.0
2015-02-12T04:56:36.167
6361
2015-02-12T04:56:36.167
3313
6358
answer


> masterの最新状態をマイブランチに反映させたい時は「masterをマージする」という流れで良いのでしょうか。  
>  masterがマイブランチをマージした時点でマイブランチを閉じて、  
>  新しい変更を加える度にmasterから新規ブランチを作成したほうがいいのでしょうか。

それで良いと思います。  
ワークフロー次第ですが、うちではチケット単位でブランチを切ってプルリクエストによる`master`マージ後はブランチ削除しています。

`rebase`に関しては下記URLを参考いただき、gitの性質を理解した上で使用するかしないか決めてください。私は`rebase`しない派です。  
(`GitHub`で公開されたソースへのプルリクエストは除く)

[こわくないgit](http://www.slideshare.net/kotas/git-15276118)  
[rebaseの功罪](http://shigemk2.hatenablog.com/entry/20121123/1353640913)


CC BY-SA 3.0
2015-02-12T05:41:17.023
6365
2015-02-12T05:41:17.023
7214
6358
answer


> この時、masterの最新状態をマイブランチに反映させたい時は「masterをマージする」という流れで良いのでしょうか。  
>  実際にやってみたところ、bitbucketのプルリクエストには 「マイブランチ → master」と表示されています。

マージ方向が逆のような気がします。`master`のコミットを取り込みたいなら、取り込む先のブランチのページで「32 commits behind
master. 今すぐ同期.」みたいになっていると思うので、「今すぐ同期」でいけるはず。

合流するんだからどちらでもいいという意見もありそうですが、内部的にはどちらが親なのか識別できるようになっているので、使い分けたほうが問題が起きにくいと私は考えています。

> masterがマイブランチをマージした時点でマイブランチを閉じて、  
>  新しい変更を加える度にmasterから新規ブランチを作成したほうがいいのでしょうか。

フィーチャーブランチなど、一時的に作ったブランチの場合はそうすることが多いです。一方で`develop`と`production`みたいな分け方では、両方とも生かしたままにして随時マージすることになります。

* * *

私もBitbucketをよく使いますが、プルリクを使うようになってからはあまり`rebase`してないですね。

  * `rebase`はそれぞれのコミットを機械的に適用し直すものなので、`master`の進み方によってはコミットごとにconflictが発生して面倒
  * `rebase`に関わらず、マージコミットのない`\--ff`マージでは後から見たときに合流点がわかりにくい  
（Github/Bitbucket上でプルリクをマージする際は所謂`\--no-ff`マージなので、必ずマージコミットが作成されます）

プルリクに関連した理由としては、

  * プルリク作成後にレビューや修正を行うならどうせコミットログはきたなく？なるのであまり甲斐がない

まあ面倒なわりに整形するメリットが薄いかな、というのが大きいですね。

余談ですが、Githubで公開されているOSSの場合でも、`rebase`する代わりに`git merge
master`として`master`に同期することで、conflictの解消をプルリク作成側で行えば問題なかったりします。`WIP`といってプルリクを作成してから作業を進めるケースもありますし、様々ですね。

Bitbucketの運営元であるAtlassianがGitやGitを使ったワークフローのチュートリアルを日本語で公開しているので、一度読んでみてはいかがでしょうか。

<https://www.atlassian.com/ja/git>


CC BY-SA 3.0
2015-02-13T06:51:20.180
6434
2015-02-13T06:51:20.180
8000
6358
answer