マスターブランチと開発ブランチ間の「git pull」または「git merge」

私は自分のmasterブランチとdevelop、いくつかの変更に取り組むためのブランチを持っています。からmasterへの変更をマージする必要がありますが、develop最終的にはからdevelopにすべてをマージしますmaster。私は2つの異なるワークフローを念頭に置いています。

1. git pull origin masterdevelop分岐
2. git merge masterdevelop分岐

これを行うための最良の方法はどれですか、そしてなぜですか？

リベースには注意してください。開発ブランチを誰かと共有している場合、リベースは混乱を招く可能性があります。リベースは、自分のローカルブランチにのみ適しています。

経験則として、ブランチをオリジンにプッシュした場合は、リベースを使用しないでください。代わりに、マージを使用してください。

このワークフローは私にとって最適です。

git checkout -b develop

...変更を加えます...

...通知マスターが更新されました...

...変更をコミットして開発します...

git checkout master
git pull

...それらの変更を開発に戻します...

git checkout develop
git rebase master

...さらに変更を加えます...

...開発を約束する...

...それらをマスターにマージします...

git checkout master
git pull
git merge develop

この種のものに対する最善のアプローチは、おそらくgit rebaseです。変更をマスターから開発ブランチにプルすることができますが、すべての開発作業はマスターからのものの上に（後でコミットログで）残しておきます。新しい作業が完了すると、マスターへのマージは非常に簡単になります。

開発ブランチを誰とも共有していない場合は、マスターが更新されるたびにリベースします。これにより、開発をマスターにマージしてマージし直すと、履歴全体でコミットコミットが行われなくなります。この場合のワークフローは次のようになります。

> git clone git://<remote_repo_path>/ <local_repo>
> cd <local_repo>
> git checkout -b develop
....do a lot of work on develop
....do all the commits
> git pull origin master
> git rebase master develop

上記の手順により、開発ブランチが常にマスターブランチからの最新の変更の上にあることが保証されます。ブランチの開発が完了し、マスターの最新の変更にリベースしたら、マージして戻すことができます。

> git checkout -b master
> git merge develop
> git branch -d develop

私の経験則は：

rebase同じ名前のブランチのmerge場合、それ以外の場合。

同じ名前の例はmaster、origin/masterとotherRemote/masterです。

場合developのみ、ローカルリポジトリ内に存在し、そして常に最新のが基づいているorigin/masterコミット、あなたはそれを呼び出す必要がありますmasterし、そこに直接仕事。それはあなたの人生を簡素化し、実際にあるものを提示します：あなたはmasterブランチで直接開発しています。

develop共有されている場合は、に基づく必要はなくmaster、単ににマージして戻し--no-ffます。で開発していdevelopます。masterそしてdevelop我々は彼らが異なるものもあり、独立した滞在したいので、別の名前を持っています。と同じにしないでくださいrebase。