From 5693f62f890b8cd3af5087e8e50d24931e9c6646 Mon Sep 17 00:00:00 2001 From: Daniel Donovan Date: Tue, 1 Aug 2023 08:43:23 -0700 Subject: [PATCH] replace master with main --- index.html | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/index.html b/index.html index a8431f4..2dfaede 100644 --- a/index.html +++ b/index.html @@ -32,7 +32,7 @@

I travel all over the place teaching Git to people and nearly every class and workshop I've done recently has asked me what I think about git-flow. I always answer that I think that it's great - it has taken a system (Git) that has a million possible workflows and documented a well tested, flexible workflow that works for lots of developers in a fairly straightforward manner. It has become something of a standard so that developers can move between projects or companies and be familiar with this standardized workflow.

-

However, it does have its issues. I have heard a number of opinions from people along the lines of not liking that new feature branches are started off of develop rather than master, or the way it handles hotfixes, but those are fairly minor.

+

However, it does have its issues. I have heard a number of opinions from people along the lines of not liking that new feature branches are started off of develop rather than main, or the way it handles hotfixes, but those are fairly minor.

One of the bigger issues for me is that it's more complicated than I think most developers and development teams actually require. It's complicated enough that a big helper script was developed to help enforce the flow. Though this is cool, the issue is that it cannot be enforced in a Git GUI, only on the command line, so the only people who have to learn the complex workflow really well, because they have to do all the steps manually, are the same people who aren't comfortable with the system enough to use it from the command line. This can be a huge problem.

@@ -55,30 +55,30 @@

So, what is GitHub Flow?

That is the entire flow. It is very simple, very effective and works for fairly large teams - GitHub is 35 employees now, maybe 15-20 of whom work on the same project (github.com) at the same time. I think that most development teams - groups that work on the same logical code at the same time which could produce conflicts - are around this size or smaller. Especially those that are progressive enough to be doing rapid and consistent deployments.

So, let's look at each of these steps in turn.

-#1 - anything in the master branch is deployable

+#1 - anything in the main branch is deployable -

This is basically the only hard rule of the system. There is only one branch that has any specific and consistent meaning and we named it master. To us, this means that it has been deployed or at the worst will be deployed within hours. It's incredibly rare that this gets rewound (the branch is moved back to an older commit to revert work) - if there is an issue, commits will be reverted or new commits will be introduced that fixes the issue, but the branch itself is almost never rolled back.

+

This is basically the only hard rule of the system. There is only one branch that has any specific and consistent meaning and we named it main. To us, this means that it has been deployed or at the worst will be deployed within hours. It's incredibly rare that this gets rewound (the branch is moved back to an older commit to revert work) - if there is an issue, commits will be reverted or new commits will be introduced that fixes the issue, but the branch itself is almost never rolled back.

-

The master branch is stable and it is always, always safe to deploy from it or create new branches off of it. If you push something to master that is not tested or breaks the build, you break the social contract of the development team and you normally feel pretty bad about it. Every branch we push has tests run on it and reported into the chat room, so if you haven't run them locally, you can simply push to a topic branch (even a branch with a single commit) on the server and wait for Jenkins to tell you if it passes everything.

+

The main branch is stable and it is always, always safe to deploy from it or create new branches off of it. If you push something to main that is not tested or breaks the build, you break the social contract of the development team and you normally feel pretty bad about it. Every branch we push has tests run on it and reported into the chat room, so if you haven't run them locally, you can simply push to a topic branch (even a branch with a single commit) on the server and wait for Jenkins to tell you if it passes everything.

You could have a deployed branch that is updated only when you deploy, but we don't do that. We simply expose the currently deployed SHA through the webapp itself and curl it if we need a comparison made.

-#2 - create descriptive branches off of master

+#2 - create descriptive branches off of main -

When you want to start work on anything, you create a descriptively named branch off of the stable master branch. Some examples in the GitHub codebase right now would be user-content-cache-key, submodules-init-task or redis2-transition. This has several advantages - one is that when you fetch, you can see the topics that everyone else has been working on. Another is that if you abandon a branch for a while and go back to it later, it's fairly easy to remember what it was.

+

When you want to start work on anything, you create a descriptively named branch off of the stable main branch. Some examples in the GitHub codebase right now would be user-content-cache-key, submodules-init-task or redis2-transition. This has several advantages - one is that when you fetch, you can see the topics that everyone else has been working on. Another is that if you abandon a branch for a while and go back to it later, it's fairly easy to remember what it was.

