Autumn comes later in Shenzhen than in most parts of the country. In the struggle between hot and cold, the weather gradually turned cool. It was a weekend. It was cool in the evening. Xiao Liu, Xiao Li, Xiao Gao and Xiao Chen made an appointment to masturbate together. They are college classmates, majored in computer science, after graduation, they all moved to Shenzhen, now make a living by writing programs, joined the army of programmers.

Programmers dinner program is fixed, a few bites of big kidney, plus a few glasses of beer, several people happen to be the same start all kinds of ridicule, from scolding boss, scolding boss, scolding product, scolding design, scolding to the end, we all understand. The so-called programmer chat begins with a rant about the boss and ends with a rant about the programming language.

But today they have a new topic, code managed workflows.

Liu was the first to speak, git this cargo with SVN what, I always did as usual, written submission, we three to five personal small team, so in addition to the local is not even on the server can submit code this, too, with SVN nothing difference, we have only one main branch is the same with the SVN trunk, Everyone is working on it, teamwork and communication is very efficient.

Centralized Workflow



This process is all about speed and simplicity, which is best for most individual developers and small teams, often maintaining an App, a personal blog, or a small website. The applicable scenes and basic characteristics are summarized as follows: 1

  1. Small team size
  2. Development is not very frequent
  3. Team communication is convenient
  4. No need to maintain multiple versions at the same time

Let’s get back to our story. Chen could not listen any longer, and said: Our team implemented the use of a Git plug-in called Git-flow. All members cooperated according to the standard flow stipulated by the software. For each change, we used the git-flow tool to create the corresponding flow according to different situations. We all follow this process, although cumbersome, but we more than 30 development teams jointly maintain several projects, and they always run smoothly and never have any accidents. You guys are the only ones who are constantly messing up the code base by novices. How dare you call team coordination, communication and efficiency? I think it’s funny, haha.

Liu qi’s face is red, have no what words to say again, have to endure.

Git-flow Workflow



Based on Git branch tags and other concepts, git-flow workflow adds some concepts such as Feature, Release and Hotfix to accurately describe some process of code version control. All collaborators give up some personal efficiency. Unified development process, ultimately brings the overall scale of the overall efficiency of the team. Its disadvantage is that it is difficult to get started and requires some basic knowledge training. The application scenarios are as follows:

  1. Don’t think extra learning about Git-flow is a problem
  2. There are dedicated code warehouse managers
  3. The development team is relatively fixed and has a certain size
  4. There are often parallel development requirements
  5. The team has a unified definition standard for the concepts of Release, Bug and Feature

Let’s get back to our story. Then Xiao Li calmly took out a string of mutton, ate a mouthful, said: I don’t know what you’re talking about, but as a freelancer, I maintain an open source software and contribute some code to open source software. I always fork on Github and submit a Pull Request, which is reviewed by the maintainer of open source software. If the review passes, it is merged into the source project. As a maintainer of open source software, I review what others contribute to me and contribute to others’ reviews, which is an ideal ecosystem. I don’t know what you’re doing with all that crap.

Fork Workflow

 

This process is a set of processes specially designed for open source software. The original inventor is Github, the world-renowned open source software repository. The biggest feature of this process is that the development participants can not directly participate in the project, want to contribute code, just fork the target project, can get a exactly the same own project, after modification, submit the Pull Request to the original project, if the original project maintainer adopted, the contribution is completed. As you can see from the diagram, each developer (team) has a project they maintain, and links with each other’s projects are handled through Pull requests. The applicable scenarios are summarized as follows:

  1. Often used in open source software
  2. Developers need to spawn their own versions
  3. The developer is not fixed, may be any net friend

Let’s get back to our story. Xiao Gao is a fat man, every time masturbation string can eat, basically chatting time is occasionally inserted a word. Our company, different from yours, uses a simplified model based on Git-Flow to work cooperatively, without installing any Git plug-ins. The repository has a default branch called master, and when we need a release, we label the default branch as release. Using the branch protection function provided by Coding, master can specify several administrators, others can open a branch based on the default branch master, submit code, and then submit a merge request to master on Coding, and can designate several team members as reviewers. After passing the review, it can be merged into master. It never runs smoothly. It never goes wrong.

Feature Branch Workflow

 

This Flow is a simplified version of Git-flow, which does not need to install additional Git plug-ins. It is realized based on some basic functions provided by the code hosting platform. The main Flow is divided into Feature Flow and Bug Flow. This process is suitable for most teams with more than 5 people, a lot of parallel development needs, frequent updates and heavy development tasks. The applicable scenarios are:

  1. The development team is relatively fixed and has a certain size
  2. Often, multiple functions, multiple problems are developed in parallel
  3. High requirements for code review
  4. Focus more on team efficiency

Xiao liu, then just slow lead to god from the words of xiao Chen, said to xiao Chen, though we are messing up the code base had a novice, but git are history, is not irreversible, it is critical that our process is simple, never have any problems is a quick response, unlike some companies, fix a bug, have to wait a week to live.

What’s the fuss? It’s all just fork/pull request.

You a, I a, all sorts of tongues, noisy. .

The arguments of these four became more and more intense, and there was no way. The arguments of programmers were all face-breaking and red-faced until the barbecue shop was about to close. Finally alerted the wife of the grill owner. The landlady listened to the argument, smiled and said: young people don’t be excited, although I don’t know what to say, but everything in this world, there is a range of application, nothing is absolutely good, nothing is absolutely bad. It’s like when you have chillies on a barbecue, and you put them on a barbecue, and they taste really good, but have you ever seen a cold drink place with chillies?

A few people listen to, instantaneous feel sanitary aunt is like jin Yong novel sweeping the floor monk that kind of magic, fine think fear extremely, hurriedly knot account, hurriedly left.

============ this is the dividing line ============

Yeah, nothing is absolutely good and nothing is absolutely bad. Everything has its limits.

Above, the applicable scenario is not fixed, is flexible, even we can go beyond the above four models, take its essence, discard its dross, create a new model. Anyway, hopefully this article has helped you find git workflows that fit your model.