Rebase and ideally Squash instead of Merge for Pull Requests

[coderbyheart]

Important

Published at https://coderbyheart.com/rebase-and-ideally-squash-instead-of-merge-pull-requests

[ewoks]

Having all these in the main branch

what is main branch here? something like develop branch where feature branches are merged into? It looks to me that something is a little bit off in this explanation.

All these small commits that are part of PR aren't cherry picked from feature branch to appear again on the develop as separate commits, no? So other developers see just merged PR as one commit consisting of all of these atomic changes.

I really don't understand what is advantage of squashing everything together in this case, but I see big disadvantage that all the work of conscious make of atomic commits just got flushed away

[Wrent]

Nice description! Btw. there is double "when" in one of the sentences.

[gregturn]

I really don't understand what is advantage of squashing everything together in this case, but I see big disadvantage that all the work of conscious make of atomic commits just got flushed away

But it didn’t get flushed away. All the work still lives. During the squashing part, you polish and edit. All the “hack” commits can be simply dropped while the non-hacks are revised and properly ordered.

What does it matter what order the feature branch was done? It’s like reading a novel and feeling you are at a loss because you can’t see the earlier drafts. All those drafts end up getting “squashed” into the final product.

[ewoks]

Maybe I just didn't understand it right. Do you or can you point me to example repository? Even simple drawing of before vs after would be helpful. Thanks

[smolak]

@ewoks I think you will find it in the article I wrote a while ago: https://medium.com/@jacek.smolak/how-do-i-commit-59bf6de2b264

In the latter part there are commits mentioned that are fixes and how I go about them.

[ewoks]

@smolak thanks for the link and article.

For me and most of the teams I lately worked with, GIT Branching Model looks and feels (in practise) much simpler than rewriting history and making documentation of git repository.
TL;DR every feature has its own branch, you as the feature owner commit in order you want and send pull request, team reviews and at the end feature branch will be merged to develop branch. Develop is always buildable and runnable and it should have deliverable product.

However, I understand that lack of branching strategy would require cleaning things up at least a bit before considering it complete. Huge time investment IMHO but everybody decides with the team.

Still it feels that I am missing some important point, cause what is described in your article looks to me like a huge overkill in comparing with how me and team is doing it at the moment, that's why I hoped for repository example.

[coderbyheart]

I think the article provided by @smolak gives a good explanation of how it would look like in a real repo.

But everybody learns differently so adding a repo with an example (feature branch with multiple commits, main branch with squashed commits) is a good idea.

It's also worth mentioning that I lean heavily towards short lived branches #16.