github.com/amazechain/amc@v0.1.3/docs/developers/codesubmission.md (about)

     1  # Code Submission Standards
     2  
     3  This document outlines the code submission and version control standards, with the code repository being managed based on git.
     4  
     5  Branching Model
     6  The code repository adopts a branching model for management, with the main branches as follows:
     7  - master
     8  - develop
     9  - feature/xxxx
    10  - hotfix
    11  
    12  There are two primary branches in the repository:
    13  master
    14  This is the product's main code branch, maintaining a stable codebase for external use. Direct work on this master branch is not allowed; instead, work should be done on other specified, independent feature branches (we will talk about this shortly). Not directly committing changes to the master branch is also a common rule in many workflows.
    15  
    16  develop
    17  The development branch is the base branch for any new development. When you start a new feature branch, it will be based on development. Additionally, this branch also collects all completed features, waiting to be integrated into the master branch.
    18  
    19  These two branches are known as long-term branches. They will exist throughout the entire lifecycle of the project. Other branches, such as those for features or releases, are only temporary. They are created as needed and deleted once they have completed their task.
    20  
    21  feature
    22  The feature is used for the development of functionalities and features.
    23  
    24  Feature Development
    25  The feature development process is as follows:
    26  1. Start a new feature
    27     Each time a new feature is started, branch off from develop with a feature/xxx branch. Once the feature is completed, merge it back into develop.
    28  2. Feature submission
    29     After the feature development is completed, the developer submits a pull request, waits for code review, and after passing the review, merges into the develop branch and deletes the feature/xxx branch.
    30  
    31  Managing Releases
    32  Release management is another very important topic in version control.
    33  Creating a Release
    34  When you think the code in the "develop" branch is now a mature release version, which means: first, it includes all new features and necessary fixes; second, it has been thoroughly tested. If both points are satisfied, then it's time to start generating a new release:
    35  1. Merge the develop branch into master.
    36  2. Tag the current master and issue the corresponding release version.
    37  
    38  hotfix
    39  Often, just a few hours or days after a release version has been fully tested, some minor errors may be discovered. In this case, we need to create a hotfix branch:
    40  1. Branch off from the main branch to make the hotfix.
    41  2. Submit a pull request and wait for code review.
    42  3. After the review, merge into both the master and develop branches.