RDC best practice development mode - git flow

Click to read the original text

Abstract:  When I created a new project today, I found that in addition to the original `branch mode`, `rdc` also added `master branch development mode` and `git flow mode`, which is a very gratifying thing - after all `git flow` is a long-standing and generally accepted development model.

Introduction

When I built a new project today, I found that rdcin addition to the original one 分支模式, I also added master分支开发模式and git flow模式, this is a very gratifying thing - after all, it is git flowa development model that has been around for a long time and is generally accepted by everyone.
So I deleted the app and switched to git flowmode, and the experience is perfect so far.
Since many people may not know much about git flowit, this article will share some minor experiences.

foreword

Do you use git?

I believe most of you here will confidently answer: "Yes".
In fact, everyone may never consider whether their usage is really scientific and really robust, especially when the project is getting bigger and bigger, the number of people is increasing, and the cycle is getting longer and longer.

Among them, the typical problems are as follows:

1. When I was in the middle of developing a feature, PM suddenly assigned me a new urgent task. How can I start this task without affecting the current one?
2. When my code is written, how do I publish it?
3. When I posted, the code went wrong, how can I fix it quickly?
4. In the above situation, it is also required to include all the code developed later after the repair?

When most developers use git, they basically only use two or even one branch, so the following concepts obviously open the door to a new world.

plan

Obviously, not only code has code specifications, but also code management and coordination requires a clear process and specifications. Therefore, the general solution in the industry is Git Flow.

How about it, dazzling, but I can give you a suggestion: turn your head 90 degrees to the left, don't be in a hurry to scold... This is office picture, not drawn by me.

In the above picture, the top row represents branches, which are

|名称|解释
|-|-
|master|这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
|Develop|这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
|Feature|这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release
|Release|当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支
|Hotfix|当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release.

实现细则

master分支

在master分枝上工作，我们需要遵循一个基本原则，所有在master分支上的commit应该tag.

feature分支

feature分支做完后，必须合并回develop分支, 合并完分支后一般会删点这个feature分支，但是我们也可以保留

开始一个新的功能的开发

git checkout -b some-feature develop
# Optionally, push branch to origin:
git push -u origin some-feature    

# 做一些改动    
git status
git add some-file
git commit    

开发完成

git pull origin develop
git checkout develop
git merge --no-ff some-feature
git push origin develop

git branch -d some-feature

# If you pushed branch to origin:
git push origin --delete some-feature    

release分支

The branch name release/* branch is created
releasebased on the branch. After the branch is completed, we can test, modify , etc. on this branch. At the same time, other developers can develop new ones based on it. Once branched, do not merge into and from the release branch, and at the same time mark the branch to remember the version number, and then delete the branch (of course, you can choose not to delete it). ).developreleasereleasebugfeaturereleasedevelop分支上合并新的改动到Release分支
releasereleasemasterdevelopmastertagreleaserelease

start release

git checkout -b release-0.1.0 develop

# Optional: Bump version number, commit
# Prepare release, commit

complete release

git checkout master
git merge --no-ff release-0.1.0
git push

git checkout develop
git merge --no-ff release-0.1.0
git push

git branch -d release-0.1.0

# If you pushed branch to origin:
git push origin --delete release-0.1.0   


git tag -a v0.1.0 master
git push --tags

hotfix

The branch name hotfix/* The branch is created
hotfixbased on the branch. After the development is completed, it needs to be merged back to the branch, and amastermasterdevelopmastertag

start hotfix

git checkout -b hotfix-0.1.1 master    

complete hotfix

git checkout master
git merge --no-ff hotfix-0.1.1
git push


git checkout develop
git merge --no-ff hotfix-0.1.1
git push

git branch -d hotfix-0.1.1

git tag -a v0.1.1 master
git push --tags

tool

If you can insist on seeing this, I am really happy for you, which shows that you have studied hard and are not afraid of dangers. After all, the long list of codes above may have made you feel intimidated.
And obviously, as a general solution, it can't be so cumbersome, then, the only possibility is - there is! work! Tool!

platform command

OS X	brew install git-flow
Linux	apt-get install git-flow
Windows	wget -q -O - --no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh
IDEA	Git Flow Integration

其中还有一大部分是gui的，比较简单，本文就不再赘述了。下面着重介绍下命令行下的使用

• 初始化: git flow init
• 开始新Feature: git flow feature start MYFEATURE
• Publish一个Feature(也就是push到远程): git flow feature publish MYFEATURE
• 获取Publish的Feature: git flow feature pull origin MYFEATURE
• 完成一个Feature: git flow feature finish MYFEATURE
• 开始一个Release: git flow release start RELEASE [BASE]
• Publish一个Release: git flow release publish RELEASE
• 发布Release: git flow release finish RELEASE 别忘了git push --tags
• 开始一个Hotfix: git flow hotfix start VERSION [BASENAME]
• 发布一个Hotfix git flow hotfix finish VERSION

仔细观察，这些命令都是有规矩的，它们大概可以如下图表示

阅读原文请点击