GitHub Git Merge 2019, 12 Mar 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Git, the annotated notepad - Git Merge 2019

Description

Presented by Aniket Subhash Kadam, Consultant, Self Employed

"Ever forgotten what you were working on the night before and needed a few minutes to get back context? Wondering if you're writing the best code you could be? Having repetitive conversations with coworkers about your code?

We'll go over how git can help at every stage of coding, from fleshing out your idea to coming back to it over lunch, to the best highlighting you've missed putting to use."

About GitMerge
Git Merge is the pre-eminent Git-focused conference: a full-day offering technical content and user case studies, plus a day of workshops for Git users of all levels. Git Merge is dedicated to amplifying new voices in the Git community and to showcasing the most thought-provoking projects from contributors, maintainers and community managers around the world. Find out more at git-merge.com

A

So my name is Ankit, Kadam and I'm here to talk to you about one way of using it in your workflow and that's a lot like an annotated note that you'll see what that means. Now enough about me. Let's talk about you. Let's say you just you just get up in the morning right and and you're on your way to work, and then you sit down at your desk and you wonder what was I doing again yesterday was it working on a feature?

A

Was I fixing some bug, maybe I threw in some code and I wanted to add a to do, but I forgot whether it was right and at this point you may open Prioleau or just to figure out like you know how this thing is supposed to actually work right, but it turns out there's a better tool for that and there's no prize for guessing which one that's going to be so I'll be talking a lot about get Cola and that's what it looks like it's.

A

My favorite, you I forget: I love the terminal for a lot of things, but you will see how get Cola helps and when I sit down on a desk. This is what I'm gonna open up and instead of having a massive codebase to look at or a cryptic teller to decode I'll be looking at these handful of files, whose file names themselves will tell me a lot of what I was working on and I can just go and look at those diffs for more context.

A

So that will immediately get me back to what I was trying to do. But it's possible that you get diffs. Don't look like this, they could end up looking like this and it's pretty easy to get here. If you don't commit really often- and there could be a lot of completed features in here, there could be too big of a part of a feature in here to make out what part you are focusing on, and it's pretty much impossible to learn anything from this because there's just too much noise.

A

So how do we get from something like this to maybe something like this and if you're looking at this you'd say alright I just added this library yesterday, I'm gonna go ahead and implement the code which I need to this for, and the answer is with small logical commits and best metaphor for small logical comments. I've found is a game called dark souls. Now I, don't play Dark Souls myself.

A

So if I get some, if I describe something wrong about it, just don't tell anyone right, but the only thing you need to know about Dark Souls is that it's a hard game. It's a really really really hard game in your facing enemies. Like this all over the place, you've got a lot of obstacles which makes it a pretty good proxy for software development.

A

So this could be like a level of Dark Souls right or it could be like just a project. It could be just one sprint. We are at the start. You've got obstacles along the way you're trying to get to the finish, which is your release and, let's say, you're playing this hard game called Dark Souls. Where we're at any moment, you could be reset all the way back to the beginning of this level, but you could hit a button and save your progress at any moment. How often are you going to hit that button right?

A

The answer is as simple as ABC always be committing right. So, to get back to this, let's say you begin your project and you're like alright I'm gonna do a bit of refactoring before I start work on my features, so you attack those little obstacles of refactoring and get that out of the way, and then you commit right and then you decide to explore down this random path to figure out what is the best way to do these features? And you go around that path. You find some things that work.

A

You find some things that don't like whatever doesn't work, you throw it away and whatever works you come in right and then you and then you finally begin work on the features themselves and you commit all through a and you're the only way. You're just you have just you just completed all of this you're, it's all saved, and then your product manager, just pops in to say, like hey, you know, isn't there enough time to do just one more small feature before release you probably want to tag right here.

A

Is this: what's actually gonna get released, but but anyway, like you, you keep committing and then you'll get through this. So, to summarize, what is what does it mean to commit and logical units? So what is a logical unit? Refactoring can be a logical unit because it because refactoring is such a thing where you can, with small small change.

A

You can affect a whole number of files, a whole number of places within those files, and if those diffs get mixed in with the diffs, which are related to your actual logic, it can be pretty hard to see what's happening anymore. So you want to start with a clean. You want to start with a clean, diff you're on a jewelry factory, and you commit that as one commit next, when you get your actual features, let's say: there's a set of functions which compose together make up one feature.

A

Now these could be spread across multiple files or at different parts in the same file, but because you're all working together, because they all are part of one feature that makes them one logical unit and all of these things should be committed together.

A

You may have one complex function. This doesn't have to be a large function, maybe there's something that just takes a line or two, and that completes your whole feature just because that the logic of that function isn't related to anything else. It is by itself a logical unit. So, to summarize, any set of changes that it makes sense to see together is something that you should commit together. Now that's a lot of work and you better fix it and we better be getting something for all of that work.

A

So, let's see what are the advantages of logical comments, so this is something so this could be a feature that you're committing, and it should only look like this with a handful of files. Just just a little bit of diffs, a nice descriptive commit like a nice, descriptive, commit message, and what this gives you is an overview of how everything is supposed to work. So you've just finished the feature. It's that's the only thing.

A

That's that's in your diff that you're looking at, and you can just read through this and make sure it's doing what you think it's supposed to be doing right.

A

It also gives you a chance to clean up like how many times have you been trying, something which is just on the edge of your ability. You have to learn a lot to just make this thing work and now it works. So we can borrow a concept from TDD, which is like red, green refactor. First, we just care about getting it from red to green, to make it work, and then we clean it up.

A

So this also gives you a chance to read through your code line by line and focus on what is the thing that you would want to improve in this, since you don't have the pressure of trying to make it work, it's much easier to do it at this point. So another thing that's really helpful. While you're doing this is a selective stage, I'm sure what all of you know and show off. You know how it looks like, but just to show you this were to select.

A

Your stage looks like and get Cola, and this is what I really love it for you just select that and you press s, and that section is selected and as you're reading the code line by line and character by character to make sure that it does. What do you think it does? You can make sure there's. No, that should be a plus and you kind of check off this line in your mind, like yeah, okay, I have proved that this thing works and you staged that another thing. It's really useful for us.

A

Let's say it's like 455 and you've just begin to commit everything you could stop at whatever point you want to and the next day when you come back, you only have to look at what's still modified, because that's just where you left off. It'll save you time there.

A

So all of these things together are what I call get discipline which involves to always commit in small logical units, as we saw to read every diff line by line before committing it's a chance for you to do a personal code review before you send it off to your team code review and since we have just read everything line by line since you have just finished the feature, you can actually have a descriptive, but a really descriptive title and you won't have changes more changes, I promise. It really works now.

A

So so you can have a really descriptive title here and you can take the time to refactor the best you can before committing. And this gets you quick context reloading, because you only locate a small section. It gives you more working memory so that if you focus only on writing the code and then only on refactoring, it can give you an enhanced focus which will help you write better code with fewer bugs. Thank you.