GitHub Git Merge 2022, 14 Sep 2015

Previous Meeting

⏯

youtube image

►

From YouTube: Git: a Love Story - Git Merge 2022

Description

Presented by Dan Kim

A git story is more than just your typical story. It is one that often centers around a hero. But we typically only see the end pull request: the story that the hero wants us to see. Before the rebase, the story is filled with struggles and stashes. Filled with time travel, love, and hate. All the elements that make for an epic tale. And today, we take a step back to marvel at the journey, not just the end result. As it is through the fire, our git skilled are sharpened.

About Git Merge:
Git Merge is dedicated to amplifying new voices in the Git community and showcasing the most thought-provoking projects from developers, maintainers, and teams around the world. Git Merge 2022 took place at Morgan Manufacturing in Chicago, IL on September 14th and 15th.

A

Hi morning I think so yep uh my name is dan kim I'm here to talk about git, a love story.

A

um This is mainly a talk like in terms of my like history, with getting sort of where I got started.

A

And where I am now and how much I sort of enjoyed that journey um all right, let's all get started, I.

A

Think I have the unique distinction of the being the only presenter not to have an actual real.

A

Picture in the slides or in the on the website, I am not an actual penguin I just like penguins so.

A

um If you are disappointed that I'm not a penguin, that's kind of your fault, I think uh I work at.

A

Nuna, as a software engineer, um nuna at nuna, we share a passion for improving the quality and.

A

Cost of health care in america and we're trying to work with industry decision makers to sort of.

A

Answer the hard questions around how to use that sort of patient data to to be more meaningful.

A

Okay, so with any story, it's there's typically some sort of journey involved. Everyone starts at.

A

A different place so coming out of college. For me, um I didn't have a whole lot of experience in git.

A

um When I submitted assignments, it was mainly through a zip, and I emailed it to my ta.

A

um That was quite quite a contrast, because you typically in depending on like the coursework.

A

That you work with you generally don't need to use a version control system because you're doing all.

A

The coding typically, but as you sort of delve into that professional space, you start using.

A

Ides and start working with other people, and so uh I guess my experience with git to start out.

A

Wasn't the best um back in the day? I don't know if this is still the case, then default.

A

For intellij was to force push any commits when you were committing through the id.

A

I don't know how many of you know how how problematic that is when two people do that, but.

A

Basically, there was the scenario where both of us would write the same release and I would say that.

A

This is the correct version of code and he would say- or she would say that this is the correct.

A

Version of code and come release time, it made testing quite interesting, just to say the least,.

A

uh But I did learn some stuff. uh Reflog is your friend. Typically most things can get. Can.

A

Be reverted and are managed really well in the ref log that you can revert to things and then.

A

um Anytime, you force push. You should also always remember to do it with force push with waste, so.

A

uh So getting off to the bet on a better foot, I think that, as you sort of grow and use more.

A

Git commands the ones that you use more commonly will end up in your git config.

A

um I I wanted to share a couple different aliases that I like to use.

A

um More frequently, this is one of my favorites just getting off on the right foot. Getting.

A

Started quickly, it's go which basically checks out the branch if it exists and if it doesn't.

A

It creates the band for you, so just a little shortcut um as a precursor to all of this, and.

A

As you're going through wherever journey you're going through, I think it's important to sort of.

A

Whether it's through commits or through pictures or through journaling, I think.

A

It's important to commit early and often, and I think, that'll become evident in.

A

um The next command that I'll go into but sort of the the pattern. For me, at least, is that.

A

Some commits have more meaningful messages want to add a command. Some commits are just.

A

I'm going into a meeting, I kind of just want to push this code somewhere and it's. This is just.

A

What I feel like organically happens for me, not every commit message is verb, whatever you're doing.

A

I feel like life rarely works out that way like you, you don't always have the time to sort of.

A

Do all the things, but I think it is important to sort of have checkpoints as you're committing so.

A

And that's why I kind of want to cover a little bit um forget bisect and how it works. So in this.

A

I guess I'll step back one sec, so you'll kind of see that as I'm committing, I kind of identified.

A

That, on the second to last, commit with with the hash of f4, I refactored from some code, but I.

A

Accidentally broke it in that step too, and I knew that the unit tests were working. A couple commits.

A

Down on e5, because I ran them before adding them, so those are the kind of commits that are kind of.

A

Important for bisect, knowing um the last sort of good commit when their code was in a good state.

A

And typically, like you just look ahead, so that's the starting commit so it'll go.

A

Through that range, and do like a binary search to determine um where you sort of introduced.

A

The error: this becomes a lot easier if you use the run command and you sort of run the.

A

Specific unit tests that you broke to sort of identify which commit introduced that breakage.

A

um Okay, and so we fixed the bug another one, I really like is git yolo. This is.

A

Very specific it sometimes like I, I use whip work in prior estimates. A.

A

Lot, but sometimes I just don't know what to write, and I just do git yolo.

