GitHub 30 Minutes to Merge, 28 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: How to play nice with others: Collaboration and communication in GitHub #30MinutesToMerge

Description

5:12 - Program start
8:23 - Demo start
9:24 - Projects and clear communications
12:08 - Branching effectively
15:02 - Commit messages
16:25 - the Pull Request
17:28 - What's a Code owner and why should we have them?
23:16 - Drafting a release
#30minutestomerge
Drive collaboration and clarity with projects in GitHub, and maintain open lines of communication. In just a few purposeful moves, Jon Cardona shows you how to reduce commit errors, get the whole team on the same page, and keep your team moving more efficiently together.

https://github.community/t/30-minutes-to-merge-advanced-branching-strategy/168069

A

A

B

What is going on welcome to another episode of 30 minutes to merge, my name is matt desmond. I go by beard of edu at github uh today I am introducing my buddy slash colleague, john cardona, aka hollywood. uh Just a quick intro for uh john uh he's got a couple of hobbies. He's got a couple more than our last host, uh so he enjoys building legos with his three kids uh hockey surfing and making music. He currently doesn't have any animals. He finds that having three kids is enough of a time suck.

B

um His recent purchase was uh a go-kart for his kids as he put it, so he has fun uh letting his kids watch him put on his golf cart um and then maybe every once, while lets them have a turn.

B

uh When it comes to open source contributions, he doesn't contribute as much as he'd like, but he does have a open source repository that I'll be sharing in a moment that enables you to order pizza from domino's using a github action, which I find very cool and very filling, and then his ideal github action would be one that modifies his uh network to block his kids devices during things. Like homework dinner and bedtime with that, I'm super excited to be introducing john uh for the today's session.

C

B

Yeah, what's happening.

C

Not much I appreciate it. This is a very special 30 minutes to merge simply because it's kind of my first one, so it may only be special to me, but thanks for the invite I know today we're going to be talking about collaborating collaboration as a whole. You know it's really easy to work within the confines of a repository when it's only you, however, when you start introducing multiple people, that's when things can get a little sticky and a little hairy.

C

If you will, if you don't have the proper discipline or the proper processes in place, uh your branching strategies, communication can get out of hand and communication can just fail to exist. To be quite honest, you know I it makes me think of a situation I was in when I was an engineer.

C

I was working on a feature finished it everything committed it. The same exact day. Another engineer committed the same exact feature that I had just finished and you know I chalked that all up to just lack of communication on my part, their par everybody's part right.

C

So with that being said, let's, uh let's hop into this wonderful calculator. Repo we've got going on here. Thank you to my buddy matt.

A

C

C

C

Calculator js node, okay, that took a second, so simple, repository, uh javascript html, you know the end goal here is we're going to show releases we're going to show a calculator being deployed to azure we're going to show multiple deployments, based on particular branches that you're on and just kind of the overall construct of how to collaborate with folks internally, I think there are like really three huge conceptual places where collaboration and transparency can happen within a repository, and you know the first of those being issues, but before I really jump into issues, I kind of want to show you the the father figure of repos and issues.

C

If you will, when discussing things at a high level, and that's that's projects within our repository, we have a project for release. 1.1 good thing about projects is, they can show issues and pull requests the to do. We have a few things to be reviewed. We have two things that you know probably should have been caught, but for whatever reason, weren't and.

C

Let me open this issue to show you some nifty functionality, because what these allow you to do is just kind of open that channel of communication between you know myself. Other engineers, if I come through here and decide that I want to add hover text to calculator buttons like beard just did, I could easily say you know not worth the effort. We have different priorities. We have competing priorities so on and so forth. However, it's a simple enough task to perform. We could easily do so and then assign it to a release.

C

Same goes with pull request, pull requests are the end game right. The end goal of what we're trying to achieve.

C

We go back to the project.

C

Adding hover text.

C

A pull request, adding titles for each calculator button. This is what we're going to get to at the end. So all of these things combined really kind of create that level of transparency that a team really needs, whether it's with an open source intersourcing, you know, or even a private repository within a single development team.

C

There's really no excuses to why engineers should not be talking to each other and or.

C

Having you know these types of conversations as the workflow goes on- and I was just I just realized that perhaps 4k monitors do not scale well here. So hopefully this is a bit better. um Okay, so, let's jump into it, we have a new bug opened. This was discovered by my coworker matt the background. Color isn't loading.

