Merging pull requests

Example 1: Merging PR #123 into master

1. Review the pull request

   • Compilation and checkstyle is verified already by github actions build:PRs are automatically checked.
   • If it is a bug fix, a new unit test, that reproduces the bug, is mandatory.Without such a test, we might accidentally reintroduce the bug again.
   • Add the appropriate labels on the github issue: If the PR fixes a bug, the label “a:bug”should be used.
   • Make sure, the PR is added to the appropriate milestone.If the PR fixes a bug, make sure, that the bug issue is added to the same milestone.

2. The actual merge commands:

   We assume, that the PR has been created from the master branch. If this is not the case,then we’ll either need to rebase or ask for rebasing before merging.

   git checkout master && git pull origin master                    # make sure, you have the latest codegit fetch origin pull/123/head:pr-123 && git checkout pr-123     # creates a new temporary branch "pr-123"

3. Update therelease notes:

   • Are there any API changes, that need to be documented? (Section “API Changes”)

   • Are there any significant changes to existing rules, that should be mentioned?(Section “Modified Rules” / “New Rules” / “Removed Rules”)

     Changes for modified rules are e.g. new properties or changed default values for properties.

   • If the PR fixes a bug, make sure, it is listed under the section “Fixed Issues”.Also make sure, that the PR description mentions this (e.g. “- fixes #issue-number”) andthe this PR is linked with the issue. Merging this PR will then automatically close the issue.
   • In any case, add the PR to the section “External Contributions”.

   • Commit these changes with the message:

     git add docs/pages/release_notes.mdgit commit -m "[doc] Update release notes (#123)"

   Note: If the PR fixes a bug, verify, that we have a commit with the message“Fixes #issue-number”. If this doesn’t exist, you can add it to the commit message whenupdating the release notes:[doc] Update release notes (#123, fixes #issue-number).This will automatically close the github issue.

4. Add the contributor to.all-contributorsrc:

   npx all-contributors add

   And follow the instructions. This will create a new commit into to the current branch (pr-123) updating boththe file.all-contributorsrc anddocs/pages/pmd/projectdocs/credits.md.

5. Now merge the pull request into the master branch:

   git checkout mastergit merge --no-ff pr-123 -m "Merge pull request #123 from xyz:branch    Full-title-of-the-pr #123" --log

   Note: If there are merge conflicts, you’ll need to deal with them here.

6. Run the complete build:./mvnw clean verify -Pgenerate-rule-docs

   Note: This will execute all the unit tests and the checkstyle tests. It ensures,that the complete project can be build and is functioning on top of the current master.
   Note: The profilegenerate-rule-docs will run the doc checks, that wouldotherwise only run on github actions and fail the build, if e.g. a jdoc or rule reference is wrong.

7. If the build was successful, you are ready to push:

   git push origin master

   Since the temporary branch is now not needed anymore, you can delete it:git branch -d pr-123.

Example 2: Merging PR #124 into a maintenance branch

We ask, to create every pull request against master, to make it easier to contribute.But if a pull request is intended to fix a bug in an older version of PMD, then we need to backport this pull request.

Creating a maintenance branch

For older versions, we use maintenance branches, likepmd/5.8.x. If there is no maintenance branch forthe specific version, then we’ll have to create it first. Let’s say, we want a maintenance branch forPMD version 5.8.0, so that we can create a bugfix release 5.8.1.

1. We’ll simply create a new branch off of the release tag:

   git branch pmd/5.8.x pmd_releases/5.8.0 && git checkout pmd/5.8.x

2. Now we’ll need to adjust the version, since it’s currently the same as the release version.We’ll change the version to the next patch version: “5.8.1-SNAPSHOT”.

   ./mvnw versions:set -DnewVersion=5.8.1-SNAPSHOTgit add pom.xml \*/pom.xml pmd-scala-modules/\*/pom.xmlgit commit -m "Prepare next version 5.8.1-SNAPSHOT"

Merging the PR

1. As above: Review the PR

2. Fetch the PR and rebase it onto the maintenance branch:

   git fetch origin pull/124/head:pr-124 && git checkout pr-124     # creates a new temporary branchgit rebase master --onto pmd/5.8.x./mvnw clean verify                                # make sure, everything works after the rebase

   Note: You might need to fix conflicts / backport the commits for the olderPMD version.

3. Update the release notes. See above for details.

4. Now merge the pull request into the maintenance branch:

   git checkout pmd/5.8.xgit merge --no-ff pr-124 -m "Merge pull request #124 from xyz:branch    Full-title-of-the-pr #124" --log

5. Just to be sure, run the complete build again:./mvnw clean verify -Pgenerate-rule-docs.

6. If the build was successful, you are ready to push:

   git push origin pmd/5.8.x

7. Since we have rebased the pull request, it won’t appear as merged on github.You need to manually close the pull request. Leave a comment, that it has beenrebased onto the maintenance branch.

Merging into master

Now the PR has been merged into the maintenance branch, but it is missing in any later version of PMD.Therefore, we merge first into the next minor version maintenance branch (if existing):

git checkout pmd/5.9.xgit merge pmd/5.8.x

After that, we merge the changes into the master branch:

git checkout mastergit merge pmd/5.9.x

Merging vs. Cherry-Picking

We are not using cherry-picking, so that each fix is represented by a single commit.Cherry-picking would duplicate the commit and you can’t see in the log, on which branches the fix has beenintegrated (e.g. gitk and github show the branches, from which the specific commit is reachable).

The downside is a more complex history - the maintenance branches and master branch are “connected” and not separate.