Bolt Core Development Feature Branch Merges

Bolt Core Development Feature Branch Merges

Git Assumptions

Access Permissions

This documentation assumes you have write access to the Bolt projects repositories, i.e. a core team member.

Remotes

Checking your remotes, we will assume origin to be you own personal fork, and upstream to be the Bolt projects fork.

$ git remote -v

The output would appear similar to:

origin      git@github.com:YourName/bolt.git (fetch)
origin      git@github.com:YourName/bolt.git (push)
upstream    https://github.com/bolt/bolt.git (fetch)
upstream    https://github.com/bolt/bolt.git (push)

Filesystem Layout

This documentation's examples assumes the following working layout:

{Base directory}/
  - master/
  - releases/
    - 3.2/
    - 3.5/
    - 3.6/
    - 4.0/

All of this functionality can be done in one repository directory, but the assumption here is this is a developers workstation.

Updating Local Branches

Prior to beginning, upstream should be synchronised on master, and any release branches that will be involved in the merge cascade.

The following script may be useful to automate this process:

#!/bin/bash

BASE_DIR=/path/to/bolt/
pushd $BASE_DIR/master

BRANCH=$(git symbolic-ref --short -q HEAD)

git fetch --all

BRANCHES=$(git branch -a | grep -E "upstream/release/(2\.[2]|3|4)" | sed 's/remotes\/upstream\///g' | sort)

git fetch --all --prune
git checkout master
git pull upstream master && git push

for rel in $BRANCHES ; do
    pushd $BASE_DIR/$rel
    
    git checkout $rel
    [[ $? -ne 0 ]] && exit 1

    git pull upstream $rel
    [[ $? -ne 0 ]] && exit 1

    git push 
    [[ $? -ne 0 ]] && exit 1

    popd
done

if [ $BRANCH ] ; then
    git checkout $BRANCH
fi

popd

Merging

The process being followed here, is merging from the lowest supported release branch (from release/3.0 onward), into the higher supported release branches, and so on, until the highest is merged into master.

Below is an over blown example of what this might look like:

            release/3.2  — 3.2 is LTS, 3.3 & 3.4 are EoL
                |
            release/3.5  — About to EoL
                |
            release/3.6  — Leading stable 3.x branch
                |
            release/4.0  — 4.0 is in beta
                |
              master

In this example, you would start in release/3.5, and merge release/3.2 into that branch, before moving on to release/3.6 where you would merge with the release/3.5 branch.

This would continue until release/4.0 is merged into master.

Starting the Merge

To commence, change into the master repository directory, and checkout the master branch, and issue the merge command:

git chekout {target branch}
git merge --no-ff {lower release version branch}

Conflicts

Typically you will get merge conflicts in files suck as src/Version.php or app/view/js/bolt.js.

Once those are resolved, simply git add the prior to moving to the next step, e.g.

git add src/Version.php

Committing the Merge

If you have not had any conflicts, this stage will start automatically.

If you were fixing conflicts, and have done a git add for changes, you simply need to:

git commit

You will then end up at the merge messsage dialogue:

Merge branch '{release version branch}'

# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.

Save and exit.

Pushing

git push upstream {release version branch}