A

And what that does, is it just pulls a random commit message from that one website and.

A

In this event, when I was recording, it said this one was really hard so uh and then your.

A

Code's done right, like you've, you fixed all the bugs you've made it to the end.

A

Of the story and sort of that's kind of where most people just stop with coding, I feel like.

A

um And that's kind of why I want to dive into sort of part two.

A

How are we doing uh so? The draft the draft pr the draft, mr, um if you've reviewed a lot.

A

Of code, this is an example of probably one of the largest prs that I've reviewed this year.

A

um You'll often see that this, this wonderfulness that says diff is too large, cannot render so.

A

Depending on like how larger change that is,.

A

I think it's, it becomes kind of more important that you have more meaningful, commit history.

A

And you kind of split out the commits so that it becomes more reviewable right so.

A

um But I think before diving into that, I want to take a little step back and git graph. I think this.

A

Was sort of demonstrated in the workshop, but this is sort of my variant on git graph, where.

A

I like to see things in color, so um this is what it sort of looks like and for different projects.

A

And different teams you'll adapt different patterns uh for this repo. I believe it's bazel.

A

It seems like sort of the pattern that they're using is that they're. They probably do an mr.

A

Process or a pr process, and they squash all of the code for that that code into one commit and.

A

They don't have a merge commit so that sort of varies. This is an example of a different.

A

Project where it's kind of sort of somewhere in between some people do that sort of pattern.

A

Where the first one it's it's squashed into a single commit, but then other people in this repo.

A

um They'll have the commit, but they'll also have the merge commit and then in other scenarios.

A

They'll return retain some of like history. They have there and also have a merchantment.

A

So different patterns for different teams, I think they're all valuable for different reasons, and so.

A

The life cycle of a project and who you're working with um sometimes it gets a little bit more.

A

Complex when you don't have a release, manager and people kind of just do whatever they want and not.

A

All not all code gets merged back. So that's why I like some branches just end up in nowhere, um so.

A

uh I guess some line merge, so this is sort of the pattern that I use when trying to like clean.

A

Up the commit, so getting rid of all of the whip commits all the commits that don't really have.

A

Valuable message or information so that it makes sort of the pr or mr process easier for whoever's.

A

Reviewing the code so in this I guess I don't know how visible it is, but you'll see that there's the.

A

Initial, where I have the branch where I swear, I branched off of the feature. That's like the.

A

Initial state, I have a bunch of whip, commits and um there's a commit where I said. Oh this feature, I.

A

Finished this feature and then sometimes you'll have to trigger the ci build or whatever for.

A

Whatever reason, none of these sort of commits sort of mean anything in the grand scheme of things.

A

Like the the full diff, so oh, I guess I'll say that you can use sublette merge, but there's also.

A

Integrated tooling, with git gui- and I know that some people sort of do this- this sort of workflow.

A

On the command line too, so I know it's possible, but I prefer this is my preferred tool of choice.

A

Because I like to be able to see sort of like the change set as a whole and.

A

Sort of what I'm trying to to tell you as a story for when you're reviewing the code.

A

um Is this the video yes, so you'll see that, like I'm sort of staging different parts of the.

A

Commit so that first one, I'm sort of fixing a bug that was already already in the in the code base.

A

And then I'll sort of identify that I needed to add or update a dependency.

A

For whatever reason and sort of I'll split that up into a different commit.

A

A

Obviously, this is a very simple example, but it can be expanded for.

A

Larger and more complex use cases, but I think the point is that you're sort.

A

Of chunking the code into more readable chunks, so that I don't have to review two.

A

20 000 lines of code to understand sort of the core change that you're making.

A

um And and oftentimes too, when you're working on features.

A

It often it very often you'll find yourself editing things that are sort of tangentially.

A

Related or you're fixing a different bug, that's or you just saw while you were there, but I think.

A

It's important to like sort of split that out, because at the end of the day, depending.

A

On sort of how large that change is or the complexity of that bug, it sort of makes more.

A

Sense to review that separately than than the work that you're currently working on.

A

um So after all of that, uh so we started on the left and then sort of ended up on the right. So.

A

The right is sort of like the linear story that you tell you're, not necessarily that.

A

You tell yourself, but this is just how chronologically these events happened.

A

As you sort of worked through code and everyone works differently, this is just.

A

How I work, but I think it's important to take the next step, where you sort sort of.

A

Make meaning out of this and sort of reorder things so you'll see that um how I organized it.

A

I found the bug at the very end after integration testing, but I sort of moved it to the front and.

A

There's various reasons to do that, it could be that you think that you might want to split that.

A

Out into another pr, so it's just more manageable or you kind of just want to ask. That's where you.

A

Kind of wanted to start your story, so that's where the storytelling process sort of starts.

A

um And this is like sort of how I would want to tell the story. I fixed a bug. I added a dependency.

A

