From 0757aac4f142f880695692334f8189dbd5bba057 Mon Sep 17 00:00:00 2001 From: Artem Bilan Date: Thu, 15 Apr 2021 11:38:07 -0400 Subject: [PATCH] Use current main branch in docs instead of master (#1322) --- .github/workflows/pr-build-workflow.yml | 2 +- CONTRIBUTING.adoc | 30 ++++++++++++------------- README.md | 4 ++-- src/dist/README.md | 2 +- 4 files changed, 19 insertions(+), 19 deletions(-) diff --git a/.github/workflows/pr-build-workflow.yml b/.github/workflows/pr-build-workflow.yml index bda4013e..563aa47f 100644 --- a/.github/workflows/pr-build-workflow.yml +++ b/.github/workflows/pr-build-workflow.yml @@ -2,7 +2,7 @@ name: Pull Request build on: pull_request: - branches: [ master ] + branches: [ main ] jobs: build: diff --git a/CONTRIBUTING.adoc b/CONTRIBUTING.adoc index 1c3ab2b8..23425ec6 100644 --- a/CONTRIBUTING.adoc +++ b/CONTRIBUTING.adoc @@ -47,7 +47,7 @@ _you should see only 'origin' - which is the fork you created for your own githu _you should now see 'upstream' in addition to 'origin' where 'upstream' is the Spring repository from which releases are built_ 6. `git fetch --all` 7. `git branch -a` -_you should see branches on origin as well as upstream, including 'master' and 'maint'_ +_you should see branches on origin as well as upstream, including 'main' and 'maint'_ == A Day in the Life of a Contributor @@ -61,37 +61,37 @@ e.g.: `git push origin GH-123` * If you want to collaborate with another contributor, have them fork your repository (add it as a remote) and `git fetch ` to grab your branch. Alternatively, they can use `git fetch --all` to sync their local state with all of their remotes. * If you grant those collaborator(s) push access to your repository, they can even apply their changes to your branch. -* When ready for your contribution to be reviewed for potential inclusion in the master branch of the canonical spring-amqp repository (what you know as 'upstream'), issue a pull request to the SpringSource repository (for more detail, see https://help.github.com/articles/using-pull-requests/[Using pull requests]). -* The project lead may merge your changes into the upstream master branch as-is, he may keep the pull request open yet add a comment about something that should be modified, or he might reject the pull request by closing it. -* A prerequisite for any pull request is that it will be cleanly merge-able with the upstream master's current state. +* When ready for your contribution to be reviewed for potential inclusion in the main branch of the canonical spring-amqp repository (what you know as 'upstream'), issue a pull request to the SpringSource repository (for more detail, see https://help.github.com/articles/using-pull-requests/[Using pull requests]). +* The project lead may merge your changes into the upstream main branch as-is, he may keep the pull request open yet add a comment about something that should be modified, or he might reject the pull request by closing it. +* A prerequisite for any pull request is that it will be cleanly merge-able with the upstream main's current state. **This is the responsibility of any contributor.** If your pull request cannot be applied cleanly, the project lead will most likely add a comment requesting that you make it merge-able. For a full explanation, see https://git-scm.com/book/en/Git-Branching-Rebasing[the Pro Git section on rebasing]. As stated there: _"> Often, you’ll do this to make sure your commits apply cleanly on a remote branch — perhaps in a project to which you’re trying to contribute but that you don’t maintain."_ == Keeping your Local Code in Sync -* As mentioned above, you should always work on topic branches (since 'master' is a moving target). However, you do want to always keep your own 'origin' master branch in synch with the 'upstream' master. +* As mentioned above, you should always work on topic branches (since 'main' is a moving target). However, you do want to always keep your own 'origin' main branch in synch with the 'upstream' main. * Within your local working directory, you can sync up all remotes' branches with: `git fetch --all` -* While on your own local master branch: `git pull upstream master` (which is the equivalent of fetching upstream/master and merging that into the branch you are in currently) +* While on your own local main branch: `git pull upstream main` (which is the equivalent of fetching upstream/main and merging that into the branch you are in currently) * Now that you're in synch, switch to the topic branch where you plan to work, e.g.: `git checkout -b AMQP-123` * When you get to a stopping point: `git commit` -* If changes have occurred on the upstream/master while you were working you can synch again: - - Switch back to master: `git checkout master` - - Then: `git pull upstream master` +* If changes have occurred on the upstream/main while you were working you can synch again: + - Switch back to main: `git checkout main` + - Then: `git pull upstream main` - Switch back to the topic branch: `git checkout AMQP-123` (no -b needed since the branch already exists) - - Rebase the topic branch to minimize the distance between it and your recently synched master branch: `git rebase master` + - Rebase the topic branch to minimize the distance between it and your recently synched main branch: `git rebase main` (Again, for more detail see https://git-scm.com/book/en/Git-Branching-Rebasing[the Pro Git section on rebasing]). -* **Note** While it is generally recommended to __not__ re-write history by using `push --force`, and we do not do this on `master` (and release) branches in the main repo, we require topic branches for pull requests to be rebased before merging, in order to maintain a clean timeline and avoid "merge" commits. +* **Note** While it is generally recommended to __not__ re-write history by using `push --force`, and we do not do this on `main` (and release) branches in the main repo, we require topic branches for pull requests to be rebased before merging, in order to maintain a clean timeline and avoid "merge" commits. * If, while rebasing for the merge, we find significant conflicts, we may ask you to rebase and `push --force` to your topic branch after resolving the conflicts. -* Assuming your pull request is merged into the 'upstream' master, you will actually end up pulling that change into -your own master eventually, and at that time, you may decide to delete the topic branch from your local repository and +* Assuming your pull request is merged into the 'upstream' main, you will actually end up pulling that change into +your own main eventually, and at that time, you may decide to delete the topic branch from your local repository and your fork (origin) if you pushed it there. - to delete the local branch: `git branch -d GH-123` - to delete the branch from your origin: `git push origin :GH-123` == Maintain a linear commit history -When merging to master, the project __always__ uses fast-forward merges. +When merging to main, the project __always__ uses fast-forward merges. When issuing pull requests, please ensure that your commit history is linear. From the command line you can check this using: @@ -117,7 +117,7 @@ This command, will provide the following output, which in this case shows a nice ---- If you see intersecting lines, that usually means that you forgot to rebase you branch. -As mentioned earlier, **please rebase against master** before issuing a pull request. +As mentioned earlier, **please rebase against main** before issuing a pull request. == Mind the whitespace diff --git a/README.md b/README.md index 8ef9241d..cc8d2529 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -Spring AMQP [](https://build.spring.io/browse/AMQP-MASTER) [![Join the chat at https://gitter.im/spring-projects/spring-amqp](https://badges.gitter.im/spring-projects/spring-amqp.svg)](https://gitter.im/spring-projects/spring-amqp?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) +Spring AMQP [](https://build.spring.io/browse/AAMQP-MAIN) [![Join the chat at https://gitter.im/spring-projects/spring-amqp](https://badges.gitter.im/spring-projects/spring-amqp.svg)](https://gitter.im/spring-projects/spring-amqp?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) =========== This project provides support for using Spring and Java with [AMQP 0.9.1](https://www.rabbitmq.com/amqp-0-9-1-reference.html), and in particular [RabbitMQ](https://www.rabbitmq.com/). @@ -115,7 +115,7 @@ None of these is essential for a pull request, but they will all help. They can * Add yourself as an @author to the .java files that you modify substantially (more than cosmetic changes). * Add some Javadocs and, if you change the namespace, some XSD doc elements. * A few unit tests would help a lot as well - someone has to do it. -* If no-one else is using your branch, please rebase it against the current master (or other target branch in the main project). +* If no-one else is using your branch, please rebase it against the current main (or other target branch in the main project). # License diff --git a/src/dist/README.md b/src/dist/README.md index 79aeda05..f5ca66ae 100644 --- a/src/dist/README.md +++ b/src/dist/README.md @@ -114,7 +114,7 @@ None of these is essential for a pull request, but they will all help. They can * Add yourself as an @author to the .java files that you modify substantially (more than cosmetic changes). * Add some Javadocs and, if you change the namespace, some XSD doc elements. * A few unit tests would help a lot as well - someone has to do it. -* If no-one else is using your branch, please rebase it against the current master (or other target branch in the main project). +* If no-one else is using your branch, please rebase it against the current main (or other target branch in the main project). # License