3 ms·

I think yours is the sensible path. Rebase can make sense for some specific cases, such as a local branch being organized to present a clearer motivation for

I think yours is the sensible path. Rebase can make sense for some specific cases, such as a local branch being organized to present a clearer motivation for an implementation. Rebase of a shared or externally-visible branch should never be done, and rebase as a default behavior is just a recipe for merge conflicts. My preferred default would be to only ever merge, with an explicit merge commit at all points. (i.e. Never rebase, never use a fast-forward merge.) The main branch is then a sequence of merge commits, visible with "git log --first-parent". This is the same cleaned-up history that rebase proponents espouse, but doesn't lie about the true history the way a rebase-by-default workflow does

lanstin 3y ago
When I am working mostly alone I never rebase or merge. I have code in various directories on my laptop or ephemeral ranches, or more likely stashes if I have more than one thing in flight. When working with others, I will pull a branch while I work on something especially once I am ready for reviews or comments. If main progresses substantially while I work on it, I will rebase and then close and reopen any pending PRs. Especially the first time I start working on a repo, when I want a low key low pressure approach. Once they take some of my work and seem ok with me in general, I will switch to more frequent branchless PRs.