Collaborative development process using GIT and github

CataloguePreface Warehouse (Repository)

SOURCE Warehouse Developer Repository Branch (Branch)

Permanent Branch Temporary Branch Workflow (Workflow) Summary reference Preface

(This article assumes that you have a basic git basic concepts, operations have a certain understanding, such as no relevant git knowledge, you can refer to the pro git book for relevant learning and practice)

Many project development uses GIT as an excellent distributed version management tool for project versioning, using the GitHub open source platform as the code warehouse hosting platform. Because git is very flexible to use, there are many different workflows in practice, and different projects and different teams have different ways of collaborating.

This article will introduce a kind of successful Git workflow that has been thoroughly tempered in various size projects, and this workflow has been successfully used in many team development. Mastering git, mastering this workflow, will be of great benefit to everyone's future study and development work.

First, a picture to scare everyone:

The diagram above shows a pattern of collaborative project development using GIT, which is described in more detail next. Warehouse (Repository)

At the beginning and end of the project, we will have two types of warehouses. One is the source repository (origin), and one is the developer repository. Each rectangle in the image above represents a warehouse, the center of our source warehouse, and the other around the source warehouse is the developer repository. Source Warehouse

At the beginning of the project, the initiator of the project builds the most primitive warehouse of a project, and we call it origin, such as our Pinghackers website, where origin is the Pinghackers/blog. The source warehouse has two functions: the code that summarizes the individual developers participating in the project is stored in a stable and available code

The source warehouse should be protected and developers should not be able to develop them directly. Only project managers (usually project sponsors) can operate on them with higher permissions. Developer Repository

As mentioned above, any developer will not directly operate the source warehouse, the source warehouse after the establishment, each developer need to do is to the source warehouse "copy", as their daily development of the warehouse. This copy, which is the fork above GitHub.

Each developer fork the warehouse is completely independent, non-interference, and even with the source warehouse is irrelevant. Each developer warehouse is equivalent to an image of a source warehouse entity, where the developer encodes the image and submits it to its own repository, allowing for easy parallel development between team members. When the development work is completed, the developer can send pull request to the source warehouse, request the administrator to merge their own code into the source warehouse, so that the distributed development work and the final centralized management are realized. Branch (Branch)

Branching is a very important concept in git, and it's a great tool for git to kill. In other centralized version management tools (SVN/CVS), the branch is positioned as an advanced technique, while in git, branching is the daily workflow for each developer. With Git's branch, it's easy to develop and test, and if using git doesn't make you feel relaxed and happy, it's because you haven't learned to use a branch yet. Do not use a little bit of the branch, do not easily tell others that you have used git.

In the picture at the beginning of the article, the dendrite of each rectangle is a branching model of git. As you can see, each developer's warehouse has its own branch route, which is mapped to the source repository by code summarization.

We set up a branching model for git, where there are two types of branches, five permanent branches

Master Branch: Main Branch Develop branch: Development Branch Temporary Branch

Feature branch: Feature Branch release branch: pre-Release branch hotfix branch:bug repair Branch Permanent Branch

A permanent branch is an infinite branch of life, which exists throughout the project's start, development, iteration, and termination processes. A permanent branch has only two master and develop.

Master: The main branch exists from the beginning of the project and is used to store tested, fully stable code, and at any point after the development of the project, the code that master stores should be the code that can be used as a product for the user. Therefore, the Master warehouse code should be kept clean and stable at all times, ensuring that it is fully tested and code REIVEW before it is put into storage. The Master branch is the least active in all branches, updated about every month or every two months, and should be tagged with git every time the Master Update is available, stating that your product has a new version released.

Develop: The development Branch, which was initially detached from the master branch, is used by developers to store basic stable code. As previously mentioned, each developer's warehouse is equivalent to a mirror of the source repository, and each developer's own warehouse also has master and develop. After the developer has done a good job, it is stored in their own develop, when the test is finished, you can start a pull request to the manager, request the develop branch of their own warehouse to merge into the source warehouse develop.

All developer-developed features are aggregated in the develop branch of the source repository, and when the code in the develop is constantly tested, it is gradually stabilizing and approaching the product target. At this point, we can merge the develop branch into the master branch and release a new version. As a result, a product continues to improve and release the process as shown below:

Note that no one should make meaningless merge, commit operations directly to master. Normally, master should only accept develop merges, which means that all master code updates should originate from the code that merges develop. Temporary Branch

Temporary branches, unlike permanent branches, are bound to be deleted during the development process. All temporary branches, usually from develop, will eventually merge back into the develop.

feature: Functional Branch, which is the branch of the function used to develop the project, is the main battle position of the developer. The developer branches from the develop branch in the local repository, the development of the function on the branch, the development is completed and then merged into the develop branch, when the functional branch has completed the task, can be deleted. A functional branch is typically named feature-*,* for the name of a feature that needs to be developed.

