[Zz] How GitHub works: asynchronous work

How GitHub works: asynchronous work

Introduction: Zach Holman, A GitHub employee, wrote an article about how GitHub operates and managesArticleThe article consists of three parts:Asynchronous Operation. (The full text below)

This is my favorite aspect of GitHub so far: Everything is asynchronous.

Chat

Gihtub had no office in the first two years. We use a chat room (campfire) for communication. Now we have moved to the second office, but still use campfire. This is because the chat Can be non-synchronous.

With this asynchronous communication method, I can go out for dinner, and then I can keep up with conversations when I come back. I can ask my colleagues a question without worrying about disturbing her, because when she has time, she will naturally reply; I can go to the Minnesota country, or work in the office as usual.

Pull requests

(Note: "pull requests" is a form of discussion on GitHub.CodeDiscuss, review, and manage code changes.Pull requests = code + question + code comment.)

Our development workflow involves pull requests. I want to describe this process in more detail in my blog later. Now I just want to express my love for this method. In the past, the days of complex branch operations were gone forever. Instead, you only need to look at the code on the screen in a concise way.

If I want to add a new feature or modify the code, I will push the code to a new branch and create a new pull requests. If my code affects my colleagues' code, or they are interested in my code, or they have plenty of time, they can check my code. In this case, we can deploy the branch to another machine to debug the new function. If everything is normal, we can merge the branch to the main branch.

With the working method of pull requests, I don't need to have a special meeting to help everyone. There is another reason:

Meeting is harmful

37signals discussed the topic "meeting is harmful" in getting real. Compared with signals 37, I hate meetings.

When you are busy, you may have a meeting. They often invite irrelevant persons for meetings. Even if you are very interested in the theme of the meeting, you will eventually get upset. Because of the meeting, you have to stop the work at hand, but the meeting is "talking" about your work. The meeting expected you to design the perfect system on the White Paper in advance, while obviously pushing a branch and viewing diff, it is easier to modify the code based on diff.

In addition, the contents of the meeting are easily forgotten. Even if you make a meeting record, you cannot guarantee that you can record everything. Some of you may not have time to write down the records. You may want to record the records after the meeting. But three weeks have passed, and you recall that something has not been recorded. Obviously, that discussion is more important. This problem does not exist if you use the chat record method. In addition, the text communication method also reduces the opening gap during the meeting.

We will have a meeting on GitHub, but there are only a few sessions in the past year and a half.

Best status

ReturnMy previous article: You want your employees to be "best ". But if they can only work in that State for an hour, they will have a meeting, which will disrupt them.

We have found that if responsible people are assigned their jobs at their own time, they can not only complete important jobs, but also ensure the efficiency of other jobs.

 

How GitHub works: be asynchronous