4 ms·

You know, I can respect people who choose to use rebase instead of merge, but your arguments against merging borderline on hysteria. I mean, plenty of teams of

by j_baker 14y ago

You know, I can respect people who choose to use rebase instead of merge, but your arguments against merging borderline on hysteria. I mean, plenty of teams of equal or larger size have dealt with merge commits that it's just silly to say things like "Merge commits do so much harm, it's outrageous that anyone would think they're any good". Having code pushed to master sooner rather than later is better. It means that you have fewer developers stepping over each other to make changes. When you have 20-60 (or more) developers working on many different things at many different times, this is important. Also, I think you're painting an extreme picture of merging where everyone always uses a merge commit for everything. It's silly to expect that with a team of 20-60 people, everyone should be doing git pull every time they update and then pushing that back to master. We have git pull --rebase for that. There are even options to make git do that by default. I vastly prefer merge commits when dealing with feature branches. It makes it much easier to see a logical grouping of merge commits, and makes it so I don't have every commit interspersed between.

erso 14y ago
The thing is, what you're saying directly contradicts reality. You have fewer developers stepping over each other to make changes when they aren't constantly merging in things that have a high likelihood of changing. If someone makes a change and pushes it to master I can just as well rebase my work on top of their commit, make any changes I might need to should there be a conflict, and go on my way without having to merge anything. If I use merge in that same situation I can end up with a string of useless merge commits that contain conflict resolution practically hidden away from the real work. Logical grouping of commits is still completely possible with merging as I said, when you use --no-ff merging into the branch after having rebased on top of it. For example, if I have a branch topicA, I can, having fast-forwarded master and being on topicA, git rebase master, git checkout master, and then git merge --no-ff topicA. This will give you the only acceptable merge commit, with a history that shows where your branch diverged from master and what commits it contains.

by j_baker 14y ago

erso 14y ago

The thing is, what you're saying directly contradicts reality. You have fewer developers stepping over each other to make changes when they aren't constantly merging in things that have a high likelihood of changing. If someone makes a change and pushes it to master I can just as well rebase my work on top of their commit, make any changes I might need to should there be a conflict, and go on my way without having to merge anything. If I use merge in that same situation I can end up with a string of useless merge commits that contain conflict resolution practically hidden away from the real work. Logical grouping of commits is still completely possible with merging as I said, when you use --no-ff merging into the branch after having rebased on top of it. For example, if I have a branch topicA, I can, having fast-forwarded master and being on topicA, git rebase master, git checkout master, and then git merge --no-ff topicA. This will give you the only acceptable merge commit, with a history that shows where your branch diverged from master and what commits it contains.