This article is inspired by a thread on Chris Wanstrath (GitHub Co-Founder) Twitter .
Because of the emergence of GitHub Pull Request, the concept of R&D collaboration has been carried forward globally. The abbreviation of PR is no longer exclusive to Public Relation. Next, let us review the brief history of GitHub PR development.
History of Pull Requests
Pull Requests make it easier for developers to collaborate, share, and review code changes. Developers submit their own code changes to a project and request the project's maintainers to review and merge these changes, and maintainers can provide feedback and suggestions to ensure code quality and project consistency. Once the Pull Request is accepted by the maintainer, the changes are merged into the master branch. The idea behind GitHub is to provide a web-based alternative to git's email-based workflow. Pull Request is based on git's request-pull subcommand . When the GitHub beta version was released, there was no pull request function, but because it is a social network, there is a private message function. So when I wanted to raise PR at that time, I just sent a private message to others: Please pull my fork on this branch. There's a pull request button shortly after, though .
Code Review Code Review
Before Pull Requests 2.0, GitHub actually had code reviews to some extent . In 2008, there was already a "submit a comment" function. You can comment on any commit or a line of code, and the comments will be marked by bubbles .
Although the function is still very basic, there is no state, and it is not optimized for branch-based workflows, but it is much more advanced than "reply all" (imagine how messy it will become when there are more threads).
Pull Request 2.0
After two years and 200,000 PRs, PR gradually evolved from a private message form to a form more similar to its current " collaborative code review ". PR has become a series of discussions about the code you want to merge, and the code changes are compared with the view. It is GitHub's interpretation of code review and represents GitHub's vision for collaborative development.
The Merge Button
Pull Request 2.0 has taken a big step forward, code review and accepting patches (the Fork Queue at that time could already be cherry-picked, although the concept is not exactly the same as now), it is more convenient, but there is still something missing. In 2011, PR had a next qualitative leap: the merge button . To merge a PR, you no longer need to enter several commands through the git command line. Just click the merge button to automatically merge and close the PR.
Merge Queue Merge Queue
As the size of the development team and system continues to expand, there may be more concurrent changes. GitHub announced the "merge queue" Pull request merge queue a month ago , by updating the PR before merging to avoid merging without the basis of the latest version Branch tested code without breaking CD.
extra
Thoughts on the product
It is hard to imagine that when GitHub was launched, there was no Pull Request function. The complete PR workflow was gradually improved after a few years. It took the team many years to create the user experience that is now taken for granted. However, their idea of a "web-based git workflow" has been around since the beginning.
There are a lot of thinking about products, and we are now (and in the future) also deliberating & improving on "database CI/CD flow", how to provide the best user experience.
Team work makes the dream work
Chris mentioned that "I believe that the best software is done through collaboration, and PR is a good example." We fully agree that the original intention of Bytebase is to promote better collaboration among DevOps teams, and we will also design products Consider how to achieve this more conveniently, safely, and efficiently.
Proper Cleanup Function
The two functions of Fork Queue and private message mentioned above are gone now, but they existed (as long as you will talk nonsense), and they were optimized in 2012. Merge buttons are a good replacement for forked queues, and with so many direct messaging tools out there, who needs an extra inbox?
The Importance of Schema Design
In addition, the functions of the product come and go, but the issues involving the information structure Schema may really need to be clearly thought out from the beginning. For example, 13 years ago, the organizational model defined in this PR is still in use today.
About why GitHub uses MySQL
Chris mentioned a small episode: almost migrated GitHub from MySQL to Postgres in the early days, and even created a branch, but some bad SQL queries he wrote for the private message function did not work in Postgres, so MySQL stayed up.
Finally, let’s summarize the growth history of PR:
When it was first launched in 2008, PR was actually a private message, but it soon became an independent button, and soon users can also comment on the submitted code;
After PR 2.0, it gradually evolved into a complete process (closer to what it is now), including discussion of the code and comparison of before and after
After that, the merge button was added, and this year, there is a merge queue.
What's next?
Another: Being good at SQL and not being good at SQL are not actually mutually exclusive.