I’ve been using Git for a while now, and I’ve had quite a few setbacks, so here are some of my experiences with git workflow.

What is a Git workflow?

Git workflow you can think of it as a code management scheme followed by team members at work. Git workflow is guided by the following workflow schemes:

• Centralized workflow
• Feature development workflow
• Gitflow workflow
• Forking workflow

The following are specific scenarios and applicability for each workflow:

Centralized workflow

Centralized workflow | center

This works in a similar way to SVN, which has only one master branch. Developers clone remote repositories locally, then make changes and commit locally until the local code is merged into the remote master at a certain point in time. This workflow is best suited to small teams, which may not have as much collaborative and convergent action.

Feature development workflow

This workflow focuses on function development. Instead of directly submitting code to master to ensure that it is stable and clean, it pulls feature branches from master for function development. Team members pull different function branches according to the division of labor for different function development, so that everyone can be completely separated from their work. When the function development is completed, a Pull Request will be sent to the Master branch, and only the approved Code will be allowed to be incorporated into the Master branch. In this way, the Code communication between team members will be strengthened, which is often referred to as Code Review.

Gitflow workflow

This workflow is actually what our team uses, and it’s what many teams use. It’s a bit more complex, but it’s perfect for managing the release and maintenance of large projects, which I’ll talk about in more detail later. The Master branch can be considered a stable branch, while the Develop branch is a relatively stable branch. Feature development takes place on the Feature branch, and release takes place on the Release branch. Bug fixes are done on the Hotfix branch. The author also spent a lot of time to master the whole workflow, encountered a lot of pits, I will share with you later.

Forking workflow

The Forking workflow is no stranger to open source contributors. It has a public central repository that contributors can Fork (clone) as their own private repository. Open source maintainers can push code directly into the central repository, while contributors can only push code into their own private repository. Only the project maintainer accepts a pull request from a code contributor to the central repository does the project truly join.

The subtotal

The above has outlined four common workflows in Git that developers need to practice and understand.

About git workflow, only choose the most appropriate oneself team workflow can effectively improve the efficiency of development, the above mentioned some of the workflow model has its own applicable scenario, how to choose suitable for their team’s workflow in combination with the actual situation of the team members, the team members to understand the degree of workflow, and for the execution of a workflow.

Some practices of our team

Now let’s talk about some practices of our team for Gitflow:

The master branch

• The main branch
• A stable
• It is not allowed to submit code directly to this branch, but only to make merge request to this branch
• Only the release and hotfix branches are allowed to merge

Develop branch

• Development branch
• Relatively stable branches
• For daily development, including code optimization, functional development

Feature branch

• Feature branch
• Pull from the Develop branch for feature development in the next iteration
• Once the functionality is developed, merge it into the Develop branch

The release branch

• Release branch
• Pull from the Develop branch
• For regression testing, bug fixes
• After publishing, tag and close it to Master and Develop

Hotfix branch

• Hot update branch
• Pull from the Develop branch
• Used to urgently fix problems with live versions
• After the fix, tag and close it to Master and Develop

You may find that our workflow is a little different from the standard Gitflow workflow. In fact, there is no standard non-standard workflow. As mentioned above, we need to combine the actual situation of the team, and our team has reached consensus on the current working mode, so there is no problem with some differences.

I haven’t had a git command yet, so let’s have a feel for it:

1). First pull the remote code locally

    git clone xxx
    git checkout -b develop origin/developCopy the code

2). Create a feature branch

    git checkout -b featureCopy the code

3). Multiple developers are developing on the feature, and if changes to develop need to be incorporated into the feature, everyone needs to commit their local code changes to the remote

    git fetch origin 
    git rebase origin/feature
    git push origin featureCopy the code

Then the feature manager rebase the develop branch, delete the original feature branch, and create a new feature branch.

    git fetch origin
    git rebase origin/feature
    git rebase develop
    git push origin :feature
    git push origin featureCopy the code

In this way, feature can keep linear change;

4). After feature development is completed, everyone needs to submit local code changes to remote

    git fetch origin 
    git rebase origin/feature
    git push origin featureCopy the code

Rebase the develop branch, merge the feature branch into the Develop branch, and delete the feature.

    git fetch origin
    git rebase origin/feature
    git rebase develop
    git checkout develop
    git merge feature
    git push origin :featureCopy the code

This ensures that develop maintains linear changes and all feature changes can be fully traceable. 5). After closing the feature, pull out the corresponding release/feature branch, and the subsequent bug fixes are on release/feature

    git checkout develop
    git checkout -b release/featureCopy the code

6). Release /feature branch after bug fixing is completed, pull corresponding tag to push remote release

    git tag -a v1.0 -m 'feature release'
    git push origin v1.0Copy the code

Add the Release /feature to the Develop branch and delete it

    git rebase develop
    git checkout develop
    git merge release/feature
    git push origin :release/featureCopy the code

7). Merge release into master branch after release to ensure that Master is the latest stable version (actual operation is to initiate merge Request)

conclusion

This article focuses on the work for some understanding and practice of git workflow, now our team is in strict accordance with the development of the workflow to complete daily work, a team member recognition and effective workflow is the most suitable for our workflow, not any rules to limit our thinking, but in order to make work more efficient and orderly, Minimize human error. Git is an extensive and profound thing, and the author has been constantly understanding it in practical applications, as well as in the learning of any technology. Just like a poem that programmers often use to put pressure on:

The paper come zhongjue shallow, and must know this to practice.

Resources: blog.jobbole.com/76847/