I've been discussing with several people about how I should structure internal project. We currently employed the standard merge approach for git (setup gitflow) and it's ok. But we have several issues with release.
Everytime people are writing on features and doing a MR into the develop or master branches or release takes for ever because we are spending time fixing merge conflicts.<p>A friend of mine suggested we change to a rebase strategy. Where instead of the conflicts happening at the time of release (develop or master) the conflicts are undertaken by the developer doing the feature before and after they do their work, essentially ensuring that release is always working.<p>What are your thoughts? Rebase or merge strategy and why?
Hi, using git flow I would be more in favor for the rebase strategy, I think conflict resolving should be the responsibility of the developer adding the feature. It's part of the cost of developing it. However, it is essential to rebase all the time and do non breaking and microcommits, I suggest doing a rebase many times a day to handle conflicts a little at a time. Moreover, a feature branch should merge with the dev branch and not last more than three days at most to mutualize code and sharing value. This should prevent never ending conflicts
Is your team quite inexperienced with git, or is there anything inherently unusual about the project?<p>If the team is spending a lot of time dealing with merge conflicts, merging vs rebasing isn't the problem.<p>More than likely, one or more of the following are issues:<p>- Too many people are making changes in parallel to the same file<p>- Everyone isn't consistently keeping their `dev` branch up-to-date<p>- Developers aren't taking the time to first merge dev into their feature branch and fix any merge conflicts before submitting a pull request<p>- Pull requests aren't being properly reviewed (no approvals until merge conflict addressed)