Re: Linear history *and* share a branch?
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Apr 5, 2012, 20:56 UTC
- Message-ID
- <CACBZZX6za0+MXi4nPiV5ZuCKa91cPz0aye6FZG4gGAdqj0GqcA@mail.gmail.com>
- In-Reply-To
- <CAE1pOi0-uSaQwgJHMTkw3nqp=idxZxMbyfKtLni0=Xwu-L-_hA@mail.gmail.com>
On Thu, Apr 5, 2012 at 22:48, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
> Should we simply do "git merge master" instead of "git rebase master"? > And then do something at the end when we are about to merge the shared > branch back into master to guarantee linear history? Your thoughts and > ideas would be greatly appreciated.
Yes, that's the most sensible workflow to have. You create a topic branch, push/pull it back and forth, do merge commits and never rebase it, then when you decide if it's finished you can either merge it into the mainline (with non-linear history), or have someone rebase it and push it to the mainline.
I use the latter workflow extensively in my work e.g. when peer programming. We'll both have the same branch set up as a tracking branch, make a bunch of WIP commits with crappy commit messages for a day or so, then at the end of the day interactively rebase the branch, and push it with linear history to the mainline.