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

The main content of this article is to explain "what is the work flow of git flow R & D". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "what is the git flow R & D workflow?"

What is git-flow?

Once you install git-flow, you will have some extension commands. These commands automatically perform multiple actions in a predefined order. Yes, this is our work flow!

Git-flow is not meant to replace Git, it's just very clever and efficient in scripting standard Git commands.

Strictly speaking, you don't need to install anything special to use the git-flow workflow. You just need to know which workflows are made up of which individual tasks, with the correct parameters, and simply execute the corresponding Git commands in the correct order. Of course, it's more convenient if you use git-flow scripts, so you don't have to keep these commands and sequences in mind.

Install git-flow

In recent years, there have been many different installation methods. In this chapter, we will use one of the most popular: AVH Edition.

To learn the details of installing git-flow, read the following document, official documentation.

Set up git-flow in the project

When you want to "switch" your project to git-flow, Git can work as usual. It all depends on whether you use a special git-flow command or a normal Git command on the warehouse. In other words, git-flow doesn't change your warehouse in any dramatic way.

Having said that, git-flow has some limitations. Let's start initializing it on a new project, and then we'll find out:

$git flow initInitialized empty Git repository in / Users/tobi/acme-website/.git/Branch name for production releases: [master] Branch name for "next release" development: [develop] How to name your supporting branch prefixes?Feature branches? [feature/] Release branches? [release/] Hotfix branches? [hotfix/]

When you execute the "git flow init" command at the root of the project (it doesn't matter whether it already includes a Git repository or not), an interactive installation assistant will guide you through this initialization. It sounds a little cool, but in fact it just configures some naming rules on your branch.

Still, this installation assistant allows you to use your favorite name. I strongly recommend that you use the default naming mechanism and determine it step by step.

Branching pattern

The git-flow mode presupposes two main branches in the repository:

Master can only be used to include product codes. You can't work directly on this master branch, but in other designated, separate feature branches (which we'll talk about in a moment). Not submitting changes directly to the master branch is also a common rule for many workflows.

Develop is the basic branch of any new development you do. When you start a new functional branch, it will be the basis of _ development _. In addition, the branch brings together all the functions that have been completed and waits to be integrated into the master branch.

These two branches are called long-term branches. They will survive throughout the life cycle of the project. Other branches, such as those for functionality and for distribution, are only temporary. They are created as needed and are deleted when they have completed their tasks.

Let's start to explore some cases that may be encountered in real applications.

Function development

For a developer, the most common job is probably the development of functions. This is why git-flow defines a lot of workflows for functional development to help you accomplish it in an organized way.

Start new featur

Let's start developing a new feature, "rss-feed":

$git flow feature start rss-feedSwitched to a new branch 'feature/rss-feed'Summary of actions:- A new branch' feature/rss-feed' was created, based on 'develop'- You are now on branch' feature/rss-feed' concept

In the output text of these commands, git-flow prints a helpful overview of what has just been done.

When you need help, you can always ask for help. For example:

$git flow feature help

As with the new feature above, git-flow creates a branch called "feature/rss-feed" (the "feature/" prefix is a configurable option setting). You already know that using a separate branch when you do new feature development is one of the most important rules in version control.

Git-flow will also check out the new branch directly, so you can work directly.

Complete a function

After a period of hard work and a series of smart submissions, our new feature is finally complete:

$git flow feature finish rss-feedSwitched to branch 'develop'Updating 6bcf266..41748adFast-forward feed.xml | 0 1 file changed, 0 insertions (+), 0 deletions (-) create mode 100644 feed.xmlDeleted branch feature/rss-feed (was 41748ad).

Most importantly, this "feature finish" command integrates our work into the main "develop" branch. Here it needs to wait:

A comprehensive test in a broader "development" context.

It will be released later with all the other features accumulated in the "develop" branch.

After that, git-flow also performs a cleanup operation. It deletes the currently completed functional branch and changes it to the "develop" branch.

Manage releases

Release management is another very important topic in version control processing. Let's take a look at how to create and publish release using git-flow.

Create release

When you think that the code now in the "develop" branch is a mature version of release, it means: first, it includes all the new features and necessary fixes; second, it has been thoroughly tested. If both of the above are satisfied, it's time to start generating a new release:

$git flow release start 1.1.5Switched to a new branch 'release/1.1.5'

Note that the release branch is named with a version number. This is a wise choice, and there is a good side feature of this naming scheme, that is, when we have finished release, git-flow will mark those release submissions appropriately _ automatically _.

With a release branch, complete the final preparation for the release version number (if some files in the project need to record the version number), and make final edits.

Complete release

Now it's time to press the dangerous red button to complete our release:

Git flow release finish 1.1.5

This command completes the following series of operations:

First, git-flow pulls the remote repository to ensure that it is the latest version.

The content of the release will then be merged into the "master" and "develop" branches, so that not only the product code is the latest version, but the new functional branches will also be based on the latest code.

For easy identification and historical reference, release submissions are marked with the name of the release ("1.1.5" in our case).

Clean up operation, the version branch will be deleted and go back to "develop".

From Git's point of view, the release version is now complete. Depending on your settings, the submission of "master" may have triggered the deployment process you defined, or you can manually deploy your software product into the hands of your users.

Hotfix

Many times, just a few hours or days later, when you do a full test of the release version, you may find some minor errors.

In this case, git-flow provides a specific "hotfix" workflow (because it is inappropriate to use either "functional" branch process or "release" branch process here).

Create Hotfixes$ git flow hotfix start missing-link

This command creates a branch called "hotfix/missing-link". Because this is a fix to the product code, this hotfix branch is based on the "master" branch.

This is also the most obvious difference from the release branch, which is based on the "develop" branch. Because you should not fix the product code on a development branch that is not completely stable.

Just like release, fixing this bug will of course directly affect the version number of the project!

Complete Hotfixes

After submitting our fix to the hotfix branch, it's time to finish it:

$git flow hotfix finish missing-link

This process is very similar to releasing a version of release:

The completed changes are merged into the "master" as well as the "develop" branch, ensuring that the error does not occur again in the next release.

The hotfix program will be marked for easy reference.

The hotfix branch will be deleted and then switched to the "develop" branch.

Again, as in the process of generating release, you now need to compile and deploy your product (if these actions are not triggered automatically).

At this point, I believe you have a deeper understanding of "what is the work flow of git flow R & D". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.