This is nice because when we go to the GitHub branch list page we can easily see what branches have been worked on recently and roughly how much work they have on them.

@@ -91,7 +91,7 @@

#3 - push to named branches constantly

-

Another big difference from git-flow is that we push to named branches on the server constantly. Since the only thing we really have to worry about is master from a deployment standpoint, pushing to the server doesn't mess anyone up or confuse things - everything that is not master is simply something being worked on.

+

Another big difference from git-flow is that we push to named branches on the server constantly. Since the only thing we really have to worry about is main from a deployment standpoint, pushing to the server doesn't mess anyone up or confuse things - everything that is not main is simply something being worked on.

It also make sure that our work is always backed up in case of laptop loss or hard drive failure. More importantly, it puts everyone in constant communication. A simple 'git fetch' will basically give you a TODO list of what every is currently working on.

@@ -107,7 +107,7 @@

* [new branch] fi-signup -> origin/fi-signup 2647a42..4d6d2c2 git-http-server -> origin/git-http-server * [new branch] knyle-style-commits -> origin/knyle-style-commits - 157d2b0..d33e00d master -> origin/master + 157d2b0..d33e00d main -> origin/main * [new branch] menu-behavior-act-i -> origin/menu-behavior-act-i ea1c5e2..dfd315a no-inline-js-config -> origin/no-inline-js-config * [new branch] svg-tests -> origin/svg-tests @@ -130,32 +130,32 @@

more discussion

-

Finally you can see that we're still in the trial phase - this is not a deployment ready branch yet, we use the Pull Requests to review the code long before we actually want to merge it into master for deployment.

+

Finally you can see that we're still in the trial phase - this is not a deployment ready branch yet, we use the Pull Requests to review the code long before we actually want to merge it into main for deployment.

If you are stuck in the progress of your feature or branch and need help or advice, or if you are a developer and need a designer to review your work (or vice versa), or even if you have little or no code but some screenshot comps or general ideas, you open a pull request. You can cc people in the GitHub system by adding in a @username, so if you want the review or feedback of specific people, you simply cc them in the PR message (as you saw Josh do above).

This is cool because the Pull Request feature let's you comment on individual lines in the unified diff, on single commits or on the pull request itself and pulls everything inline to a single conversation view. It also let you continue to push to the branch, so if someone comments that you forgot to do something or there is a bug in the code, you can fix it and push to the branch, GitHub will show the new commits in the conversation view and you can keep iterating on a branch like that.

-

If the branch has been open for too long and you feel it's getting out of sync with the master branch, you can merge master into your topic branch and keep going. You can easily see in the pull request discussion or commit list when the branch was last brought up to date with the 'master'.

+

If the branch has been open for too long and you feel it's getting out of sync with the main branch, you can merge main into your topic branch and keep going. You can easily see in the pull request discussion or commit list when the branch was last brought up to date with the 'main'.

-

master merge

+

main merge

When everything is really and truly done on the branch and you feel it's ready to deploy, you can move on to the next step.

#5 - merge only after pull request review

-

We don't simply do work directly on master or work on a topic branch and merge it in when we think it's done - we try to get signoff from someone else in the company. This is generally a +1 or emoji or ":shipit:" comment, but we try to get someone else to look at it.

+

We don't simply do work directly on main or work on a topic branch and merge it in when we think it's done - we try to get signoff from someone else in the company. This is generally a +1 or emoji or ":shipit:" comment, but we try to get someone else to look at it.

shipit comment

-

Once we get that, and the branch passes CI, we can merge it into master for deployment, which will automatically close the Pull Request when we push it.

+

Once we get that, and the branch passes CI, we can merge it into main for deployment, which will automatically close the Pull Request when we push it.

#6 - deploy immediately after review

-

Finally, your work is done and merged into the master branch. This means that even if you don't deploy it now, people will base new work off of it and the next deploy, which will likely happen in a few hours, will push it out. So since you really don't want someone else to push something that you wrote that breaks things, people tend to make sure that it really is stable when it's merged and people also tend to push their own changes.

+

Finally, your work is done and merged into the main branch. This means that even if you don't deploy it now, people will base new work off of it and the next deploy, which will likely happen in a few hours, will push it out. So since you really don't want someone else to push something that you wrote that breaks things, people tend to make sure that it really is stable when it's merged and people also tend to push their own changes.

Our campfire bot, hubot, can do deployments for any of the employees, so a simple: