I don't see how maintaining the order of commits in a feature branch would provide much benefit since, ultimately, the code needs to be integrated on top of the base branch, which is exactly what rebase achieves. As for the concern about accidentally rebasing the base branch, Git won’t allow a push if the histories differ unless a force push is used, so Git ensures that any history rewrite is intentional. If someone loses local history during a rebase, they can easily create a new branch from the remote. Regarding the risk of force-pushing to the base branch, best practices suggest that base branches should be protected. This can be enforced via your remote Git platform, allowing only merge commits through pull requests and preventing any force-pushes to critical branches.
exactly on feature branch where you only work, preserving the commit history doesn’t not matter. Only while merging it to remote branch, it need to be considered. yes force push should be avoided in remote.
I had the exact same thought while listening to this explanation. I think the idea of wanting to preserve histories comes from a difference of working styles. Some people prefer to use git bisect to identify commits causing problems in which case the history becomes important. For a better take on why some people prefer merge instead of rebase, check out Primeagean’s video with Theo called “You only Git Merge? Feat Theo”
The issue I have with merge is that junior / unexperienced / bad developpers always f up with merges and end up doing merge conflict resolution in every other direction. I've seen it time over time. If the person doesn't grasp the difference between merge and rebase, then that person should also always rebase since that person will always f up his/her merges. Also, that person should think of a different career path probably.
Great explaination Shrayansh along with a great example.
To the point explanation, Thanks for it.
Nice explanation. Thank you bro!
Demn you such a powerful explainer thank for explain it
I don't see how maintaining the order of commits in a feature branch would provide much benefit since, ultimately, the code needs to be integrated on top of the base branch, which is exactly what rebase achieves.
As for the concern about accidentally rebasing the base branch, Git won’t allow a push if the histories differ unless a force push is used, so Git ensures that any history rewrite is intentional. If someone loses local history during a rebase, they can easily create a new branch from the remote.
Regarding the risk of force-pushing to the base branch, best practices suggest that base branches should be protected. This can be enforced via your remote Git platform, allowing only merge commits through pull requests and preventing any force-pushes to critical branches.
exactly on feature branch where you only work, preserving the commit history doesn’t not matter.
Only while merging it to remote branch, it need to be considered.
yes force push should be avoided in remote.
@@JainShrayansh how so
I had the exact same thought while listening to this explanation.
I think the idea of wanting to preserve histories comes from a difference of working styles. Some people prefer to use git bisect to identify commits causing problems in which case the history becomes important.
For a better take on why some people prefer merge instead of rebase, check out Primeagean’s video with Theo called “You only Git Merge? Feat Theo”
The issue I have with merge is that junior / unexperienced / bad developpers always f up with merges and end up doing merge conflict resolution in every other direction. I've seen it time over time.
If the person doesn't grasp the difference between merge and rebase, then that person should also always rebase since that person will always f up his/her merges. Also, that person should think of a different career path probably.