3 ms·
I do prefer rebases over merges because they lead to a cleaner history, but when you have a set of features in separate branches that are all dependent, rebasin
by Ruud-v-A 11y ago
I do prefer rebases over merges because they lead to a cleaner history, but when you have a set of features in separate branches that are all dependent, rebasing becomes a pain. I like to have one local branch per CL/pull request. If I have a branch feature1 with commits on top of master, then feature2 with commits on top of feature1, feature3 with commits on top of feature1, and feature4 that merges feature2 and feature3 and then has commits on top of that, that thing is a pain to rebase. (I know about --preserve-merges, but it does not always do the right thing.) The main problem here is that the end result should be feature4 rebased on top of master, but the other branches should also be updated to point to the new commits.
- Pyxl101 11y agoIt's rare to need to develop multiple features as concurrent branches, as long as you can release regularly. The practice that works really well is: just develop against master while running "git pull --rebase" regularly. Code review and then ship the feature, repeat. Use branches only for rare concurrent development, and only after the need has arisen (Git makes it trivial to move changes into a branch after the fact).
- Ruud-v-A 11y agoIt is not rare at all. The features I am talking about are small. In a large project code review can take several days if the reviewers are busy, even for a small change, so it is essential to work on multiple things concurrently.