C

I can do one of two things I can work off of two separate different conceptual get workflows at github.

C

We have what we call the github flow, which is where we branch out off of main every time you know, regardless as to whether or not it's a release, branch dev branch, hot fix, doesn't matter branch off of maine, contrary there's also the git flow, where you have the idea of release branches, dev branches, you know main hotfixes, whatever you'd like we're, gonna go with the git flow here, just because I I do feel like that's more prevalent, but you know it also gives me a good chance to demonstrate you know deploying to different environments so to speak.

C

One thing to take note of is if your repository by default has main listed as the default branch and you're working off of the git flow. You might want to go into your settings.

C

And quickly change that to dev oops don't want to rename sorry.

C

C

Default branch is already dev awesome, it wasn't, but so this stops a lot of accidents from happening specifically accidents that I myself have kind of uh partaken in which was branching off of the wrong branch and then realizing it far too late. So going back to the issue at hand, you know we found a bug. We want to fix the background color for the calculator, because as of right now there is no background. Color and or it's broken, I'm going to come in here create my own branch fix background color.

C

Let me zoom in a little.

A

C

As you can see, we're now creating from dev.

C

My branch, so I'm going to come in here.

C

As you can see, we have a background color. This particular value does not exist. So what I'm gonna do- and you know you'll- usually probably do this from an ide text editor. What have you for the sake of this I'm going to simply edit it in our online editor, which is perfectly fine with me.

C

I typically like to give at least some idea of what my commit really is. I don't really like to kind of leave that watermark text there, because you know other developers looking at it. They could spend hours. If this was you know a 700 line, long file thinking, you know what is update default, css, so updating background color we're going to commit it directly to the branch I created great. Now we have an actual background color.

C

The next thing I'm going to do from here is not just go back to the code screen and open up a pr which you'll see at the top, but background color. Isn't loading gonna? Let matt know that I'm on.

C

C

Great so back to the main screen or to the pull request screen, whichever you know, process you're more familiar with this just makes things much easier. um One thing to note, since so this was forked from a template repository that we have, if that's the case, for anything internal for you, unless you want to create that pr back to the source, repo make sure to change your base repository right here.

C

So we'll switch this to dev, updating background color.

C

Really not much to put in here.

C

But a good rule of thumb for prs that I usually always follow is title being the what the body being the. Why now, this isn't really a why? But for the sake of this, we'll we'll go along with it all right, create the pull request.

C

And awesome, so this gives me a good opportunity to talk about another area of collaboration that really requires folks to collaborate within a repository and that's the idea of code owners in my checks here, you'll see code owner review required waiting on code on a review from beer to veto test calculator review.

C

Now a code owner can be a team, an individual, a set just of individuals, not in a team, and you can set these particular values over certain areas within your code, so that you know, if you have front-end experts on your team, you know css experts like obviously I am, since I could just quickly change a background, color value. uh You can assign those individuals to particular pull requests that preside over particular files.

C

If you have database, you know back-end dbas on your team, you have all of these things in the same repository you can do that there as well. We go back I'll, show you what a code owner file looks like if folks haven't seen one. It's simply called code owners, you'll create it in your main.

C

Top level branch.

C

And as of right here, we just have a star, meaning that beard test calculator review needs to review everything you can replace this star with things like uh folder pads file, names, uh star.js, so, for instance, any javascript files or star.css for any css files, and things like that, and so that that just makes the accountability there and it gives the team a chance to kind of discuss changes, because these changes happen outside of the team that presides over these areas.

C

It's a good idea for those individuals to chat and kind of understand why those changes are being made.

C

So it looks like matt has approved my pr, which is good news.

C

Looks great thanks for changing this can't wait for the background color to actually show up you and me both because a gray screen is kind of dull and I'm going to go ahead and merge. This pull.

C

C

Put request, merge, go ahead and click branch you can see. I have one commit merged into dev and with that.

C

I have my node ci check running. I have my release drafter check running and I am currently deploying to our development instance on azure. I will show you all what this looks like just a second. I just want to run through kind of another workflow here too, so we've just deployed to the development instance to test this out right.

C

We decide that everything's golden great wonderful. We want to create a release from it once we do that, it'll push to a separate environment, but in order to do that, we need to create an actual release branch. So, let's check out.

A

C

