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?
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!