[devjab]

Wouldn’t you have the same amount of merge conflicts with rebase? Especially if you don’t do it often, which you frankly also should with merge?

I have to admit that I never really understood the advantages of rebase, and what I mean by this is they I actually don’t understand how the dangers of rebase out-weighs any form of advantages. Especially because on of the major advantages of merge is that you can squash your local commit history when you submit it to your main branch.

What we do is that we tie every pull request to a relatively small feature task, and because we do this, we genuinely don’t care about the individual commits developers do. Which means they can commit really silly messages if they are heading to a meeting or if they are just tired at the end of the day. It also helps with them merging main into their branch often, because it doesn’t taint the history.

The biggest advantage we’ve seen, that maybe we didn’t expect, is that nobody ever fucks up our tree in a way that needs someone who actually understands git to solve. We’ve also locked down the use of force push so that is not available to anyone unless it’s absolutely needed. Part of the reason I set this up initially was to protect myself from me, but it’s been a good thing since.

But I’m actually curious if it’s wrong.

[doix]

> Especially because on of the major advantages of merge is that you can squash your local commit history when you submit it to your main branch.

Squashing is in no-way limited to merging and is actually done by doing an interactive rebase. Nothing is stopping you from squashing without creating a merge commit. It's entirely separate.

If you're squashing everything anyway, what does merging even give you? Is your main branch just:

* merge B

* squashed commit B

* merge A

* squashed commit A

If you didn't merge, you'd have:

* squashed commit B

* squashed commit A

> What we do is that we tie every pull request to a relatively small feature task, and because we do this, we genuinely don’t care about the individual commits developers do.

Except eventually there is a large feature task and then you end up with a giant commit that is annoying when git-bisecting.

But at the end of the day, these things only matter if you are spelunking through git history and/or using things like git bisect. If your git history is "write-only & rollback", then none of this stuff matters.

[xorcist]

> advantages of merge is that you can squash your local commit history

No, it's the other way around. Squashing is a type of rebase.

Most workflows involve both. Merges can also be fast-forward merges, which are indistinguishable from rebases. Choosing between a rebase and a merge operation is often the wrong question to ask. The question is what state you wish the repository to end up in.

> I’m actually curious if it’s wrong

Look at "git log". It is readable and easy to understand? It is obvious why each commit was made, and why alternative solutions were turned down?

Are you able to use "git bisect" to track down problems?

Then you're doing it right. If not, think about what a functional commit log would look like and how you would get there. Working together is culture, and what type of merges you decide to use is just a tiny part of that culture.