Closed lkraav closed 7 years ago
PS one of the triggers here was the massive sudden rollback in master
, where a whole bunch of commits suddenly just disappeared to get the 1.9.10 release out for fixing WP 4.7 crashes.
Essentially, for Sensei, we are following https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow, with tags denoting stable release snapshots
Agree, rebasing with master before opening a pull request is recommended for most development work. I would not go as far as to enforce it though
Reason is, there are drawbacks to rebasing, mostly related to the commit sha changing and using git pull --rebase
.
If a feature is being developed by more than one person on a branch, it is easy to mess things with rebases, especially because if you rebase, you need to git push -f
back to the branch.
Fixing conflicts when rebasing is harder for new folks, as it might end up requiring more advanced git commands (cherry-picking, resetting spefific blobs, reflog etc). Merging might be easier for them in the beginning.
Sure, there is no magic bullet, since people's skill level at this varies so widely. http://endoflineblog.com/gitflow-considered-harmful was an interesting recent read + comments discussion.
Maybe a useful tip for someone, stgit
has helped me a lot with intra-branch patch management. Makes rebase-principle operations a ton quicker to handle.
The difficult case still remains where you need >1 wip feature branches sitting underneath your own...
I guess the main value filing this issue might have been to just draw periodic attention to "this stuff does matter, care should be taken". Perhaps some quick incremental wins could be found by group-thinking about it.
Closing as answered.
The criss-cross merging of
master
with feature or developer branches creates a very confusing picture of what happens where and why. Example below (mainly the bottom part):I propose the official policy to be adjusted and start requesting
rebase
use overmerge
. Before merging any feature or developer branch, it should be cleanly rebased on top of latest everbranchmaster
, whenever possible (occasional work sync timelapses need to be adjusted for, i.e. PR review is delayed butmaster
advances). Master should really never need to be merged into anything.Hypothesis is that the resulting linear cleanliness should produce increased understanding for all participants, therefore resulting in higher quality code inputs already in short-term perspective.
Your thoughts?