For example, let's say I'm a developer of a pinghackers Web site that has already forked the source repository and clone to the local. Now to develop the "discussion" feature of the Pinghackers website. I can do this in the local repository:

Step 1: Switch to develop branch

    >>> git Checkout Develop

Step 2: Branching out a functional branch

    >>> git checkout-b feature-discuss

Step 3: Development work on functional branches, multiple commits, after testing ...

Step 4: Merge the good functions into the develop

    >>> git checkout develop

    # back to develop branch

    >>> git merge--no-ff feature-discuss
    # Merge the good features into develop

    >>> git branch-d feature-discuss
    # Remove Functional Branch

    >>> git push origin develop
    # Submit develop to your remote repository

This completes the development and submission of a feature.

release: Pre-Release Branch, when the product is about to be released, to make the final adjustment and testing, this time can be divided into a pre-release branch, the final bug fix. After the test is complete, the new version is released and the pre-release branch can be deleted. The pre-release branch is generally named release-*.

Hotfix: Fix the bug branch, when the product has been released, suddenly there is a major bug. This is the time to create a new hotfix branch, continue the urgent bug repair work, when the bug is fixed, after the branch merged into master and develop, you can delete the branch. Fix bug branch naming is generally hotfix-*

The release and hotfix branches are far from us. Not detailed, interested students can refer to the final reference materials for learning. Workflow (Workflow)

Long-winded talk about so much, the concept is always abstract. For beginners, all like step-by-step steps for the Fool tutorial, next, we will step-by-step to operate the above mentioned workflow, we feel: Step 1: The construction of the source warehouse

This step is usually done by the project sponsor, we set the administrator as pinghackers, assuming that Pinghackers has established a source repository Pinghackers/git-demo for us, and two permanent Branch Master and develop have been initialized, as shown in figure:

Step 2: Developer Fork Source Warehouse

Once the source warehouse is established, each development can replicate a source repository to its own GitHub account and then use it as a repository for its own development. Assuming I'm a developer in a project, I'll go to the Pinghackers/git-demo Project homepage and fork:

After the fork, I can see a copy of the same as the source warehouse in my own warehouse list. At this time should sigh, you want to and it each other:

Step 3: Clone your own developer repository to local

This step should not be taught, git clone Step 4: Build a functional branch for development

Go into the warehouse, follow the steps of the previous build feature branch, build a functional branch for development, merge, assuming I'm now developing a "discussion" feature:

    >>> git checkout develop
    # switch to ' develop ' branch

    >>> git checkout-b feature-discuss
    # to separate a functional branch

    >> Touch discuss.js
    # Pretend discuss.js is the feature we're going to develop

    >> git Add.
    >> git commit-m ' finish discuss feature '
    # commit changes

    >>> git checkout develop
    # back to develop branch

    >>> git merge--no-ff feature-discuss
    # Merge The good features into develop

    >>> git branch-d feature-discuss
    # Remove Functional Branch

    >>> GIT push origin develop
    # Submit develop to your remote repository

At this point, you go to the develop branch of your GitHub project home page and have discuss.js this file:

Step 5: Submit pull request to Administrator

Let's say I've finished the "discussion" feature (you might also have several merges of your own develop, you've done multiple functions), and after testing, you can ask the administrator to merge the develop branch of your warehouse into In the develop branch of the source repository , this is the legendary pull request.

By clicking the green button on the image above, the developer can silently wait for the administrator to review your submission.

Step 6 Administrator test, merge

Next is the operation of the Administrator, as the administrator of the pinghackers landed on GitHub, I saw the source warehouse initiated pull request.

The thing pinghackers need to do at this point is to review my Code. GitHub offers a very powerful code review feature:

Create a new test branch in his local test to test my code:

>> git checkout develop
# into his local develop branch

>> git checkout-b livoras-develop
# Separate a test branch called Livoras-develop from the develop branch test my Code

>> git pull https://github.com/livoras/git-demo.git Develop
# Pull My code into the test branch to test

To determine if you agree to merge into the develop of the source repository , if tested, you can merge my code into the develop of the source repository:

>> git checkout develop
>> git merge--no-ff livoras-develop
>> git push origin develop

Note that the repository that Pinghakers has been operating in is the source repository. So after a series of actions above, we can see in the Source Warehouse home page:

After a tortuous journey, our discuss.js finally reached the develop branch of the source warehouse from the functional branch of my development warehouse. This is the basic step of a Git & GitHub collaborative workflow. Summary

Git is a powerful tool, it is difficult to imagine the use of such a disgusting and so flexible and elegant tools exist, this is an artifact, we still do more hands-on, more information, so that git become a basic skill, to help themselves to deal with the various project teams work together, become an efficient developer, Excellent project manager. Send everyone a picture of God, a good understanding:

Finally, some references are given for reference study. References A successful git branching Model understanding the git Workflow Github flow Pro git git branch management policy