Git チームワークフロー: マージ (merge)、それともリベース (rebase) ? | Atlassian Japan 公式ブログ | アトラシアン株式会社

質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか？これは、確固たる意見を持つ両陣営によって繰り返し展開されている議論の一つですが、やはり議論には最低限の配慮を持って対応したいものです。 (その他の激しい議論の例としてはこれがあります: The Internet)。 リベースを行って、リポジトリの履歴をフラットかつクリーンに保つべきでしょうか？それとも、可読性と明晰さを犠牲にする事でトレーサビリティを得られる、マージを行うべきでしょうか？( ファストフォワード マージを禁止するなど。) 議論 このトピックは、vim と Emacs や Linux と BSD ほどまでには有名な論争の的とはなっていないものの、双方共に遠慮なく意見を述べ合っています。 all-things-git に

[theatrical]

安全第一のmerge派です

[kompiro]

自分はmerge派。 mergeだと bisect が難しいとはなんのことなんだ

[machupicchubeta]

おもしろいまとめ！

[h5y1m141]

昨日のイベントの懇親会で聞いた話をふまえて、rebaseすれば・・と単純に考えていたけど、これ読んだら、そっか自分がやっていたやり方は安全第一なアプローチだったわけでそれも間違いじゃなかったのか。

[aroma_black]

rebaseは1本線の履歴が欲しいかつメンバーにgitの操作スキルがある場合でmergeは安全にブランチを運用したい場合にする

[qt4cpp]

Check out "Git チームワークフロー: マージ (merge)、それともリベース (rebase) ?" (via @pocket)

[raimon49]

これはチームの多きさや全体の習熟度で決めるのが良いんじゃないか。3人くらいまでならrebaseありでやるけど。

[naney]

「チームポリシーとしてのリベースは、クリーンアップとしてのリベースとは異なります。」「重視するのは、クリーンでリニアな履歴ですか? それとも、ブランチのトレーサビリティでしょうか?」

[griefworker]

masterにマージする前にコミットを１つにまとめているからrebase派になるんだろうか。

[kozy4324]

origin/masterにinteractiveじゃないrebaseしてからmerge --no-ffじゃないの？Squashで常に1コミットにするのは反対だしレインボーなコミットグラフも避けたい派

[mabots]

Git チームワークフロー: マージ (merge)、それともリベース (rebase) ?

[ocs]

push 前のブランチは好きに rebase すればいい、push 後は (featureブランチであっても) rebase 禁止派

[hirose31]

merge rebase

[ninjinkun]

会社ではmerge派、OSSへのPullReq作りではrebase派でやっている気がする / 履歴を汚しても良いかという空気次第?

[katzchang]

「少数の禁忌」って、`push --force`しないでということくらい？

[isseium]

（なんとなく）rebase 派だけど，よく理解していない部分もあるので深めたい

[indication]

チームビルディングこの参考にする

[poppun1940]

質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか？これは、確固たる意見を持つ両陣営によって繰り

[slywalker]

私はマージ派

[Sips]

git

[auient]

マージ方針のmergeとrebaseの比較

[yuu850213]

git

[osawagiboy]

git

[ruedap]

これは良いまとめ。自分は今のところ少数・小規模ばかりなのでマージ派