47 | Creating Team Projects#
When creating a repository, select the organization as the owner.
- You can add teams and assign permissions.
48 | How to Choose the Right Workflow for Your Team?#
Factors to consider: team composition, development and design capabilities, product features, project difficulty.
- Trunk-based Development (Google, Meta)
- Features: Changes are directly integrated into the trunk for rapid iteration.
- Suitable for:
- Teams with strong system design and development capabilities, with an effective feature switching implementation mechanism, similar to feature toggle capability;
- Team members with strong capabilities, developing simple and independent components with low upgrade costs, i.e., component development.
- Git Flow
- Features: Complex process, relatively cumbersome.
- Suitable for: Teams without trunk-based development capabilities, with predetermined release cycles, high product quality requirements, and a need for strict release processes.
- Github Flow
- Features: Master branch as the mainline, stricter than Git Flow.
- Suitable for: Teams without trunk-based development capabilities, requiring continuous integration and immediate release.
- Gitlab Flow (+ Production Branch)
- Features: Master branch + production branch, deployment to the production branch is required before release.
- Suitable for: Teams without trunk-based development capabilities, unable to control precise release timing.
- Gitlab Flow (+ Environment Branch)
- Features: Master branch + environment branch + production branch, deployment to the environment branch for testing, and deployment to the production branch after passing the tests.
- Suitable for: Teams without trunk-based development capabilities, requiring validation through various testing environments before release.
- Gitlab Flow (+ Release Branch)
- Features: Master branch + multiple release branches, maintaining different versions.
- Suitable for: Teams without trunk-based development capabilities, requiring external release and maintenance of different versions.
Summary: Each workflow has its own characteristics, but there are also some similarities. Teams should use the one that suits them best.
49 | How to Choose the Right Branch Integration Strategy?#
Version Tree Evolution: Insights - Network
e.g.
Set Branch Merge Strategy: Settings - Options - Merge Button, 3 options in total.
- Non-linear: Merge using
git merge(⚠️notgit merge --squash)
e.g.
- Linear: Combine all commits to be merged into one commit and add it to the target branch using
git rebase(⚠️notgit merge --squash)
e.g.
- Linear: Add all commits to be merged to the target branch using
git rebase
e.g.
❗️:
- When there is a Pull Request on GitHub, the manager can choose any of the three methods to merge (executed by GitHub).
- The last two methods do not make the branches meet.
50 | Enabling Issue Tracking for Requirements and Tasks#
Issues
- Features: States are categorized as open and closed, classified by labels, and major version changes are marked by milestones.
- Templates can be set: Feature, Bug, custom, can refer to excellent third-party libraries.
- Purpose: Facilitate team communication and record communication details.
PS: Excellent library in China: vuejs/vue - Issues
51 | How to Manage Issues with Projects?#
Projects
- Create a board for easy management.
- Templates can be set for issues, PRs, CRs, etc.
52 | How to Implement Code Review within a Project?#
Settings - Branches - Add rule (Branch protection rules)
- Specify the branch pattern to apply the rules to
- Check the desired rules, such as code review
53 | How to Integrate Multiple Branches in Team Collaboration?#
(Refer to the merge results in Section 49, this section discusses conflict resolution methods)
Scenario: 1) Beijing -> master; 2) Shanghai -> master. ⚠️: 2) will cause conflicts
- Merge
Handling conflicts in Shanghai -> master:
GitHub will merge master into Shanghai to resolve conflicts, create a new commit, and then merge into master.
- Squash
Handling conflicts in Shanghai -> master:
GitHub will merge master into Shanghai to resolve conflicts, create a new commit, and then perform a squash merge operation.
- Rebase
Handling conflicts in Shanghai -> master: GitHub cannot merge and will be stuck after resolving conflicts.
Manual method: Roll back to the following state;
In the local environment, let Shanghai rebase based on the remote master, resolve conflicts (4 times, Shanghai's 4 commits); a better way: git rerere, official documentation
Force push the local Shanghai branch to the remote (because it is no longer fast-forwards)
Finally, perform the rebase merge operation:
Equivalent to cloning 7 commits~
❗️It may seem unnecessary, but from another perspective, it clearly distinguishes the responsibilities of the author and committer.
54 | How to Ensure the Quality of Integration?#
- Configure services
- Find them in the Marketplace, such as Travis CI, codecov, etc., and configure them in the project's Settings - Integrations.
- In addition, you can configure third-party services in your personal Settings - 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, refer to Section 52.
55 | How to Publish Product Packages on GitHub?#
Release feature: Package the code into a binary compressed file for testing and installation.
- Configure the before deploy and deploy sections of the CI script (e.g., .travis.yml);
- Configure tokens, etc.
56 | How to Add Detailed Documentation to a Project?#
Wiki feature.
You can refer to excellent wiki libraries, pull them to your local environment, and then push them to the corresponding Wiki address of the repository (add .wiki to the project name), so that you can write your own documentation.
- You may need to enable Wikis in the project's Settings - Options.
This is a very practical chapter, mainly for GitHub. Let's take a look at Gitlab together in the next chapter~