1

I read up online that rebase command shouldn't be run on a public branch. I have the following scenario:

master having commits A1 <- A2 <- A3
stable branched from master at A1, having commit B1
dev1 branched from stable at B1 and having commits C1 <- C2 <- C3
dev2 branched from dev1 at C2 and having commits D1 <- D2

Now if I want to update stable with master's updates, I run git rebase master and do a force push. Now, dev1 does a rebase on top of stable to get the master's updates and dev2 needing both master and dev1 does a rebase on top of dev1.

In this scenario is it ok to run the rebase command on stable, dev1 and dev2 branches as long as I am following the order? If this isn't ok then what's the alternative to merge latest master to stable and latest master, dev1 updates to dev2? The only thing I can think of is to create a pull request, merge the code and then re-branch. Is that the better alternative or is there something I'm missing?

linuxNoob
  • 600
  • 2
  • 14
  • 30

1 Answers1

1

With Git 2.18+, you should not need to do all those rebases: only one:

git checkout stable
git rebase --rebase-merges master

dev1 and dev2 should be rebased as well: you will need to reset your local branches to those new rebased branches HEAD.

In your case, if you have set local branches for master, stable, dev1 and dev2, that means only one rebase (of stable) will rebase all related branches (dev1 and dev2)

--x--x--x--x (master)
      \
       s--s--s (stable)
              \
               d--d (dev1)
                   \
                    d--d (dev2)

A git checkout stable; git rebase --rebase-merges master will do:

--x--x--x--x (master)
            \
             s'--s'--s' (stable)
                      \
                       d'--d' (dev1)
                            \
                             d'--d' (dev2)

No need to rebase stable, then dev1, then dev2!

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @torek Yes, I was a bit in a hurry when I wrote this. I have edited the answer. – VonC Jan 30 '19 at 07:47
  • I'll be honest, I'm having a hard time understanding what `--rebase-merges` does. Does this mean I don't need to force push after `rebase`? What sort of local branch resetting is required? I mean the `rebase` command would make the local branch sit on top of `master` or `stable` or `dev1` so where does the new rebased branch come into picture? – linuxNoob Jan 30 '19 at 16:36
  • 1
    @linuxNoob I have edited the answer to address your comment. – VonC Jan 30 '19 at 16:55
  • so if I force push the changes to remote `stable` after `--rebase-merges` and `dev1` and `dev2` pull it down then what do they need to do to sync their local `dev1` and `dev2` with the remote? More importantly, what if `dev2` doesn't exist in the remote yet? Is this what you're talking about with local branch being reset to rebased branches HEAD? – linuxNoob Jan 30 '19 at 17:13
  • 1
    @linuxNoob you can push (for new branches) or force push. Anyone working on a forced pushed branch will need to: 1/ `git fetch` 2/ `git reset --hard origin/dev1` (for instance, to reset `dev1` working tree and history to `origin/dev1` you just fetched). Make sure to stash any work in progress first. – VonC Jan 30 '19 at 17:19
  • If `dev2` doesn't exist in remote yet then I'm assuming `git fetch` and `git reset --hard origin/dev1` will take care of rebasing `dev2` on top of the rebased `dev1`? – linuxNoob Jan 30 '19 at 17:48
  • @linuxNoob the idea behind git reset --hard is that you already force pushed *all* branches, so dev2 does exists in the remote. Another collaborator will fetch everything (including origin/dev2) and can then reset any local branch he/she wants. – VonC Jan 30 '19 at 21:38
  • if `dev2` exists only on local then they would have to manually `rebase` on top of `dev1`? It sounds like, this option requires all branches to be present in local before doing it. So if I am running `git rebase --rebase-merges stable` in my local then I must have `dev1` and `dev2` on my local? – linuxNoob Jan 30 '19 at 22:07
  • @linuxNoob No, as illustrated, `dev2` would be rebased during the `git rebase --rebase-merges master`, alongside `stable` and `dev1`. Remember you rebase on top of `master`. You don't type `git rebase --rebase-merges stable`: that would rebase on top of `stable`. – VonC Jan 30 '19 at 22:10
  • > No, as illustrated, dev2 would be rebased during the git rebase --rebase-merges master, alongside stable and dev1. How will this happen if I don't have `dev2` on remote or local? – linuxNoob Jan 30 '19 at 22:26
  • 1
    @linuxNoob if dev2 does not exist at all anywhere, then it won't happen indeed: just create dev2 once the rebase is done, on top of dev1. – VonC Jan 30 '19 at 22:30