Check out our branches.

C

Actually, let's check out our other pr. This is on me. I should have merged these first as well, because remember I was talking about code owners, matt actually fixed things that were waiting on me see funnily enough. This is where the communication aspect comes into. Play could easily have missed these and pushed a few things out to prod that perhaps we didn't want to, and let's hope that you folks have a step in between development and prod, because just because, let's say yes, so I'm going to go ahead and add my review.

C

Let's see, we change the background image url from images forward, slash to just top level background png, I'm gonna go ahead and approve this.

C

Submit my review.

C

C

Thank you matt for merging that go ahead and then add the titles for the calculator buttons.

C

B

C

Submit review all right.

C

Perfect, so I'm fairly confident now that there are no open issues, no open pull requests.

C

We're ready for release 1.1, as you can see, everything is in the done column. Let's go back to the dev branch here and draft the release from this particular branch.

C

Let me zoom in.

C

And let me actually show you folks what it looks like as well.

C

There you go. Isn't this the most amazing functionality, you've seen what's 23 plus 11.

C

Life changing prior to this, there was, you know, just great screen, so these are what those fixes implemented- the nice, seafoam, green and dark blue amazing color contrast.

C

I don't proclaim to be a ux designer, so let's go ahead and draft a release, so you can do this one of two ways with.

C

Your release management action- you can use the forward, slash like the normal git flow does. So it would be something along the lines of like that to kind of designate that you're in a release branch or that for hotfix, so on and so forth. uh For the sake of this, we're simply going to just release hyphen, I will just do one one.

C

I'll do 1.1 create this from development.

C

From here I'm going to have an action run, automatically looks for open branches, parses out the branch name and in a very rudimentary regex determines if it's a release branch. If it is a release branch we're going to run a few tasks once those tasks run, then we can go ahead and create our.

A

C

While we're waiting on that to finish, let's go back to the main.

C

Screen, if you've noticed, we now have release notes that were automatically created for us by our actual changes by the commit messages themselves. That's why it's? You know it's really important to give them meaningful messages, because if you do there's a git of action called release drafter that will build these release. Notes for you. So it's you know it's invaluable, because chances are a lot of you. Work on teams that push things out without release.

C

Notes, I'm not going to assume I'm just basing that off my own experience, finding release notes for a lot of things over my career have been hard in various different places. So from this we're gonna click draft. We see our draft here.

C

We have who actually committed these individual items.

C

Let's check on our action that is done and has been deployed to our release. Environment.

C

Let me grab the.

C

Got the url for that?

C

Let's go back here! So if you notice we're in staging I'm going to go to release there, we go. We've deployed this through a github action using publishing profiles that we downloaded off of azure.

C

So when I go to releases the last thing I'm going to do is draft the new.

C

C

C

We'll edit, this draft and we'll call this release 1.1.

C

Contains everything: that's changed, it's not a pre-release and let's go ahead and publish it as such, so we now have at least 1.1.

C

You can see that we see them in sequential order granted. This could say, release 0.1, so when I say sequential order, it's really just in the order of when they were created, and I don't know that this necessarily deserved a minor value increase, but that that's okay.

C

Cool we created that.

C

You can see 39 seconds ago, we have a new release and let's check out our production environment.

C

Look at that we have no seafoam green background and that's great because you know what the seafoam green kind of does right is. Tell you hey, you're, not in broad um that that's really what we were going for there so to speak. You know. If everything looked like fraud, you could, you know, perhaps get confused at times and make changes in the wrong area, but that that's really I mean that's all. There is to kind of the release. Branching aspect of things utilizing the git flow within the confines of github.

C

You know one thing I'll say is that your team will need to be absolutely disciplined and aligned up front on following rules following the rules that you all decide on. You know making sure that specific branch names or specific branch name prefixes actually carry meaning to them. uh You know not just having a thousand separate meanings for the word, dev or thousand different spellings of the word dev, meaning. You know, dev development, uh things of that nature.

C

You know align on a naming convention, stick to that naming convention and your teams can be extremely successful using the github flow or the git flow. What's great about having these release branches as well. Is that if I publish release 1.2 say I find a major security vulnerability in release 1.1 as we're publishing release 1.2, I can easily come back and retroactively apply the fixes to these release branches so long as they have not been deleted.

C

um Yes, I mean: that's, that's really, that's really it from the the branching aspect. Side of things so kind of to recap.

