3 ms·

Im looking for a workflow to replace having multiple dependent branches (unmerged code reviews) and rebasing each of them when you have to revise one of the bra

Im looking for a workflow to replace having multiple dependent branches (unmerged code reviews) and rebasing each of them when you have to revise one of the branches for Code review comments. Any suggestions?

tazjin 5y ago
Drop Github, use something like Gerrit and then embrace linear history. If you have very active development with frequent conflicts (requiring lots of rebasing to get things merged) you might want to look at a merge bot like gerrit-queue, but don't do it before it becomes a problem.
- Osiris 5y ago
  A solo developer may be able to make this call but in any size organization, good luck with that.
- searealist 5y ago
  Even if you have linear history on main (squash commits from PRs). You still have this problem if you have multiple out-standing PRs and one of them is dependent on another.
  - tazjin 5y ago
    In Gerrit, the review unit is commonly one commit. IMO the Github pattern of bundling several changes in one review is a mistake.
    - u801e 5y ago
      Even the email based flow presents a series of changes as a thread of email messages, so the association between changes that are related or depend on each other is maintained. Once a patch set looks good to the maintainer, it's merged. Email clients do enforce looking at the changes as a series of diffs on a per commit basis.
    - searealist 5y ago
      There are 2 possibilities: 1) Gerrit doesn't support stacked PRs 2) You have this rebase problem.
the_gipsy 5y ago
Gerrit?
globular-toast 5y ago
I'm not entirely sure what your problem is but you could try deferring the rebase using !fixup and !squash commits. I prefer this workflow during code reviews because then reviewers can see exactly what's changing.
- u801e 5y ago
  We do this as well (using fixup! commits to make code changes and squash! commits to update the commit message).
epage 5y ago
I'm biased but recommend git-stack [0]. A `git stack --pull` will update all branches and maintain associations. I also maintain a comparison of related tools [1] that might interest you. Of them I would probably recommend looking at git-branchless [2] [0] https://github.com/epage/git-stack https://github.com/epage/git-stack [1] https://github.com/epage/git-stack/blob/main/docs/comparison.md https://github.com/epage/git-stack/blob/main/docs/comparison... [2] https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless
- faizshah 5y ago
  Exactly what I was looking for thank you!
simplyinfinity 5y ago
The tool is not your problem, your task prioritization is. if you have dependent branches, you have specific order you have to merge them or split the shared code into a separate branch that gets done before the 'branchoff'. 1. analyze your work properly 2. Break down work to smaller parts 3. prioritize what comes after what
- arxanas 5y ago
  I disagree here. The tooling is a big problem. If you revise one of the earlier commits, it's pretty hard to coax Git into rebasing the dependent commits and branches properly.
arxanas 5y ago
Under git-branchless, this workflow is: $ git checkout <commit> $ git commit --amend $ git restack It will properly rebase descendant commits and branches for you.

tazjin 5y ago

Drop Github, use something like Gerrit and then embrace linear history. If you have very active development with frequent conflicts (requiring lots of rebasing to get things merged) you might want to look at a merge bot like gerrit-queue, but don't do it before it becomes a problem.

Osiris 5y ago
A solo developer may be able to make this call but in any size organization, good luck with that.
searealist 5y ago
Even if you have linear history on main (squash commits from PRs). You still have this problem if you have multiple out-standing PRs and one of them is dependent on another.
- tazjin 5y ago
  In Gerrit, the review unit is commonly one commit. IMO the Github pattern of bundling several changes in one review is a mistake.
  - u801e 5y ago
    Even the email based flow presents a series of changes as a thread of email messages, so the association between changes that are related or depend on each other is maintained. Once a patch set looks good to the maintainer, it's merged. Email clients do enforce looking at the changes as a series of diffs on a per commit basis.
  - searealist 5y ago
    There are 2 possibilities: 1) Gerrit doesn't support stacked PRs 2) You have this rebase problem.

the_gipsy 5y ago

Gerrit?

globular-toast 5y ago

I'm not entirely sure what your problem is but you could try deferring the rebase using !fixup and !squash commits. I prefer this workflow during code reviews because then reviewers can see exactly what's changing.

u801e 5y ago
We do this as well (using fixup! commits to make code changes and squash! commits to update the commit message).

epage 5y ago

I'm biased but recommend git-stack [0]. A `git stack --pull` will update all branches and maintain associations. I also maintain a comparison of related tools [1] that might interest you. Of them I would probably recommend looking at git-branchless [2] [0] https://github.com/epage/git-stack https://github.com/epage/git-stack [1] https://github.com/epage/git-stack/blob/main/docs/comparison.md https://github.com/epage/git-stack/blob/main/docs/comparison... [2] https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless

faizshah 5y ago
Exactly what I was looking for thank you!

simplyinfinity 5y ago

The tool is not your problem, your task prioritization is. if you have dependent branches, you have specific order you have to merge them or split the shared code into a separate branch that gets done before the 'branchoff'. 1. analyze your work properly 2. Break down work to smaller parts 3. prioritize what comes after what

arxanas 5y ago
I disagree here. The tooling is a big problem. If you revise one of the earlier commits, it's pretty hard to coax Git into rebasing the dependent commits and branches properly.

arxanas 5y ago

Under git-branchless, this workflow is: $ git checkout <commit> $ git commit --amend $ git restack It will properly rebase descendant commits and branches for you.