Shulou(Shulou.com)05/31 Report--

Today, Xiaobian will share with you the relevant knowledge points of Git's collaboration mode in the project. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you will gain something after reading this article. Let's find out together.

1. Distributed workflow

In contrast to traditional centralized version control systems (CVCS), Git's distributed nature makes collaboration among developers more flexible and diverse.

In a centralized version control system, each developer is like a node connected to a hub, working much like each other. In Git, each developer acts as both a node and a hub. That is, each developer can contribute their code to other repositories while maintaining their own public repository on which others can build and contribute code.

As a result, Git's distributed collaboration can spawn a variety of different workflows for your projects and teams. Here are a few common Git workflows.

You can choose to use one of them, or mix and match their features.

2. Centralized workflow

Git To facilitate collaboration between clients, Git version control systems typically set up a central repository server, with the goal that all clients update versions from that host and submit the latest versions, and that clients in this mode of work are equal.

Centralized workflow is like SVN, with the central repository as the single point entity for all changes to the project, all changes committed to the Master branch. The main difference between this approach and SVN is that developers have native libraries, but many Git features are not used.

As shown below:

The above illustration:

A remote warehouse.

A master branch.

Each team member has a local repository where code editing, staging, and submission work takes place.

Centralized workflow summary:

Applicable people: small development teams, small teams accustomed to using SVN tools.

Working methods:

The team leader creates a remote repository, creating a master branch that the team members can read and write.

Each developer git clones remote repositories to local repositories, developing on the master branch.

Git pull updates the master branch of the remote repository to the local version every time you develop.

Git commit to local repository every time development is complete, then git push to remote repository.

Disadvantages:

Forget git push, it will always be submitted to the local repository, not pushed to the remote repository.

Forgetting git pull results in inconsistency between the local repository and the central repository, resulting in file conflicts.

A large number of git pull operations result in an increase in the number of branch merges in Git, an increase in the number of base changes in Git, and a decrease in Git performance.

3. Branch workflow

Functional branch workflow assigns a special branch for each new function to develop on the basis of centralized workflow, that is, a branch is created outside the master branch, all new functions developed by programmers are pushed to this branch, and when the function is mature, this branch is merged into the master branch.

As shown below:

Branch workflow summary:

Target audience: Small development teams, teams familiar with Git branches.

Working methods:

The team leader creates a remote repository, creating a master branch that the team members can read but not write.

Each developer git clones remote repositories to local repositories.

Each developer creates his own feature branch and develops on the feature branch. (Remember, the feature branch is based on the master branch)

Each developer git commits to their feature branch in the local repository each time they finish development, and then git pushes to the remote repository.

Remind team leaders by pulling request and browse the team member submission feature branch.

The team leader pulls down the feature branch and merges it into the master branch of his local repository for testing.

After the team leader tests the feature branch, the team leader is responsible for merging the feature branch into the master branch of the remote repository.

Team leader deletes merged feature branches in remote repository.

Team members delete the merged feature branch in the local repository.

Team members switch the local repository branch to the master branch, and git pull updates the master branch version of the local repository to the master branch version of the remote repository.

Disadvantages:

Increase the workload of the team leader.

Added team member submission step.

Description: Pull Request is used to allow other team members or team leaders to view your code and propose code modifications or discussions.

GitFlow workflow (most popular)

Gitflow workflow does not use concepts and commands beyond the functional branching workflow above, but assigns a very specific role to different branches and defines how and when branches interact.

In addition to the master branch, which stores historical releases, there is also a develop branch that is a feature integration branch.

When initialization is complete, a programmer wants to develop a feature, not by pulling a new branch directly from the master branch, but by using the develop branch as the parent branch.

When the new feature is completed, it is merged back into the parent branch, and the commit of the new feature does not interact directly with the master branch.

Once there is enough functionality on the develop branch to make a release (or near a given release date), checkout a release branch from the develop branch.

The new release branch is used to start the release cycle, so new features cannot be added to this branch after this point in time, and the branch should only do Bug fixes, documentation, and other release-oriented tasks.

Once all the work for external releases is done, the release branch merges into the master branch and assigns a version number labeled Tag.

In addition, changes made since the new release branch are merged back into the develop branch.

The maintenance branch, or hotfix branch, is used to quickly patch production releases and is the only branch that can be forked directly from the master branch.

When the fix is complete, the changes should immediately be merged back into the master and develop branches (the current release branch), and the master branch should be tagged with the new version number.

Using a dedicated branch for Bug fixes allows the team to quickly work out the problem without interrupting other work or waiting for the next release cycle.

