On Thu, Jan 10, 2019 at 9:20 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:
I'm looking to merge my develop branch into the master so that they will be in sync. I'm thinking that this the changed in develop should be squashed so that the master branch doesn't included all the the intermediate changes made during the develop phase. Is there any boost rule/practice/guidence regarding this?. Ideally, I'd like to see the master have only one set of consolidated changes for each release. But I'm not the person who decides these things or does the work. Any insight by other parties would be appreciated.
Robert Ramey
Any merge from master into develop should be empty (i.e. nothing to do). This ensures you didn't miss anything in the past through a bad procedure. (for example someone checking into master directly, which I've seen) Any merge from develop into master should always be a fast-forward. If you squash commits when going from develop to master, you cannot prove that develop is missing anything from master because you cannot merge master into develop. I had to do this and fix up the missing/conflicts on all the CMT repositories. I'd also recommend if you have more branches lying around than develop and master that you consider removing them unless they are for active team development of a feature. Otherwise you should be using a fork and using your own travis and appveyor accounts to prep your changes so that you do not consume Boost CI resources. My recommendation is that your commits to develop are considered project history and they do not get rewritten by rebase or squash into master, and certainly never by a force push. Pull requests run the same CI as a push does, so you should be able to get CI stable on your PR before you rebase your PR into develop. Then you can always merge (fast-forward) develop into master. I don't see any benefit in consolidating all the changes in master to one commit. You can accumulate all the changes using git by comparing the tags between releases. Further nobody who consumes boost from a release sees any of this stuff anyway. If you want to fix your branches, do this: 1. git clone your-repo 2. git checkout -t origin/develop 3. git merge master If you have any commits in master not in develop, this will pick them up. 4. git push 5. git checkout master 6. git merge develop This merge should be a fast-forward because of what you did in 3. What you proposed by squashing commits into master would cause us to have to force push a new consolidated commit into master during the release cycle, which would rewrite history, which is bad for everyone. - Jim