From 17e499e11f9724f05c9f2ac0d2ba39a5e4295fe1 Mon Sep 17 00:00:00 2001 From: babolivier Date: Thu, 22 Jul 2021 10:58:46 +0000 Subject: deploy: d518b05a8667943bd0aa9ab1edc91eec0a8283fe --- develop/print.html | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) (limited to 'develop/print.html') diff --git a/develop/print.html b/develop/print.html index 4a623018e3..b22fbe8d97 100644 --- a/develop/print.html +++ b/develop/print.html @@ -101,7 +101,7 @@ @@ -11298,7 +11298,7 @@ flag to git commit, which uses the name and email set in your

By now, you know the drill!

Notes for maintainers on merging PRs etc

There are some notes for those with commit access to the project on how we -manage git here.

+manage git here.

Conclusion

That's it! Matrix is a very open and collaborative project as you might expect given our obsession with open communication. If we're going to successfully @@ -11489,7 +11489,7 @@ is left as an exercise for the reader!

In an ideal world, our git commit history would be a linear progression of commits each of which contains a single change building on what came before. Here, by way of an arbitrary example, is the top of git log --graph b2dba0607:

-clean git graph +clean git graph

Note how the commit comment explains clearly what is changing and why. Also note the absence of merge commits, as well as the absence of commits called things like (to pick a few culprits): @@ -11537,10 +11537,10 @@ towards.

Ok, so that's what we'd like to achieve. How do we achieve it?

The TL;DR is: when you come to merge a pull request, you probably want to “squash and merge”:

-

squash and merge.

+

squash and merge.

(This applies whether you are merging your own PR, or that of another contributor.)

-

“Squash and merge”1 takes all of the changes in the +

“Squash and merge”1 takes all of the changes in the PR, and bundles them into a single commit. GitHub gives you the opportunity to edit the commit message before you confirm, and normally you should do so, because the default will be useless (again: * woops typo is not a useful @@ -11571,10 +11571,10 @@ lot). I tend to think the whole thing is overblown. Fundamentally, it's not that complicated. Here's how we do it.

Let's start with a picture:

-

branching model

+

branching model

It looks complicated, but it's really not. There's one basic rule: anyone is free to merge from any more-stable branch to any less-stable branch at -any time2. (The principle behind this is that if a +any time2. (The principle behind this is that if a change is good enough for the more-stable branch, then it's also good enough go put in a less-stable branch.)

Meanwhile, merging (or squashing, as per the above) from a less-stable to a @@ -11586,7 +11586,7 @@ that our active branches are ordered thus, from more-stable to less-stable: