4 ms·

Is there a way so you can rebase and push without breaking everyone who already pulled your repo? I have this issue continuously when using rebase on branches t

by spockz 8y ago

Is there a way so you can rebase and push without breaking everyone who already pulled your repo? I have this issue continuously when using rebase on branches that have gitlab or github merge/pull requests. I need to create a different branch all of the time.

ereyes01 8y ago
You can always define a new branch pointing to your new rebased ref and push/PR that to avoid having to force-push and messing everyone up.
cesarb 8y ago
You aren't supposed to rewrite history (which is what rebase does) on which other people are basing work. If people have merge/pull requests on your branch, then people are basing work on your branch, and you shouldn't rewrite it. The best approach (which is what git.git itself uses) is to do the work on a separate branch, which is rebased often; once it's moved to the master branch, it's "frozen" and won't be rebased anymore. All pull requests are based on the master branch, so aren't affected by the constant rebases on the development branch. (Actually, all the work is done on topic branches, what's often rebased/rewritten is a sequence of merges of these topic branches into the master branch.)
- spockz 8y ago
  That is what I meant. Master is stable, I have my feature or bug fix branch which I already want to show. Nobody is forking from this branch but if the pulled the branch before it will break after my rebase.
kazinator 8y ago
Point people to a stable repository that doesn't have non-fastforward changes. Do your history rewrites between your local development repo(s) and a "staging" repo that outsiders do not know about. Only push good changes from "staging" to the public repo. (By "good" I don't mean bug-free code written from an irreproachably perfect design, but simply changes that are not so bad that the best way to fix them is to steamroll their history and rework them entirely.) You can give people access to the staging repo, but then they have to acknowledge that they are willing to deal with some occasional chaos.

by spockz 8y ago

ereyes01 8y ago

You can always define a new branch pointing to your new rebased ref and push/PR that to avoid having to force-push and messing everyone up.

cesarb 8y ago

You aren't supposed to rewrite history (which is what rebase does) on which other people are basing work. If people have merge/pull requests on your branch, then people are basing work on your branch, and you shouldn't rewrite it. The best approach (which is what git.git itself uses) is to do the work on a separate branch, which is rebased often; once it's moved to the master branch, it's "frozen" and won't be rebased anymore. All pull requests are based on the master branch, so aren't affected by the constant rebases on the development branch. (Actually, all the work is done on topic branches, what's often rebased/rewritten is a sequence of merges of these topic branches into the master branch.)

spockz 8y ago
That is what I meant. Master is stable, I have my feature or bug fix branch which I already want to show. Nobody is forking from this branch but if the pulled the branch before it will break after my rebase.

kazinator 8y ago

Point people to a stable repository that doesn't have non-fastforward changes. Do your history rewrites between your local development repo(s) and a "staging" repo that outsiders do not know about. Only push good changes from "staging" to the public repo. (By "good" I don't mean bug-free code written from an irreproachably perfect design, but simply changes that are not so bad that the best way to fix them is to steamroll their history and rework them entirely.) You can give people access to the staging repo, but then they have to acknowledge that they are willing to deal with some occasional chaos.