Create new main branch

Author: pmshaw15

.github/workflows/ci.yml

@@ -2,7 +2,7 @@ name: ci
 on:
   push:
     branches:
-      - master
+      - main
 permissions:
   contents: write
 jobs:

docs/guides/developer_workflows.md

@@ -5,7 +5,7 @@ When working with Git most teams use one of two different workflows depending on
 - [Feature branch workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow) (also known as [GitHub flow](https://guides.github.com/introduction/flow/))
 - [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)
 
-Though FBW is the simpler of the two, it should be used by teams that are confident whenever they change the **main** branch it still remains ready for production ([main is always shippable](https://github.com/DEFRA/software-development-standards/blob/master/docs/principles/coding_principles.md#main-is-always-shippable)).
+Though FBW is the simpler of the two, it should be used by teams that are confident whenever they change the **main** branch it still remains ready for production ([main is always shippable](https://github.com/DEFRA/software-development-standards/blob/main/docs/principles/coding_principles.md#main-is-always-shippable)).
 
 Gitflow is useful for teams that like the space to combine multiple features, or are working on a large feature, before then shipping to production.
 
@@ -31,7 +31,7 @@ In all cases when the branch is created it should be pushed up to the **origin**
 
 Using this workflow it means our branches have specific uses
 
-- **main** is the version of code that is in production (see the principle [main is always shippable](https://github.com/DEFRA/software-development-standards/blob/master/docs/principles/coding_principles.md#main-is-always-shippable))
+- **main** is the version of code that is in production (see the principle [main is always shippable](https://github.com/DEFRA/software-development-standards/blob/main/docs/principles/coding_principles.md#main-is-always-shippable))
 
 - We create a **Hotfix** branch when we need to make a change to production code because of a critical error. When finished we merge the change back into main, but also Develop
 

docs/processes/pull_requests.md

@@ -11,7 +11,7 @@ We also want to respect the time and effort of those reviewing the work. Keeping
 
 ## Always on a branch
 
-No matter how small the change, all changes should be done on a branch and never directly to `main`. This is to support the principle of [main is always shippable](https://github.com/DEFRA/software-development-standards/blob/master/docs/principles/coding_principles.md#main-is-always-shippable)
+No matter how small the change, all changes should be done on a branch and never directly to `main`. This is to support the principle of [main is always shippable](https://github.com/DEFRA/software-development-standards/blob/main/docs/principles/coding_principles.md#main-is-always-shippable)
 
 Clone the repo then create your new branch. For example `git checkout -b add-ea-admin-area-lookup`.
 

docs/standards/quality_assurance_standards.md

@@ -60,7 +60,7 @@ By default, use [Jira](https://www.atlassian.com/software/jira) to manage bugs a
 
 ## Code quality testing
 
-Automated test code must meet Defra [common coding standards](https://github.com/DEFRA/software-development-standards/blob/master/standards/common_coding_standards.md) wherever applicable.
+Automated test code must meet Defra [common coding standards](https://github.com/DEFRA/software-development-standards/blob/main/standards/common_coding_standards.md) wherever applicable.
 
 All development and test code must undergo regular linting to check that it meets minimum standards.