On 14.10.2019 21:22, Frederik Schwarzer wrote: > If however, master had seen commits as well, fast-forwarding is > performing a rebase ... is that correct?
The workflow would be: whenever master is updated, you rebase your local feature/work branch and force-push to the remote copy of the feature/work branch. That way you would get a linear commit history whenever you merge the feature/work branch to master. People reviewing your work should be prepared to reset --hard to the origin whenever that happens. There are two caveats with this model: - one: you should never accept MRs which are (partially) behind master, because the person who merges things in should not modify what is being merged in. Rather the person who proposes the merge should take the time to do the necessary rebase, because they know best how to do that. - especially when working with many people on the same code-base there should be reasonably fast paced dev -> MR -> review -> merge cycle. Long lived feature/work branches are really bad because as time goes on it becomes fairly difficult to keep them up to date. Regards, -Johan
