The importance of

Let’s start with the importance.

Pay attention to cleanliness freaks in team development, who are constantly commenting on poor workflows and demanding ways to use Git. If these people are being ignored on your team, then your team must have mismanagement, poor code quality, and so on.

A uniform workflow is essential, regardless of the industry. For us developers, the workflow includes Git usage specifications at development time, Repo management specifications, testing process specifications, design interaction management specifications, and so on. Because more people are involved in the design of testing and interaction, this article will focus on Git usage specifications and REPO management specifications.

This article will describe the Work Flow that I have been using in my Work, and I hope it will be helpful to you.

Common Git usage specifications

To give you an example, here are some graphic screenshots of Network. In order for your project not to become like this, please treat Git with kindness:

Such a messy Git, you can bear it but I can not.

First, let’s talk about the problem of some kinds of pictures:

  1. Reverse pulldevelopbranch
  2. Do not pass throughPull RequestThe merger of
  3. Reuse branches that have been merged
  4. meaninglessCommit Message

For question 1, dare to ask the student, can we use rebase? Merge the contents of Develop into your current branch. For Rebase and Merge, refer to this article. To quote:

The feature branch introduces an external merge commit each time an upstream change is merged. If Develop is very active, this more or less pollutes your branch history. While the advanced Git log option alleviates this problem, it still makes it more difficult for developers to understand project history.

For question 2, it is completely a matter of habit. For all merges, if it is between two branches of your own, it is ok to Merge directly, but if it is a branch developed separately by two people, it is irresponsible to Merge directly. Pull Request or Merge Request can help you find Merge conflicts earlier and force you to review your code, which is crucial to ensuring code quality.

For problem 3, remove all branches that have been merged into Develop during the Pull Request merge to keep them in sync.

For question 4, the most common one, take a look at your project and see how many consecutive Commit messages are “bug fix”, “update”, “pod add”, “fix”, and so on with no obvious description. Dare I ask the students who write like this, is your project Owner full of WTF when he sees the Network? Commit messages should be short and succinct descriptions of what the Commit does.

Let’s look at another positive example of a very refreshing Network:

For my Work Flow, let’s start with a basic Git development Flow.

Git Flow

Git Flow, as it is known, defines a standard Git development Flow. Here are the classic articles.

The general meaning is:

  1. masterA long-term branch is used to manage releases. Each COMMIT is for a tag, which is a release
  2. developThe long term branch is generally used as a daily development summary, that is, development release code
  3. featureA short branch, usually used for the development of a new feature
  4. hotfixIt is a short-term branch. It is generally used to create a branch to fix bugs after the official release.
  5. releaseIs a short-term branch, typically used before the official release (that is, merging intomasterBefore branching), you need to have pre-released versions to test.releaseBranches will be merged after testing, test confirmation and acceptancedevelop 和 master

For details, see Git workflow.

Github Flow

Git is often coupled with continuous delivery platforms in development. Both Github and GitLab provide complete continuous delivery management functions. Combine these to create a Github Flow

Roughly meaning:

  1. masterBranch out without distinguishing between functional branches or patch branches.
  2. When a new branch is developed or needs to be discussed, askmasterTo launch aPull Request.
  3. Team members review and discuss your code together. You can also keep submitting code during the conversation.
  4. Pull RequestPass, merge intomaster, the original branch is deleted.

It can be seen that Github Flow is a simplified version of Git Flow, but with some cooperative joint control.

Git Work Flow

I usually want the development process on my team to be something like Git Flow, but in more detail, like this:

Git branch

master

Long branching, one tag per commit (one release)

develop

Long-term branch, daily development summary (development version of the code).

Develop a new feature and open a temporary branch of your develop feature, then Request the ‘Pull Request’ to develop.

release

Short-term branch, a branch that is pulled from develop after the feature has been developed, and is used during the test phase. The commit is usually a bug fix that is added to develop and master at the same time.

hotfix

Short branch, after the official release, bug fixes

2. Git operation

Commit specification

  1. commit messageBe brief and concise. Don’t write useless information. Don’t use phrases like “update” or “Bug Fix” that confuse others
  2. Add a new onePodThe library orpod updateAfter, submit a separate onecommitUnity,commit messageFor “POD Add XXX” or “POD Update”
  3. commitKeep them independent and do not modify the same file. For example, aPull RequestCommit1 changes a variable name in FileA, commit2 changes it back. The reason is:When reviewing code, reviewers usually review it one by onecommitLook, not lookChanges(You can just ignore things like pod UpdatecommitDon’t look at)

