Philip already described the options well > On Thursday, January 27, 2022 at 8:24:37 PM UTC+5:30 [email protected] wrote: > But use the rebase/editing on the feature development branch to make that look clean (not to hide your mistakes, but to make it easier to understand and bug fix later), and then merge with --no-ff set, adding a full commit message describing the feature (for the --first-parent log). > ...
I'll add my $0.02 > if git could have a feature that allows you to squash commits into a commit bundle A branch is a "bundle", or logical grouping if you will, of commits > which keeps the commit history clean while still maintaining a lot of the important verbose commit history Note that "Clean" is somewhat of a subjective matter I think what you're looking for is something along the lines of git rebase -r main feature && git switch main && git merge --no-ff - ie: rebase branch "feature" to the tip of main and then merge with no fast-forward This is "clean" in the sense that the tree is more linear, and in most tools often easier to read. Some tools provide this functionality. For example Azure DevOps calls it semi-linear merge and provide it as an option to complete a PR I find this often strikes a good balance of keeping a "clean" tree (a more linear history) while retaining the separation inherit to each commit, allowing easier revert/bisect/log A challenge is when you have a lot of conflicting changes in between the common ancestor of the branch and main. Then rebasing can be more arduous than a simple merge wo. rebase. rerere helps in such cases when there are lots of repeated conflicts. A situation where this approach isn't well suited is when a branch has two targets. Say "fix" targets "main" and "release" Then you may want the merge base of "fix" to be the merge base between "main" and "release" Ie: git rebase -r $(git merge-base main release) fix if it is not already at that point at which point you can merge "fix" into "main" and "release" and the "fix" commits will be merged into both branches. If at this point one would either squash or rebase + merge --no-ff, you lose information of which commits are merged into both branches. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/00cd51ea-22a5-4159-905d-ca36fe223f4an%40googlegroups.com.
