5 ms·
That works if you have one commit. Otherwise it's more like git commit, git merge --no-ff master, git commit, git merge --no-ff master, git commit, git merge --
by ivanche 4y ago
That works if you have one commit. Otherwise it's more like git commit, git merge --no-ff master, git commit, git merge --no-ff master, git commit, git merge --no-ff master… which shows as bunch of really ugly and unnecessary merge commits from master to feature branch. In contrast, I can do 50 times git rebase and you wouldn't know.
- l72 4y agoThose merges from master into a feature branch are useful though. If there is a conflict that you have to resolve in your feature branch, then there is a clear place where you did it, and that can be double checked. If you are rebasing, then when I review your feature branch, I have no idea if you had conflicts, and if so, how many and how you resolved them. git should be used like an audit log, where you can trace the thought process and actions of your developers. Erasing that by rebasing/squashing for a "clean" log isn't worth it in my opinion. I'd much rather see 40 commits across two weeks on your branch than one "clean" commit with everything. With the 40 commits, I can trace back through your work, and understand your challenges (sometimes seeing 5 commits in a row with 'trying to get X to work' is really useful). Now, do I want all that detail once your branch is in master. Absolutely Not! I just want a single merge commit that brings in your whole branch. Unfortunately, `git log` shows everything, which is why I advocate for `git log --first-parent` being the default. If git log's default behavior wasn't so terrible, I don't think this argument would even come up so often.