4 ms·

Even the "don't rebase once code is pushed to a shared repo" thing is more of a guideline than a hard and fast rule. For example you might reasonably want to cl

by jgraham 13y ago

Even the "don't rebase once code is pushed to a shared repo" thing is more of a guideline than a hard and fast rule. For example you might reasonably want to clean up the history on branches that you have previously: * Pushed to a distributed test system * Pushed to a branch based code review tool (e.g. Opera Critic or Gerrit). Using a heavily rebase-centric workflow for several years, with rebases on semi-public branches like those described above an expected part of the process, I don't think that history rewriting has ever caused me an actual problem. So my gut feeling is that people spend a lot of time trying to avoid something that sounds theoretically bad but isn't much of a problem in practice as long as some common sense is employed.

jedbrown 13y ago
The intent is "don't rebase if you might have a downstream". You're welcome to rebase branches that you push as long as your workflow specifies that they are still volatile. For example, we push unfinished topic branches to our team repo as backup and to allow "passive review" (a pull request is "active review"). Comments at this stage are communicated by bitbucket line comments (or by email/chat) and are handled by amending the topic branch. This unmerged topic branch is rebased any time the author prefers to start from a later 'master' in exchange for re-testing the series. When the topic is considered complete by the author, she either makes a pull request or merges to 'next' herself. Merging to 'next' signifies that another topic may depend on that branch. In this workflow, an unmerged topic branch is roughly equivalent to a patch series on a mailing list, but doesn't require email client integration and degrades more gracefully with less disciplined commit factoring and less sophisticated tool use.
dlitz 13y ago
There's a loose convention of using the suffix, "-wip", to name published branches that you plan to rebase.

by jgraham 13y ago

jedbrown 13y ago

The intent is "don't rebase if you might have a downstream". You're welcome to rebase branches that you push as long as your workflow specifies that they are still volatile. For example, we push unfinished topic branches to our team repo as backup and to allow "passive review" (a pull request is "active review"). Comments at this stage are communicated by bitbucket line comments (or by email/chat) and are handled by amending the topic branch. This unmerged topic branch is rebased any time the author prefers to start from a later 'master' in exchange for re-testing the series. When the topic is considered complete by the author, she either makes a pull request or merges to 'next' herself. Merging to 'next' signifies that another topic may depend on that branch. In this workflow, an unmerged topic branch is roughly equivalent to a patch series on a mailing list, but doesn't require email client integration and degrades more gracefully with less disciplined commit factoring and less sophisticated tool use.

dlitz 13y ago

There's a loose convention of using the suffix, "-wip", to name published branches that you plan to rebase.