Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://docs.pmd-code.org/latest/pmd_projectdocs_committers_merging_pull_requests.html below:

Merging pull requests | PMD Source Code Analyzer

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 main branch. If this is not the case, then we’ll either need to rebase or ask for rebasing before merging.

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

3. Update the release 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”) and the 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 “Merged pull requests”. You can add it by calling .ci/tools/release-notes-add-pr.sh prnumber.

   • Commit these changes with the message:

     git add docs/pages/release_notes.md
     git 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 when updating the release notes: [doc] Update release notes (#123, fixes #issue-number). This will automatically close the github issue.

</div>

1. Add the contributor to .all-contributorsrc:

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

2. Now merge the pull request into the main branch:

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

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

</div>

1. 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 main.

</div>

<div markdown="block" class="alert alert-info" role="alert"> <i class="fas fa-info-circle"></i> **Note:** The profile `generate-rule-docs` will run the doc checks, that would
otherwise only run on github actions and fail the build, if e.g. a jdoc or rule reference is wrong.

</div>

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

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

We ask, to create every pull request against main, 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.

For older versions, we use maintenance branches, like pmd/5.8.x. If there is no maintenance branch for the specific version, then we’ll have to create it first. Let’s say, we want a maintenance branch for PMD 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-SNAPSHOT
   git add pom.xml \*/pom.xml pmd-scala-modules/\*/pom.xml
   git commit -m "Prepare next version 5.8.1-SNAPSHOT"
   

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 branch
   git rebase main --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 older PMD version.

</div>

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

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

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

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

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

   git push origin pmd/5.8.x
   

5. 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 been rebased onto the maintenance branch.

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.x
git merge pmd/5.8.x

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

git checkout main
git merge pmd/5.9.x

Note: This ensures, that every change on the maintenance branch eventually ends up in the main branch and therefore in any future version of PMD.
The downside is however, that there are inevitable merge conflicts for the maven pom.xml files, since every branch changed the version number differently.
We could avoid this by merging only the temporary branch “pr-124” into each maintenance branch and eventually into main, with the risk of missing single commits in a maintenance branch, that have been done outside the temporary branch.

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 been integrated (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 main branch are “connected” and not separate.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4