Secondary git branch to hold multiple pulls until update complete

Question

I have a live app and we will be making some significant changes to it that cannot be done in one pull request. I would like to spin up a separate branch from the master and then merge in changes that other programmers approve. Once it has reached the point where it is ready, that branch is then merged with the master.

How do I go about doing this? I know that you can merge into a branch that isn't master, but can you do a pull request that others approve of and then merge those branches into the non master branch?

Answer 1

I know that you can merge into a branch that isn't master, but can you do a pull request that others approve of and then merge those branches into the non master branch?

Yes, you can open a pull request essentially with any branch as the source and with any other branch as the destination, just like you can do so locally with git checkout dev && git merge add-foo, for example.

I would like to spin up a separate branch from the master and then merge in changes that other programmers approve. Once it has reached the point where it is ready, that branch is then merged with the master.

What you're looking for is an integration branch. That is, a branch whose purpose is to absorb "unstable" changes (usually from other branches) until they are considered stable and then merged into a more stable branch (e.g.: master). See also gitworkflows(7).

The simplest workflow in your scenario is as follows:

First of all, create a "dev" branch from master:

git checkout master
git pull --rebase
git branch dev
git push -u origin dev

This is needed to be done only once.

Note: The --rebase option is given in order to avoid "merge hell" if you have extra commits locally on the current branch (i.e.: master in this case) when pulling. See also the pull.ff only / pull.ff rebase config options.

Beginning

For each bugfix/feature, create a topic branch from master:

git checkout master
git branch add-foo
git push -u origin add-foo
# develop and add commits to it, etc

Whenever a feature branch is ready, open a pull request from topic to dev and review, merge it and then delete the topic branch. Using git directly:

# dev <- add-foo
git checkout add-foo
git pull --rebase
git checkout dev
git pull --rebase
git merge add-foo
git push origin dev
# delete add-foo
git branch -d add-foo
git push -d origin add-foo

Note: I'd suggest doing merges using either only git or only GitHub to make sense of the history (and to potentially aid in scripting), as the auto-generated merge commit messages are rather different.

Once your dev branch is ready, make sure that it contains all the changes from master, as it may have changed in the meantime (especially if you have multiple integration branches). That is, either open a pull request from master to dev, or merge using git directly:

# dev <- master
git checkout master
git pull --rebase
git checkout dev
git pull --rebase
git merge --no-ff master
git push origin dev

Note: --no-ff is used to force a merge commit (this is also what GitHub does by default). This is done here to make the history look cleaner by making each branch have its own separate "lines" on the graph, rather than looking like dev and master are one and the same.

If there were changes on master, you might want to test dev before proceeding. Then, open a pull request from dev to master, or merge using git directly:

# master <- dev
git checkout dev
git pull --rebase
git checkout master
git pull --rebase
git merge --no-ff dev
# push master
git push origin master

Ideally, you now create a tag to mark the version that is being released:

git checkout master
git pull --rebase
git tag -a v1.2.3
git push v1.2.3

When creating the tag, write something like a changelog/summary of the changes from dev.

Now it's all done. For the next release just go back to the beginning.

Details

• Topic branches are always created from master, not dev

This ensures that they have a stable foundation. If a feature depends on another one, try to develop both in the same topic branch in order to avoid issues. If this becomes a problem (e.g.: due to poor project/release management), then create topic branches from dev directly and keep merging them into dev (or just commit directly on dev at this point).

• dev is a long-lived branch (i.e.: not deleted), just like master

Done for simplicity's sake. If you have dynamic integration branches instead (e.g.: sprint1, sprint2, sprintN), they will have a different lifecycle.

---

Note: As hinted before, you can even have multiple independent integration branches (say, one just for bugfixes and another one for features) which merge to master whenever they're ready. It solely depends on how you want to do releases ("release management").

Answer 2

Unclear what you are asking, but GitHub will let you submit a pull request from a branch and then, with the pull request still sitting there, branch from it and merge to it with another pull request.

Answer 3

This is what should be done anyway.

You should merge all your pull requests to a dev branch. Once you release, merge with master. Master branch should only be in sync with the release version. If it's not in sync, then you're doing something "wrong", or more exactly, you're practicing a bad practice.

Create another branch called dev, make this dev branch as your default branch, and do the work there. Forget that you have a master branch, as you only need to merge with master branch in case you have a release.

From GitHub, you can go to the repository's settings, and go to branches: Choose your default branch from there to be your created dev branch: