On Thu, Apr 5, 2012 at 22:48, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html