For this feature, I worked on the main feature that that is sort of outlined in the jira ticket.

A

Or whatever system that you have and then I also worked on some other tangentially rate related.

A

Things so I think piecemeal, like it's important, depending on the size of your pr to sort of.

A

Make things better for whoever is going to be reviewing your code and outline.

A

Things that you think are important because adding notes to a pr is great, but it's it's.

A

Always nice to sort of just see that side by side, if you're reviewing commit by commit.

A

um So when we get to the actual pr so there's the various there's various patterns around this.

A

This is not neces. This is not necessary to do if you sort of always, if your team always squashes.

A

Into one commit, but if you sort of want to retain that history for certain files, for whatever reason.

A

um So that you can do a git, blame and sort of understand why a certain component of the code was.

A

Changed it's sort of valuable there. This is just a little quicker workflow, where you can actually.

A

Do git commit desk fix up and, as people give you feedback, you can sort of align. Those change sets.

A

To whatever initial code that you were kind of working on, so in this scenario this is sort of.

A

Like the order I have- and this is like I get this one- pr feedback where you need to change.

A

The dependency for a security vulnerability, so the fix up you would you specify the commit hash.

A

And it'll put the commit at the end, but what I'll go into a bit later, where you.

A

Can use something called auto squash, where it'll naturally pull the commit.

A

Into the correct ordering that it needs to be for you to be able to squash, it.

A

um So this is the alias I have for auto squash, it's a little bit fancier because it takes into.

A

Account that not all repos well so they should be renamed their master branch to main it's not.

A

Always the case, so it's doing a little bit of a short circuit -ness there to determine.

A

The correct base of your bench, so that could be either master or head or master or main sorry.

A

And so, if you were to do a rebase without the auto squash feature, you'll see that there's.

A

The fix up message with the exclamation points and then the commit message of the fix up. You.

A

Were trying to do, but if you did it with auto squash, it will sort of label it as a.

A

Fix up so it'll use the prior message, so you don't have to redo that component and.

A

It'll, just it's just again a faster workflow for this sort of scenario. If that makes sense,.

A

And so I think we kind of reached the end once your mr is kind of just you've sort of cleaned.

A

Everything up and you sort of squashed all the things that were extraneous as part of.

A

As part of the pr process um and you're ready to merge back- and I guess the conclusion that.

A

I want to end up with is that it is just it's so much more than just the basic commands that.

A

Everyone is probably more familiar with if you're, only using it through an ide like pull, commit and.

A

Push but there are, there are so many other commands that you'll sort of pick up as you.

A

As you work more with git as you develop your workflow, you refine your workflow. You sort of.

A

Get a better understanding of what your team cares about and how they leverage git um those I sort.

A

Of outline really quickly the ones that I use most frequently and they could be different for.

A

You, but I think, leveraging git, config and again making your workflow faster is very important.

A

And then in the grand scheme of a story, there's the the past or the present and the future, so the.

A

Past is sort of how you experienced and you how you wrote the code. That's basically before the mr.

A

Presently, you kind of want to clean things up so that when someone's reviewing it, they sort.

A

Of have a better experience, you don't have to work through. You don't have to go through 200 files to.

A

Determine like what core change that you're trying to make and then sort of the final product is when.

A

You merge back, there's also the concept of keeping those commits so that people can see historically.

A

Why you made certain changes, regardless of whether it be part of the feature branch or not so.

A

I think it's important to consider that the time you spend with code is not not your own.

A

People think that, because code is the end, result is code, is that that's just.

A

That's just the final product, but I think it's more than that. It's you want to tell.

A

A story you want to you want to share what you learned. I think that's best done if you.

A

Do you take those extra steps to make the process better for everyone else.

A

That was it for me.

A

I don't know if I'm supposed to take questions but.

A

Does anyone have a question? Oh.

B

A

Get everything you said if you asked if I needed, if you needed to force push sorry? Yes, yes, you do.

A

Need to do a force, push anytime, you do a rewriting of history. So anytime, you rebase, and you change.

A

The actual commits it requires a force player and is that generally kind of accepted, like it's okay,.

B

That you're a force pushing into a pull request in that way, not during a pull request. So that's.

A

From my personal perspective, you should not do that because, depending on who reviews your code.

A

And how they review it? If you do a force push, it becomes more difficult for you understand.

A

The specific change sets you requested, so this happens after the approval. For me personally does.

A

That make sense: okay, yeah, because when you were describing rewriting, I assumed you meant for the.

B

Person who was reviewing the pull request? You're, not yes, yeah, so there's like there's like two or.

A

One or two stages, where you rewrite history and they sort of happen differently, at least for me,.

A

All right, I'm happy to talk with about the sort of the process that I use. Oh, uh is there somewhere.

B

That you posted your git config commands that we can look at yes, I can make that available.

A

Somehow I'll record I'll try to coordinate with the event people to get get that out there.

A

All right, thank you very much.