Use the current main branch in docs (#1759)

.github/workflows/pr-build-workflow.yml

@@ -3,7 +3,7 @@ name: Pull Request build
 on:
 
   pull_request:
-    branches: [ master ]
+    branches: [ main ]
 
 jobs:
   build:

CONTRIBUTING.adoc

@@ -48,7 +48,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 SpringIO 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'_
 
 == A Day in the Life of a Contributor
 
@@ -65,12 +65,12 @@ e.g.: `git push origin GH-123`
 `git fetch <your-username>` to grab your branch.
 Alternatively, they can use `git fetch --all` to sync their local state with all of their remotes.
 * If you grant that collaborator 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
+* When ready for your contribution to be reviewed for potential inclusion in the main branch of the canonical
 spring-kafka 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
+* 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 master's current state.
+* 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.
@@ -79,36 +79,36 @@ As stated there: _"> Often, you’ll do this to make sure your commits apply cle
 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
+* 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 GH-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 GH-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** You cannot rebase if you have already pushed your branch to your remote because you'd be rewriting history
 (see **'The Perils of Rebasing'** in the article).
 If you rebase by mistake, you can undo it as discussed
 https://stackoverflow.com/questions/134882/undoing-a-git-rebase[in this StackOverflow discussion].
-Once you have published your branch, you need to merge in the master rather than rebasing.
+Once you have published your branch, you need to merge in the main rather than rebasing.
 * Now, if you issue a pull request, it is much more likely to be merged without conflicts.
 Most likely, any pull request that would produce conflicts will be deferred until the issuer of that pull request makes
 these adjustments.
-* 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:
 
@@ -134,7 +134,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
 

README.md

@@ -79,7 +79,7 @@ None of these is essential for a pull request, but they will all help.
 * 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 another target branch in the main project).
+* If no-one else is using your branch, please rebase it against the current main (or another target branch in the main project).
 
 # License