C

Talk it out in issues. If you have a problem, you know the more transparency you have the better, because that means the more eyes will be on things, especially if you're working within an organization right. If many people can see a repository, it's not it's not hard to search for particular topics, and I can't tell you the number of times I've searched for something internally here at github and have found what I was looking for in a completely separate repo, and that was due to having an issue created.

C

You know we have a saying internally here that that goes put a url on it. So you know as long as it has a url people can find it and the the knowledge, the domain knowledge so to speak, won't just live within a single individual or a few individuals, pull requests extremely powerful. The use of code owners and status checks again in pull requests.

C

Don't just blindly go in there and click merge for the sake of clicking merge. You know have a conversation, uh you know talk it out. A great example of every bow that I like to go. Look at and use when I discuss these things is the bootstrap repository if you look through their issues and pr's you'll see tons of communication back and forth and a lot of great communication as well.

C

Lastly, you know projects. If there we go. If you know you need even higher visibility for things that are in play, so, for instance, you know if it's easier for you or your team, to kind of just look at a board and visualize where everything is at any given time.

C

Projects are extremely easy to use and they're they can be extremely powerful using automation. Specifically, so you know you close a pr that's in to be reviewed. It could automatically be moved to done so a lot of the manual work has been taken away from us there um yeah I mean you know that. That's really that that's really it from a collaboration standpoint, there's github was built on the premise of collaboration with anybody from anywhere right.

C

So all these tools, when used in conjunction with each other, are extremely powerful. So you know the end of the day. It really just comes down to you and your team. You have to talk to each other and you have to have these conversations so thanks. No, um I really appreciate everybody watching.

C

You know my extremely extremely uh exciting pocket calculator demonstration. You know I got to give a lot of props to beard, video or matt for for helping me set this up. um Thanks, matt, you.

B

Have a problem thanks.

C

Everyone for watching.

B

Super super glad to help set this up um but yeah. So thanks very much for uh hosting today or at least participating and showing off.

B

You know, working in kind of that, like main dev feature workflow, uh we had a question uh that I'll kind of comment on uh in chat that was uh referencing, like you know, if you already have tests set up like why, wouldn't you check just check out to a feature branch off of maine and then merge into your main or master via like a pull request after you've gotten like approvals from your colleagues and stuff?

B

um So if you wanted to touch on that, that would be great. um I kind of answered it in chat, but would love your thoughts as well as to like. You know why. Maybe you wouldn't use something like a just a feature off of maine so like. Why? Wouldn't you use github flow.

C

It depends if your team- so you know I in my previous life in professional services- I've worked with teams who are very proficient in git flow and very proficient in github flow, so depends on what your team is really used to, there's really no reason not to per se. It just depends on the discipline of the team. Now, if you have automation that kicks off, let's say, aside from you know: let's get github flow aside.

C

If you use git flow, let's say you know: you have automation that kicks off for hotfix branches, for release for dev qa, and then you have main you. You might need to go through certain workflows to get there. So that that's a reason I can think of, but but I don't disagree with what the what the user asked. I mean. That's the easiest way really to just branch off of maine and boom be done. Instead of branch off dev push back into dev, then push back into release and so on and so forth, but yeah.

B

Yeah, I would agree, I think, starting I like to say, like starting small and then um working your workflow up as you run into issues or you start to identify like that things aren't working for you or your team. I think that that's just kind of how it works best, as opposed to like going grand or big with your workflow, because you read like a blog or something and then trying to fit your team's workflow to that, doesn't necessarily work.

C

You know I I used the phrase before that when that happens, it starts to look like the subway map for new york city.

B

C

Yeah, you don't want to get yourself into subway map mode.

B

Yeah um yeah. So if uh there are any other questions that people have feel free to throw it and chat, um there might also be a link that we're gonna throw into the github community forum uh for the q a as well, which is where these questions. uh Actually the topic of today's session was kind of sourced from the github.community uh group, uh which is going to then like drive further 30 minute to merge.

B

B

So yeah all right well, so thank you very much. Everyone for attending um and andrea will be dropping a link in chat for the um q, a session on the github community site and then uh yeah. I hope you have a great rest of your day and hopefully have a great weekend as well. So thanks everyone for joining, have a wonderful one and we'll see you in chat or in the community forum, have a good.

B

B