This article is reprinted from: Watchtower

Git is a great tool, but it’s not easy to use well. There are many tutorials on the web that teach you how to use Git commands, but very few teach you how to manage the branches of your project (git workflow).

If you’re given a huge project, how do you fix bugs on the line, make sure branches are always clean and usable, and ensure code stability on the project?

We developed a set of management methods, you learn it is your experience.

Management tool

First, instead of using tools like Zen Tao to document bugs and requirements, we use the Issue feature on Github. Because bugs and requirements are associated with branches, if you use a third-party tool (Zen Tao), it will be disconnected from branches and difficult to achieve unified management. You can also use tools like Gitea and Gogs, which do the same thing as Github. This article takes Gitea as an example to explain.

Classification of branches

First, we divide the branches into three fixed branches:

  • test

Test branches, newly developed features or bug fixes, waiting for testers to test them.

  • master

The pre-release branch, which contains tested new features or bug fixes, can be released at any time.

  • prod

A formal branch, consistent with the code run in production.

Two dynamic branches, the branch name for developing new features starts with “new_” and the branch name for fixing bugs starts with “fix_”. Dynamic branches can be deleted when used up.

Create a tag

For issue and PR, we need to attach the corresponding tag to identify the corresponding status. Generally speaking, we will establish the following 17 tags:

  • Level 1 bug
  • The secondary bug
  • Level 3 bugs
  • Invalid bug
  • Duplicate bug
  • Do not repair
  • Unable to reproduce
  • Level of demand
  • The secondary demand
  • doubt
  • resolved
  • Confirm the address
  • The implemented
  • Confirm the implementation
  • Handle failure
  • Code optimization
  • Is not related PR

Division of personnel

There are four roles in our overall git branch management approach

  • Tester: Tests the code written by developers
  • Developers: Write code to implement new features or fix bugs
  • Product Manager: Demand
  • R&d team leader: Code review, merge code

Specific processes and roles

Since each character does different things, I split it up by character and action.

Action: New requirement

Role: Product manager
  1. Create an issue, label it with requirements (level 1 requirements) and assign it to the r&d team leader.
  2. The development team leader, assigned to the appropriate developer, marks milestones.
Role: Developer
  1. Search for new requirements by assigning people, and the “requirements” TAB.
  2. New demand branch based on master, write code to achieve new demand.
  3. Once the code is written, merge it into the Test branch.
  4. Mention of pr
  5. Go to Gitea and find the corresponding issue, then associate the issue with the proposed PR and mark the issue as “implemented”. And assign test requirements to testers.
Role: tester
  1. Test whether the new requirements are fulfilled on schedule by assigning people and searching for new requirements under the Implemented TAB.
  2. If there is a bug, add an issue to record the bug. And associate the BugIssue with the requirements Issue.
  3. If the new requirement has no bugs or all related bugs have been fixed, mark the issue as “confirmed implementation” and mark the PR associated with the requirement as “confirmed implementation”.

Action: Fix bugs

Role: tester
  1. Create an issue, tag a bug, and assign it to the developer concerned
  2. Wait for developers to fix bugs.
  3. Find the bug to retest and retest it by assigning and using the “Solved” TAB.
  4. If the bug is successfully fixed, mark it as “confirmed resolved”, remove the “Resolved” label, and mark the associated PR as “Confirmed resolved”. If the bug is not fixed successfully, mark it as “resolved failed” and remove the “Resolved” label. Then assign it to developers.
Role: Developer
  1. Search for unresolved bugs by assigning people, and the bug TAB or “resolve failures” TAB.
  2. New bug repair branch based on master, write code to modify the bug.
  3. Once the code is written, merge it into the Test branch.
  4. Mention PR (note that if a bug is generated by a new requirement, there is no need to re-mention PR, just use the SAME PR for the new requirement)
  5. Go to Gitea and find the corresponding issue, mark the issue as “resolved”, and then associate the issue with the proposed PR. And assign bugs to testers.

Action: Merge code

Role: R&d team leader
  1. Look for a label in the PR header that contains “Confirm solution” or “Confirm implementation”.
  2. Check whether PR is associated with an issue. If no issue is associated, it cannot be merged. (Because you don’t know if there are bugs)
  3. Check to see if the issues associated with PR are marked “confirm resolution” or “Confirm implementation” and if so can be merged. Close all related issues first
  4. Check that the code conforms to the specification. (code review)
  5. After closing the associated issue, merge the PR.

Action: Release a new version to production

Role: R&d team leader
  1. Check to see if all the PR to be merged has been merged.
  2. Merge branches of Master directly into PROD.
  3. Publish the PROD branch

Action: Temporarily fix bugs in the production environment

Role: Developer
  1. Create a bug fix branch based on the master branch.
  2. Merge the bug fix branch into the test branch after the code is written.
  3. When you pass the test, ask for a PR.
Role: R&d team leader
  1. After code reivew, merge PR
  2. Cherry pick this PR involved to the PROD branch
  3. Publish the PROD branch

Commercial time: Watchtower, just 3 lines of code, to help you handle business alerts.