You can think of the maintenance branch as a temporary release that is processed directly on the master branch.

The summary is: Gitflow workflow makes the release iteration process smoother by setting up independent branches for feature development, release preparation and maintenance, making full use of the characteristics of branches. The strict branching model also provides some much-needed structure for large projects.

The following diagram is a complete Gitflow workflow development diagram, but the actual development work environment may be streamlined:

Gitflow workflow summary:

Audience: Any development team, familiar with Git branches.

Working methods:

Project maintainers create remote repositories for project maintainers, creating master and develop branches that contributors can read but not write.

Each contributor git clone branches develop from remote repositories to local repositories. (Remember, the develop branch is equivalent to the master branch, including feature development, modification, and testing.) Master branch is equivalent to final branch)

Each contributor creates its own feature branch in the local repository and develops on the feature branch.

In the feature branch, you can create multiple feature branches to continue developing the project.

Each contributor git commits to its own feature branch in the local repository each time it completes development, and then git pushes to the remote repository.

Alert project maintainers by pulling request and browse the contributor submission feature branch.

Project maintainers pull down the feature branch and merge it into their local repository's develop branch for testing.

After the team leader tests the feature branch, the team leader is responsible for merging the feature branch into the develop branch of the remote repository.

The project maintainer will release the git tag on the branch with the version number.

Project maintainers can create release branches from the develop branch, merge release branches into master branches, and synchronize master branches to the develop branch.

The project maintainer removes the merged feature branch from the remote repository.

Each contributor deletes the merged feature branch in the local repository.

Each contributor switches the local repository branch to the develop branch, and git pull updates the master branch of the local repository to the develop branch version of the remote repository.

Description: Gitflow workflow is a multi-branch workflow proposed by Vincent Driessen engineer.

Forking workflow (occasionally used)

Forking workflow can also be called distributed workflow, which is derived from GitFlow workflow, making full use of Git's advantages in branching and cloning, plus pull request function, to achieve the purpose of code review. You can manage submissions from developers on large teams and accept submissions from untrusted contributors.

This workflow allows each developer to have a server-side repository (this repository can only be pushed by themselves, but everyone can pull and modify), each programmer can push code to his server-side repository, but not to the official repository, only the project maintainer can push to the official repository, so that the project maintainer can accept any developer's commit without giving him write permission to the official code repository.

This workflow is suitable for open source projects in the open source community. Everyone contributes to the project uniformly, but one person or team manages the project as a developer. All contributors 'code is reviewed by the developer, and after its function is perfected, the developer pushes it into the formal repository.

Summary:

Forking workflows are better suited to safely and reliably managing large teams of developers and accepting submissions from untrusted contributors.

In practice, we might use it if we occasionally need someone outside the team to help us solve a problem.

This type of workflow is not used often, and it is only advantageous when the project is extremely complex or requires multiple levels of management. In this way, the overall project leader (i.e., supervisor) can delegate a large amount of scattered integration work to different team leaders, and then pool large subsets of code at different times for later integration.

The diagram is as follows:

Tip:

Each member can pull code from the central repository.

Each level member can only submit code one level up.

The next level merges the code and then continues to submit the code to the next level.

Finally, only dictators can submit code to the central repository.

Fork Workflow (Distributed Warehouse Workflow) Summary:

Audience: Large development teams, teams familiar with Git branches.

Working methods:

The master project maintainer creates a remote repository, creating a master branch that is readable but not writable by the slave project maintainer.

From the maintainer to his own remote repository, including the master branch, by forking copies of the master maintainer's remote repository. (Remember that the slave project maintainer's remote repository is independent of the master project maintainer's remote repository)

From the project maintainer git clone copy of the master project maintainer remote repository to the local repository.

Create your own feature branch from the project maintainer and develop on the feature branch.

Every time the project maintainer completes development, git commits to its own feature branch in the local repository, and then git pushes to the remote repository.

Merge your own feature branch from the maintainer to the master branch from the maintainer's remote repository via pull request.

Remove the merged feature branch from the project maintainer in the remote repository.

Remove the merged feature branch from the project maintainer's local repository.

Push from the project maintainer in the remote repository via pull request to the master project maintainer's remote repository.

The master project maintainer gets a push from the project maintainer's remote repository via pull request.

The master project maintainer performs remote repository code reviews, testing from the project maintainer.

After confirmation by the master project maintainer, it can be merged directly into the master project maintainer's remote repository.

That's all for "What is Git's collaboration model for projects?" Thanks for reading! I believe everyone has a great harvest after reading this article. Xiaobian will update different knowledge for everyone every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.