Skip to content

Administrator Guidelines

Glenn Renfro edited this page Jun 2, 2025 · 40 revisions

These instructions are only relevant to those who have been granted push rights on the upstream repository (those who are in the spring-integration-admin group). Contributors, even admin group members when contributing code, should consult the [Contributor Guidelines](Contributor Guidelines).

Merging Pull Requests

The following steps indicate a typical merge of a Pull Request once its review is complete and it has been approved by at least one team member (other than the original contributor). Note that the button on github can also merge a PR (our comment below emulates the comment it would generate), but while that will only be enabled if the PR can merge cleanly, it will not check if the PR is up-to-date with respect to upstream/main. In order to maintain a clean linear history (with only merge commits being non-linear), the following steps include a rebase (and optionally, an interactive squashing rebase as well).

// sync up
git fetch --all

// make sure your local main is up to date
git checkout main
git merge upstream/main

// grab the branch for the PR
git checkout --track johndoe/INT-123 

// make sure that branch is up-to-date
git rebase main

// get a quick view of the number of commits past upstream/main
git log --oneline

// At this point, you might even do some basic polishing, but typically
// that should be handled by the original committer via PR feedback.
// - Check copyright dates
// - Include a check for whitespace violations and fix or bounce back to contributor.
git log -p --check

// IF you want to squash (no historical value) do an interactive rebase;
// 3 in this case (HEAD~3) being an example number of commits to squash.
git rebase -i HEAD~3

// Polish the comment if necessary during the interactive rebase

// Do a full build
./gradlew build

// go back to the local main
git checkout main

// perform a fast-forward merge from the local tracking branch
git merge INT-123 --ff-only

// verify that the commit log is linear (the --ff-only should prevent non-linear merges)
git log --graph --pretty=oneline

// push to your own fork's main
git push origin main

// push to THE upstream main
git push upstream main

To avoid accidental merge commits, you can configure git to always use fast-forward on main...

git config branch.main.mergeoptions "--ff-only"

Sometimes, however, if there are a number of commits on a topic branch and it is desirable to keep them separate, then use a non-fast-forward merge instead (but you will have to remove the mergeoptions above).

// merge the local tracking branch into main with a comment having this format (and no fast-forward)
git merge -m "Merge pull request #99 from johndoe/INT-123" --log --no-ff INT-123

// polish the results of the previous --log if necessary
git commit --amend

// push to your own fork's main
git push origin main

// push to THE upstream main
git push upstream main

After the branch has been merged, if that branch did require rebasing main, then it will not be automatically closed within github. If that's the case, manually close the PR in github, optionally including a comment. GitHub will close the PR if no rebase was required, but you should check the PR list anyway.

Common Questions

  1. What if my push to upstream main fails after I've merged the branch into my local main? This can occur if someone else has pushed another PR to the upstream main after your last rebase on the branch.
    The solution is as follows:
// Update your main branch
git fetch --all

//Reset the index and working tree to remote. 
git reset --hard upstream/main

// Go back to your branch
git checkout INT-123

// Rebase the branch to include all changes
git rebase main

// Do a full build
./gradlew build

// go back to the local main
git checkout main

// perform a fast-forward merge from the local tracking branch
git merge INT-123 --ff-only

// verify that the commit log is linear (the --ff-only should prevent non-linear merges)
git log --graph --pretty=oneline

// push to your own fork's main
git push origin main

// push to THE upstream main
git push upstream main

Warning: Any changes to tracked files in the local main since <commit> are discarded.

Release Process

TBD

Clone this wiki locally