We have to fork a repository and keep it up to date, with adding changes here and there. The important branches are remote/1.0 and remote/1.1

The workflow currently used is to fork the repository, create our own 1.0 branch that is the same as remote/1.0. Changes are then made that are pushed to our 1.0. Now, we have to create a new 1.1 branch based on our 1.0 and merge remote/1.1 to it. The idea is to end up with the copy of remote/1.1 branch, but with all our previous changes kept (where that made sense, some changes may have to be adjusted to remote/1.1).

Is merging every so often a correct strategy here? Or should rebasing be more appropriate? Is a better third way to do it?

  • For me your question boils down to is rebase better than merge? I would always rebase my changes ontop of remote/1.1 (which I assume is the "bleading edge" or develop branch according the standard branching model Jul 1, 2022 at 9:37
  • You mentioned "We have forked" — I assume you are working on a team? This is significant if you are thinking about debasing commits. Jul 2, 2022 at 19:02
  • Are you planning on merging your fork into their repository? If so, how often? What is their pull request process? Jul 2, 2022 at 19:06
  • Yes, I'm part of a team. Shouldn't rebase be fine if it produces a new branch (i.e. no rebasing of pushed commits)? The fork is never going to be merged. Jul 3, 2022 at 20:30


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.