problem I see with the ff merge: if the merge breaks master, you have to revert all the commits or force push to before-the-merge. and it's not even clear where the merge starts.
problem I see with the rebase: if you don't stop after each rebased commit and check that the unit/integration tests still work, nobody knows. so if for some reason you have to go back to a commit there or branch off from one of those, your code might be broken. squash removes that problem, but then you might have mega large commits and it's not clear anymore why some of the changes happened.
the problem of the crazy history is in my opinion a display problem, that can be solved by intelligent display of branches and merges. I used a tool called git-kraken for a while, that had a very beautiful display of the history. (not free for commercial use, tho)
You know where the problem has started because before merging and break the master for example, has receive a pull request. So they know WHO, the Branch that has caused the problem.
I used gitkraken for a while, i realized that i don't need it anymore. But the main problem is the maintenance not only the visual. Visual is a secondary problem, developer we should always try to work properly for ourself and team members, for future work even if there is something that we don't see everyday like a git history, a documentations ...
hey coyla,
we don't use github or gitlab pull requests. just plain git. if you fast forward a merge, you don't see any branches or info without diving into the internals. in our company we try to pull with ff and only rebase if it fails to avoid a) pull merges and b) accidental rebases of merged branches. we also merge no ff always to keep the branch name information. for multiple reasons.
sometimes it goes wrong and everything looks shit. most of the time we have clean feature branches.
I guess in the end it's always what the team decides for and if everyone is happy every solution can be the best one.
Yes. It depends of the team. I remember that some people said in our last team " we need to keep track of the release branch" so must of the time we used rebase and sometimes normal merge (for releases) as you say.. thanks to share your way to do 🙇✌️✌️
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
well written article. thank you.
problem I see with the ff merge: if the merge breaks master, you have to revert all the commits or force push to before-the-merge. and it's not even clear where the merge starts.
problem I see with the rebase: if you don't stop after each rebased commit and check that the unit/integration tests still work, nobody knows. so if for some reason you have to go back to a commit there or branch off from one of those, your code might be broken. squash removes that problem, but then you might have mega large commits and it's not clear anymore why some of the changes happened.
the problem of the crazy history is in my opinion a display problem, that can be solved by intelligent display of branches and merges. I used a tool called git-kraken for a while, that had a very beautiful display of the history. (not free for commercial use, tho)
Hi ! PAxel
I used gitkraken for a while, i realized that i don't need it anymore. But the main problem is the maintenance not only the visual. Visual is a secondary problem, developer we should always try to work properly for ourself and team members, for future work even if there is something that we don't see everyday like a git history, a documentations ...
hey coyla,
we don't use github or gitlab pull requests. just plain git. if you fast forward a merge, you don't see any branches or info without diving into the internals. in our company we try to pull with ff and only rebase if it fails to avoid a) pull merges and b) accidental rebases of merged branches. we also merge no ff always to keep the branch name information. for multiple reasons.
sometimes it goes wrong and everything looks shit. most of the time we have clean feature branches.
I guess in the end it's always what the team decides for and if everyone is happy every solution can be the best one.
Yes. It depends of the team. I remember that some people said in our last team " we need to keep track of the release branch" so must of the time we used rebase and sometimes normal merge (for releases) as you say.. thanks to share your way to do 🙇✌️✌️