First published on fXM5547

reference

  • Open. Leancloud. Cn/git – branch -…
  • Blog.coding.net/blog/featur…
  • Blog.coding.net/blog/git-wo…
  • Blog.coding.net/blog/princi…

introduce

This restriction applies to all iOS and Android engineering code. The management tool uses the Git hosting service provided by Coding.net.

Git workflows come in many forms, both good and bad. But teamwork requires consistent norms, so be sure to follow them.

In addition to consistency, the purpose of this specification is to:

  • It is convenient for development and testing students to cooperate, efficiently complete the research and development work, and produce high-quality results.
  • When urgent bugs need to be fixed and released as soon as possible, you can release only necessary Bugfixes without releasing other changes that should not be released at the same time.

Branch and the tag

Using Feature Branch Workflow, create a Feature Branch as required

Branch: Feature Branch, master, and release. Master is the default branch and Release is the branch used for publishing.

  • Create a branch from master, push it to a remote repository, submit a merge request to master, and delete the branch after merge.
  • master:Only responsible for merging the code of each feature branch and ensuring that the master branch is testable at any time and can be released after testing.Integration is automatically triggered after submission.
  • Release: is the currently published branch where only new or additional commits from master cherrypick can be created.

Tag: Tag for each release.

  • SDK and App application tags follow<major>.<minor>.<patch>For example, 2.5.1, referSemVer;
  • The server program’s tag is named after the date of publication, such as 2016.07.28, followed by lower case letters if there is a bugfix, such as 2016.07.28 followed by 2016.07.28A and then 2016.07.28b.

    branch&tag

Atomic commits should be used as much as possible, i.e. commit based on a single function (worktile single task or its split function). It is not recommended to commit multiple functions at once, and each commit must be a complete function that can be executed. A clear commit log must be written at commit time.

Development test process

  • Development test process

Release management

Before all releases, the test engineer must confirm that the tests are fully covered and passed.

  • Release process: Remove the old Release Branch and create a new Release Branch from the current master;
  • Bugfix process: A Bugfix is a fix for a bug in a released Branch program. Fix one or more commit of this defect from master Branch cherry pick in Release Branch;

Detailed steps for releasing the new version

  1. Delete the release branch from Coding;
  2. Create a release branch from the master branch in Coding;
  3. Package from the Release branch for integration testing and release;
  4. Tag the release branch on Coding and add the update log.

Release patch details

  1. Update the entire project first;
  2. Git switches to the Release branch;
  3. Run the git cherry-pick commit_id command.
  4. Push to the remote release branch;
  5. Package from the Release branch for integration testing and release.
  6. Tag the release branch on Coding and add the update log.

other

  • Not every bug requires a special bugfix release, but for non-urgent bugs, the fix can be released with the next release.
  • For master and Release branches, only the owner has readwrite permission; other developers only have read permission.