47 | Creating Team Projects#
When creating a repository, the Owner can choose the organization.
- Teams can be added and permissions granted.
48 | How to Choose a Suitable Workflow for Your Team?#
Factors to consider: team composition, R&D design capabilities, product characteristics, project difficulty.
- Trunk Development Method (Google, Meta)
- Characteristics: Changes are directly integrated into the trunk, allowing for rapid iteration.
- Suitable for:
- Teams with strong system design and development capabilities, having an effective feature toggle implementation mechanism, similar to feature switch capabilities;
- Team members with strong abilities, developing simple, independent components with low upgrade costs, i.e., component development.
- Git Flow
- Characteristics: Complex process, relatively cumbersome.
- Suitable for: Teams lacking trunk development capabilities, having a scheduled release cycle, requiring high product quality, and needing to follow strict release processes.
- GitHub Flow
- Characteristics: master as the main line, stricter than Git Flow.
- Suitable for: Teams lacking trunk development capabilities, needing to integrate and release at any time.
- GitLab Flow (+ Production Branch)
- Characteristics: master branch + production branch, releases need to be deployed to the production branch first.
- Suitable for: Teams lacking trunk development capabilities, unable to control the exact release time.
- GitLab Flow (+ Environment Branch)
- Characteristics: master branch + environment branch + production branch, releases need to be tested on the environment branch before being deployed to the production branch.
- Suitable for: Teams lacking trunk development capabilities, needing to pass validation through various testing environments before release.
- GitLab Flow (+ Release Branch)
- Characteristics: master branch + multiple release branches, allowing maintenance of different versions.
- Suitable for: Teams lacking trunk development capabilities, needing to release and maintain different versions externally.
Summary: Each workflow has its own characteristics, but there are also some similarities; teams should use what suits them best.
49 | How to Choose a Suitable Branch Integration Strategy?#
Version Tree Evolution: Insights——Network
eg.
Set Branch Merge Strategy: Settings——Options——Merge Button, with 3 options.
- Non-linear: Merge using the merge method (
git merge, ⚠️ notgit merge --squash)
eg.
- Linear: Consolidate all commits to be merged into one commit and add it to the target branch (
git rebase, ⚠️ notgit merge --squash)
eg.
- Linear: Add all commits to be merged to the target branch (
git rebase)
eg.
❗️：
- When there is a Pull Request on GitHub, the manager can choose any of the three methods above to merge (executed by GitHub).
- The latter two methods do not bring the branches together.
50 | Enable Issue Tracking for Requirements and Tasks#
Issues
- Characteristics: Status is divided into open and close, categorized by Labels, and major version changes are marked by Milestone.
- Templates can be set: Feature, Bug, Custom, and can refer to excellent third-party libraries.
- Purpose: Facilitate team communication and record communication details.
PS: Excellent domestic library: vuejs/vue——Issues
51 | How to Manage Issues with Projects?#
Projects
- Create a Kanban feature for easy management.
- Templates can be set for Issue, PR, CR, etc.
52 | How to Implement Code Review Internally in a Project?#
Settings——Branches——Add rule (Branch protection rules)
- Specify the branch pattern to which the rules apply
- Check the required rules, such as code review
53 | How to Integrate Multiple Branches During Team Collaboration?#
(Refer to the merging results in section 49, this section discusses conflict resolution methods)
Scenario: 1) Beijing->master; 2) Shanghai->master. ⚠️: 2) will cause conflicts
- Merge
Handle the conflict from Shanghai->master:
GitHub will first merge master into Shanghai to resolve the conflict, creating a new commit, and then merge it into master.
- Squash
Handle the conflict from Shanghai->master:
GitHub will first merge master into Shanghai to resolve the conflict, creating a new commit, and then perform a squash merge operation.
- Rebase
Handle the conflict from Shanghai->master: GitHub cannot merge and will get stuck after resolving the conflict.
Manual method: Roll back to the following state;
Locally rebase Shanghai based on the remote master to resolve the conflict (4 times, Shanghai's 4 commits; a better way: git rerere, official documentation)
Force push the local Shanghai branch to the remote (since it is no longer fast-forwards)
Finally, perform the rebase merge operation:
Equivalent to cloning 7 commits～
❗️ It may seem redundant, but from another perspective, it clearly distinguishes the responsibilities of Author and Committer.
54 | How to Ensure Integration Quality?#
- Configure Services
- Find in the Marketplace, such as Travis CI, codecov, etc., which can be configured in the project's Setting--Integrations.
- Additionally, you can configure third-party services in your personal Setting-- Developer settings--OAuth Apps, or add your own or open-source services in GitHub Apps.
- Configure Branch Protection Rules
- Go to Settings--Branches--Branch protection rules to set, refer to section 52.
55 | How to Release Product Packages on GitHub?#
Release feature: Package the code into a binary compressed file for easy testing and installation.
- Configure CI scripts (such as .travis.yml) for the before deploy and deploy sections;
- Configure tokens, etc.
56 | How to Add Detailed Documentation to a Project?#
Wiki feature.
You can refer to excellent wiki libraries, pull them locally, and then push them to the corresponding Wiki address of the repository (adding .wiki after the project name), allowing you to write your own documentation.
- You may need to enable Wikis in the project's Settings——Options.
This is a very practical chapter, mainly focused on GitHub; in the next chapter, we will look at GitLab together.