Change master branch to main branch in documentation

This commit is contained in:
Maurice Parker 2020-07-17 13:27:41 -05:00
parent d9c117fc59
commit ffa3afe83c
3 changed files with 5 additions and 5 deletions

View File

@ -5,7 +5,7 @@ The main repository for NetNewsWire utilizes a [Trunk Based Development](https:/
## Three-Flow
Three-Flow uses 3 branches to facilitate development, stabilize a release, and manage production hotfixes. Development happens on Master and moves to a branch called Candidate when it is ready to be stabilized. New feature development continues on Master and bug fixes to the release candidate happen on Candidate. When the product is released, it is pushed to the Release branch. Hotfixes can happen on the Release branch. Candidate is now free to be reused to stabilize the next release. All bugs found and fixed are back merged to Candidate and then Master respectively.
Three-Flow uses 3 branches to facilitate development, stabilize a release, and manage production hotfixes. Development happens on Main and moves to a branch called Candidate when it is ready to be stabilized. New feature development continues on Main and bug fixes to the release candidate happen on Candidate. When the product is released, it is pushed to the Release branch. Hotfixes can happen on the Release branch. Candidate is now free to be reused to stabilize the next release. All bugs found and fixed are back merged to Candidate and then Main respectively.
![Branching](Images/Branching.png)
@ -15,9 +15,9 @@ That is Three-Flow applied to NetNewsWire. It would be that simple, but we have
![Branching Full](Images/Branching-Full.png)
Today (6/12/2019) we have 2 branches, master and macOS Candidate, in the main repository which will eventually grow to be 5 branches.
Today (6/12/2019) we have 2 branches, main and macOS Candidate, in the main repository which will eventually grow to be 5 branches.
There will also be a number of repository forks that NetNewWire developers will create to do bug fixes and implement new features (not shown here). Typically contributers will fork the Master branch to thier own repository. They would then create a feature/bugfix branch on their repository. Once work on thier forked branch is complete, they will submit a pull request to be merged back into the main repository master.
There will also be a number of repository forks that NetNewWire developers will create to do bug fixes and implement new features (not shown here). Typically contributers will fork the Main branch to thier own repository. They would then create a feature/bugfix branch on their repository. Once work on thier forked branch is complete, they will submit a pull request to be merged back into the main repository main.
## Tagging
@ -25,8 +25,8 @@ Each release should be tagged using [Semantic Versioning](https://semver.org/).
## Submodules
NetNewsWire uses Git submodules to manage project dependencies. All the submodules are under the same project umbrella as NetNewWire and there are no third party dependencies to manage. These submodules are mostly stable at this point. For simplicity sake, all development on the submodules will continue on their repository Master branch. These submodules wont be managed as separate projects with separate releases/tags at this time.
NetNewsWire uses Git submodules to manage project dependencies. All the submodules are under the same project umbrella as NetNewWire and there are no third party dependencies to manage. These submodules are mostly stable at this point. For simplicity sake, all development on the submodules will continue on their repository Main branch. These submodules wont be managed as separate projects with separate releases/tags at this time.
## Summary
There are 3 types of branches: Master, Candidate, and Release. All feature development happens on Master. Stabilization happens on Candidate. Hotfixes happen on Release. Each product gets its own Candidate and Release branches. All candidates and releases get tagged.
There are 3 types of branches: Main, Candidate, and Release. All feature development happens on Main. Stabilization happens on Candidate. Hotfixes happen on Release. Each product gets its own Candidate and Release branches. All candidates and releases get tagged.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 28 KiB

After

Width:  |  Height:  |  Size: 35 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 20 KiB