request for git help
See original GitHub issueI’ve been merging commits for v1.1 in the v1.1 branch.
But I’m unsure of how to manage the git workflow so that, in the end, when we merge that branch to master, the commit history is correct.
In short, I want the new v1.1 commits to be added after the 1.0.x stuff, when they’re ready, and to end up with correctly tagged v1.0.2 and v1.1 versions.
Related issue is a few in-progess PRs, where master changes during that progress.
You can also see an example of a PR that’s otherwise ready to merge to master at #212.
My earlier assumption was that for the latter cases, the PR branches should merge (or rebase?) master.
Does this have anything to do with why the convention to do work on a develop
branch; maybe so one can rebase on it to fix some of these issues?
@dhimmel - any advice?
References:
Issue Analytics
- State:
- Created 3 years ago
- Comments:18 (18 by maintainers)
Top GitHub Comments
Yes.
Unless the merge is for something like
v1.1
where you want to keep commits separate. It’s also possible to rebase a branch on master, but a bit more risky if you mess up.Note that conflicts are actually pretty rare unless changes are large and sweeping or PRs are kept open for long periods of time. You’re getting more now because of the reorganization, lot’s of whitespace changes, etcetera.
In general, it’s the onus of the PR creator to resolve conflicts, but it’s best for maintainers to be cognizant of what actions will create unnecessary conflicts.
Will er really need to keep updating 1.0 once 1.1 is out? I thought 1.1 will be merged into master once it is ready, tagged 1.1.0 and then development takes place there. Any non minor PRs go then in a 1.2 branch.