rebase

Don’t pull your code backwards, as you did in the first and second images at the beginning of this article — merge your Develop code into your branch when you see an update to Develop.

The reason is:

  1. mergeCauses all your branches to introduce a foreign merge commit. ifdevelopVery active, more or less contaminating your branches.
  2. Ugly, complex Network, increase the difficulty of understanding the history of the project.

How to resolve the current develop update situation?

Please use therebase!

Rebase. The previous picture helps you understand:

When rebase is in progress, you need to select a commit point and move the current branch from the root to the specified commit point, literally rebase.

This way you can get a good looking Network and control conflicts in time. However, in multiplayer development, you need to keep an eye on Develop and rebase in a timely manner, so you don’t have to wait a long time for your code to rebase to the latest date and find a lot of conflicts. Of course, projects that are well controlled and allocated are rarely conflicted themselves.

Iii. GitLab management specifications

issue

Those who play Github regularly know that issue can do many things, such as opinion management, Bug management and task management. It can only do one function, or use all functions at the same time through different labels.

In my Work Flow, issue is used for task management, because issue can be conveniently assigned and timely receive email notification.

At the beginning of each iteration of a new version, when PRD passes the review, the task will be divided into the smallest units after negotiation within the group. The Owner will establish issues respectively, and everyone can get them by themselves.

Also create an issue if there are areas that need to be improved during development.

As for labels, I usually classify them into optimizing, bug fix and Feature

When a task is completed, a Pull Request is usually sent. If all the tasks in the Pull Request are completed, the Title of the Pull Request should be similar to the following format:

“Close #13 Home scroll bar switching effect improved”

Both GitLab and Github recognize close #{issue ID}. If you write this in the Title, the issue will be automatically closed when the Pull Request is approved.

Milestones

Renamed as a milestone, the issue can be selected as renamed when establishing renamed; if renamed is reasonably used, a clear project schedule can be obtained on the Renamed page.

Pull Request

All merges require Pull Request, including merging your own branch into your own branch, which can better help you develop the good habit of Code Review.

The title of the Pull Request should briefly describe what the merge is doing. More details should be itemized in Description. Links to relevant documents should also be listed.

Take care to select the appropriate Milestone and Labels. An Assignee is selected for review. If the contents of the Pull Request are deemed to be excessive or there are areas requiring common Discussion, all participants will receive the email in time in the Discussion area @ others after the submission of the Pull Request.

Code Review

Code Review is a point worth mentioning. Most of the time, people think that Code Review is to understand other people’s Code, and then analyze and Review. In fact, Code Review is more of a transfer of experience within the team.

For example, a code specification, even if a team has detailed documentation, is not always written down. For newcomers, after completing the feature, Pull Request will be submitted to others for Code Review. The Code specifications will be reviewed by others, and non-compliance requirements will be corrected for four or five times. Basically, there will be no problems.

This is also my personal experience. One of my former leaders is very experienced in Work Flow management. At the beginning, I proposed several Pull requests and soon became familiar with the code specifications in the team.

Therefore, the content that Code Review reviewers should check is not mandatory, but it should at least include:

  1. Code specification
  2. Basic syntax and logic errors
  3. Some experience with business logic
  4. .

When errors are found, comments should be added in a timely manner.

After all the reviewers have completed the review and added all the comments, the submitter shall be notified in the Discussion area @ review done.

Similarly, after the submitter finishes the modification in accordance with the comment, the submitter should also finish the modification in the Discussion area @ relevant reviewers, please review it again.

Ammend should be appended to the last commit after the local modification is complete.

However, this is just the way I’ve always done it, again following the principle of “remain independent between commits” if committing a new commit results in two commits modifying the same file.

Of course, some people think that the new commit will make it clearer to see the new changes of the committer, and it will be more consistent with Github Flow. There’s no compulsion here, you can do whatever you like.

conclusion

Finally, I hope everyone can harvest a refreshing Network like the wind.

What question can leave a message in the back of the blog post, or micro blog on the private letter I, or mail me [email protected].

The blogger is an iOS girl.

I hope we can make progress together.

My micro blog: Xiaoyu Zhou Lingyu

Please correct any intellectual property rights, copyright issues or theoretical errors.

Please indicate the original author and above information.