Jeff Terrell: Okay, let's get started here today.
Jeff Terrell: I'll come back another week in the saddle here in classes.
Jeff Terrell: Semester starting to drag on a little bit seems like not I don't so much mean it for me. But I feel like a lot of people are going through a lot of midterms and are feeling the mid semester slumps so
Jeff Terrell: I don't really have anything to say about that just kind of commenting.
Jeff Terrell: Alright, today we're going to talk about get Part two
Jeff Terrell: We are probably over halfway through the actual extras this class, towards the end of the semester it's mainly going to be tech talks that I will listen to you. You will be giving lectures to the class.
Jeff Terrell: So,
Jeff Terrell: Yeah, I don't know. I guess that's worth knowing. That's coming up.
Jeff Terrell: Yeah, let's do, let's do get Part two. We're also going to do quiz three today. Apologies for getting about that last Wednesday, but I do have that setup to go today. We'll do that at the end of class.
Jeff Terrell: And so I'll stop.
Jeff Terrell: Going to try to stop 15 minutes early. To be sure I give you time to do that. There is a 15 minute time limit on it as well.
Jeff Terrell: So without further ado,
Jeff Terrell: So yeah, that was I remember by dead mouse, just because I like it.
Jeff Terrell: No further announcements. I wanted to check in about the assignments.
Jeff Terrell: It's been a little bit since I've done that. So, this week we have the application architecture and the architecture diagram do so you'll be talking about that with your mentors.
Jeff Terrell: Note that the big assignment walking skeleton assignment number eight is to in two weeks.
Jeff Terrell: So the idea of this assignment is to avert disaster which was so common, I think in comm 523 projects before having this assignment eight it was is pretty common to say, well,
Jeff Terrell: You work on the front end, I'll work on the back end, you know, we'll figure out, figure out how French to talk to the back end as the last step, and as long as you have the front end done and I have the back end on that should be easy. Right. Well, no.
Jeff Terrell: devils in the details and the devil comes and bite you on that last day when you're trying to get everything working and you realize I should have allowed
Jeff Terrell: A lot longer for this than I did. So the idea of the walking skeleton is to avoid having that kind of panic moment at the end.
Jeff Terrell: And I ending up with the project that isn't useful to anybody because there's a pilot code that doesn't talk to itself, talk to each other effectively. So the walking skeleton requires you to integrate first
Jeff Terrell: Skeleton idea of this is to find the simplest set of features that could show the pieces working together and ignore all the other features. Just get something that's connected
Jeff Terrell: Without worrying about getting everything so it's it's kind of a depth first approach over breath, you'll fill out the breath and put some flesh on the bones as you continue on after assignment eight and work on features.
Jeff Terrell: Of walking part of this term comes from that it should actually work and be deployed.
Jeff Terrell: Part of the integration that you have to figure out is how to deploy it. And so that's where the lecture. A couple of lectures ago comes in handy where we talked about deployment and her Roku and the 12 factor app.
Jeff Terrell: Remember the ass lab is ready to help with all of this stuff, you know, I can't necessarily guarantee that the Apple app will be able to help you with everything that you could possibly encounter, but
Jeff Terrell: You know where they are to try at least and the sooner you ask for help, the more likely will be able to give it to you before I sign my name is do
Jeff Terrell: I don't know whether there will be a big rush to get help, right before the assignment deadline or not. But if that does happen, you know, it will behoove you to get get that help sooner rather than later.
Jeff Terrell: And even apart from needing help and potential contention there.
Jeff Terrell: It would be foolish, I think, to wait until the week after next start on assignment eight, you should start on an assignment eight at the latest, and next week after you've finished assignment, six and seven and turn that into your mentor.
Jeff Terrell: It's certainly not a problem to start assignment eight before then. You do have to have figured out which you know technologies you're going to be using. So that's the gating factor there but
Jeff Terrell: Anytime after you figured that out, even if you haven't written up the architecture decision records for assignment six or written or, you know, written the diagram for assignment seven, you can still start on assignment eight and get that walking skeleton moving
Jeff Terrell: Any questions about anything their assignments or anything else.
Jeff Terrell: Okay, I assume, everybody's making good progress on that I've been getting good reports from your mentors seems like people are generally on track and doing well. So kudos to you all for doing a good job.
Jeff Terrell: With this and continuing moving even though you know we can't have in person classes and in person meetings.
Jeff Terrell: Yeah, from what I can tell, it sounds like most things are going well. But I don't hesitate to reach out for help if you need it.
Jeff Terrell: Okay, I realized, last time I didn't actually talk about one alternative to get which is just to use a shared folder right use like Dropbox or Google Drive or something like that, why not just put your code there.
Jeff Terrell: And I think my lecture would have been improved if I have talked about that and use that to motivate like it is useful. So I wanted to go back and mentioned that idea and respond to it a little bit.
Jeff Terrell: Today, since we're still talking about get
Jeff Terrell: So a few reasons not to just use a shared folder include you can actually see past versions of the code.
Jeff Terrell: And go back to a point in time and say this is the entire code as it existed in April, or on April 13 or whatever.
Jeff Terrell: And that's a useful thing when you need to have that you just can't get there from a shared folder and maybe you'll never need to meet that but if you do shared folders will get you there.
Jeff Terrell: Being able to see exactly what changed is really useful even what changed at some point in the history of the project.
Jeff Terrell: That too is a really useful feature that get provides but that a shared folder would not
Jeff Terrell: And I've actually had clients asked me by the way you know why, why do I need to learn these commands. I don't know yet what is this good thing like
Jeff Terrell: Can I just share my code with you if I'm working on the styles and you're working on the the code, can't I just share a folder with you and you can figure it out.
Jeff Terrell: Well yeah, I could, especially if there's only two developers like one person working on one half of the code never touching the other files. The other person working on the other half, and never touching the other half, so
Jeff Terrell: That could work.
Jeff Terrell: But it would be
Jeff Terrell: You wouldn't be able to go back to a point in time and see what changed. Exactly.
Jeff Terrell: You'd only be perpetually looking at the latest code if something broke could be hard to figure out what went wrong.
Jeff Terrell: We can't really annotate a snapshot. There's no real concept of snapshots there so you can annotate one to say like, this is what's changed recently.
Jeff Terrell: So we'll talk in in a bit here about you, good annotations that actually are really valuable for an entire development team.
Jeff Terrell: But you can't really do that with the shared folder and, in general, thinking about working in a team of developers without clobbering their work or getting into some weird conflict.
Jeff Terrell: Is hard. It's hard to think about how to do that. What sort of protocols, you might need to set up with your teammate. What sort of disciplines, you might need to follow as a team to avoid clobbering somebody else's work.
Jeff Terrell: You could say, well, hey, you know, I'm going to work on food.js RIGHT NOW AND NOBODY TOUCHED that file until I'm done.
Jeff Terrell: Well, what happens if you realize you also need to edit bar, such as and maybe somebody else's currently editing that one, you get into some weird locking cases.
Jeff Terrell: And you're having to manage all this with like explicit messages and waiting to hear back from your teammates and that's just a pain.
Jeff Terrell: You could also just say, well, I changed these five files and let me look at the time steps on those files and see if they're newer than what I have
Jeff Terrell: Well, they might not be newer than what you have. But there, there might still be some changes that you weren't aware of. And so you might be clobbering your teammates work.
Jeff Terrell: And so in general, you could probably get away with doing that if you're really, really careful. But it would be tedious. It would be error prone, you'd have to wait on your teammates, potentially, to respond to you.
Jeff Terrell: Not a good approach get solves all these problems and any good version control, control system is going to solve these problems.
Jeff Terrell: So that's just kind of a note motivating the topic of study and get
Jeff Terrell: OK, so moving on from there. I wanted to kind of review what we covered last time just to get our heads back into gets in back where we were from last Wednesday.
Jeff Terrell: So remember these concepts that we talked about, like commits are snapshots of the code with metadata refs or also called branches are pointers to commits remote is a URL that holds an instance of the code base named URL.
Jeff Terrell: And fetching and pushing and pulling our ways to share commits between remotes
Jeff Terrell: And I wanted to respond to a couple of questions that came up in the what topics were confusing or unclear takeaway question from last time because I figured if one person had these questions, probably more than one did so.
Jeff Terrell: One person said I was confused about what it means to have a branch checked out.
Jeff Terrell: And that's where the head meta ref comes in. That's my head is it's indicating what is currently checked out right now and your repo.
Jeff Terrell: Typically head is going to point to a ref, which is to say, a branch wraps and branches are the same thing. And so I've had points to a branch, it means that that branch is checked out.
Jeff Terrell: Head could also point to a commit, which means that committed what's currently checked out.
Jeff Terrell: Okay, another student said I don't understand. I've good flow for creating different branches. We'll talk about the this time when we get to the advanced recipe for collaboration.
Jeff Terrell: What's the difference between a ref and a commit
Jeff Terrell: Commit is a snapshot with meta data and the ref is a pointer to that commit. Alright, so the commit is the actual snapshot the ref is some named pointer.
Jeff Terrell: Also called a branch unnamed pointer to a commit
Jeff Terrell: One of the things to know about refs or branches is that they automatically update whenever you commit
Jeff Terrell: When you commit you're creating a new commit and updating what you're currently checked out RAF assuming you're currently checking out a ref what that should now point to is the new commit that you created so that raffle get updated.
Jeff Terrell: Alright. Another question was, in what situation, would you want to fetch and not pull basically if if you want more control over the merge that happens automatically as a part of a pole, then you'll want to fetch rather than pull
Jeff Terrell: One example of this would be if you want to replace instead of merge, which actually is a very common thing that at least that I do. I think is a really useful thing to do. I will fetch and then re base rather than to pull, which would be a fetch and merge.
Jeff Terrell: All right. Final question I wanted to cover just as kind of review to get some of this information page back into your head. What is the difference between downloading and cloning.
Jeff Terrell: Cloning is the initial download when you first clone the repo. You're getting everything getting the code base set up and getting that local instance that lives on your hard drive.
Jeff Terrell: Setup. So you have to download all the information about the code base from the origin remote that your cloning from
Jeff Terrell: In contrast, fetching and pulling our different kind of download that happens after the initial clone. Once you have that code base set up locally, then you can fetch and pull and that also as a download you're downloading information from origin or some other remote potentially
Jeff Terrell: But it's not a clone.
Jeff Terrell: Alright any questions before we move on and kind of pick up with
Jeff Terrell: Merge strategies merging and rebasing
Jeff Terrell: Okay.
Jeff Terrell: interrupt me anytime with questions. I know it takes a minute to type things out. Maybe it takes a while to digest. So
Jeff Terrell: If you have a question and you need a minute I think kind of figure out how to formulate it and type it out, you know, feel free. Just to paste that in the chat, the chat window and I'll get to it when I get to it.
Jeff Terrell: Okay, so I'm gonna, I kind of already reviewed some stuff from last time I'm going to continue to review here a little bit and also move into the merge strategies where we left off last time.
Jeff Terrell: Sorry, and then we're gonna talk about the advanced collaborative recipe that solves some of the problems with the basic recipe and then I'll just get into other tips just kind of a grab bag of other tips that that I have kind of recommendations for using it.
Jeff Terrell: So we're call this basic recipe for collaboration highlight highlights are initially you want to pull everything down from origin.
Jeff Terrell: And then you want to make some changes to your working tree, which is the files in your local directory that local instance of the repo.
Jeff Terrell: And then at some point you'll add some at least some maybe all of those changes to the index.
Jeff Terrell: And then you'll create a new commit based on the content. So the index and push that commit up to origin and maybe origins master branch in particular.
Jeff Terrell: All right. And remember, the problem with this basic recipe is what if one of your teammates push to commit in between your pole and your push
Jeff Terrell: So you pull you make some changes you create a commit and then you push but you realize, somebody else pushed first and so you can't push you get a rejection notice from origin says, I'm not going to accept that.
Jeff Terrell: Your, your changes rejected.
Jeff Terrell: So then what to do about that.
Jeff Terrell: And there were two different strategies for dealing with that one was merged and one was re base. I'm calling this problem, the intervening teammate push
Jeff Terrell: And the problem is that the histories have converged and origin versus your local repository have different opinions about which Commission follow this one. So if we look at it, get L output we saw the kid l alias last time.
Jeff Terrell: We've got this commit and origin thinks that 971 F is the command that follows that your local repo thinks that is the commitment follows that so histories have diverged.
Jeff Terrell: The goal of emerged strategy is to incorporate the changes from origin masters commit into your local history.
Jeff Terrell: So the first step is not to change what's on origin but to change what you have locally, so that your history includes what origin has
Jeff Terrell: And that's a generic goal that both merge and re base will meet
Jeff Terrell: And one thing I think I didn't say very clearly last time that I wanted to clarify this time is that both merge and re base.
Jeff Terrell: Get us to the exact same commit snapshot. Alright, we're going to have different meta data for the commits, which is why the actual commit addresses are going to be different with emerged versus hurry base.
Jeff Terrell: If nothing else, the
Jeff Terrell: commit messages are different, but also a few other things changed as well. So our commit addresses are different, but the snapshot that to commit is sort of pointing to.
Jeff Terrell: Is the same in both cases, assuming there's no merge conflict or if there was a merge conflict that you resolve it in the same way I the way
Jeff Terrell: You'll have the same snapshot. Alright. So merge and re base both solve this goal, they have different ways of doing it, but they both get us there, and they get us to pretty much the exact same place.
Jeff Terrell: At least in terms of a snapshot, a little bit different terms of the history, which is important.
Jeff Terrell: Okay, so I wanted to, I went through a base pretty quickly last time. So I wanted to go through this a little bit more carefully. This time talk on it like
Jeff Terrell: I think though.
Jeff Terrell: The resolution. I'm viewing
Jeff Terrell: These slides in when I'm writing them as a different, I guess, the resolution here that I'm sharing on zoom. So
Jeff Terrell: This is cut off. That's pretty unfortunate. All right. Um, you can
Jeff Terrell: Know,
Jeff Terrell: I could zoom out and fix that.
Jeff Terrell: Okay, I'm gonna have to deal with that some of the way
Jeff Terrell: Anyway,
Jeff Terrell: So what happens here. I think I can do this from memory. And I'll just have to fix the slides for next time or like
Jeff Terrell: Before hopefully I'll remember to do that fix the slides and put them the fixed version online.
Jeff Terrell: I wonder if the PDF version is cut off in the same way, it probably is. Anyway, so the way rebates is kind of work.
Jeff Terrell: That the words that we might use our we're going to re base your commits a top origin master or onto origin master.
Jeff Terrell: And the way this works is kind of the algorithm. First we identify the merge base, which is the nearest common ancestor of where you're at and where you want to replace on to. So we're at 2162 and we want to re base on to origin master, which is commit 971 f
Jeff Terrell: So the merge base between 2162 and 971 F is the nearest common ancestor, which is this one. It's actually just one hop away from either of these F6 ad
Jeff Terrell: So that's our merge base.
Jeff Terrell: Alright, next step we take where we're at right now and we walk up the history until we get to our merge base.
Jeff Terrell: In this case, that's only one step away.
Jeff Terrell: And for each step we capture and push on to a stack the changes that need to happen.
Jeff Terrell: The changes that are sort of represented from that step. In other words, going from F6 ad to 2162 has a certain depth associated with it to make those changes. And what we want to do is basically push that diff onto a stack.
Jeff Terrell: And keep pushing things onto the stack one at each step until we get to our merge base.
Jeff Terrell: I hope that makes sense.
Jeff Terrell: Then we advance our local RAF which in this case would be master.
Jeff Terrell: We've sort of walked it all the way back to our merge base and then we want to advance it to origin master that are our target of the base, which is where we're rebasing onto
Jeff Terrell: So we're going to advance master local master from F6 ad to 971 F and that's going to involve a change as well. Right, that's going to change what's in your working tree.
Jeff Terrell: Because there were some set of changes associated with transition from F6 at 8971 f
Jeff Terrell: So we walk and that's called a fast forward merge in this case.
Jeff Terrell: So we do that and now master is set to 971 F. Finally, we start to pop all of the sets of changes from our stack.
Jeff Terrell: And replay those commits in reverse order on to our new 971 F commit
Jeff Terrell: Alright. So remember we captured the chat of changes from F6 ad to 2162 because we only had one step, we only had one diff here one commit to replay.
Jeff Terrell: And so once we got master up to 971 f we replayed that one commit on top of that to get our final re based version.
Jeff Terrell: Okay.
Jeff Terrell: And I think let's see here.
Jeff Terrell: What we end up with is this year. So we've got once we do it get reverse origin master, we are left with head.
Jeff Terrell: Which is pointing to master, that is to say, masters, the currently checked out branch.
Jeff Terrell: That points to a commit that is my command. It's my replayed commit. So it's a little bit different than my initial commit which had an ID and address of 216 to my replay of Matt has a different address because the metadata has actually changed. But what we have is a linear history now.
Jeff Terrell: So we went from F6 ad to 971 F, which is origin master. So we let origin master stay where it was. We didn't change it.
Jeff Terrell: And then we replayed my commit on top of origin master to get this commit
Jeff Terrell: All right. And again, what's at this commit here the snapshot. There should be exactly the same as the snapshot that's contained in the merge merge approach the merge approach creates a new covenant with two parents one parent is my commit the other parent is origin master.
Jeff Terrell: And this snapshot snapshot container this commit is the same as a snapshot contained in this commit both of them get the job done and we can push either one of these commits up to orange master.
Jeff Terrell: Because they both have the current value of origin master in their history and so origin can look at that and say,
Jeff Terrell: Gotcha. This is a fast forward merge from a master branch. So I just kind of fast forward up to in this case, nine, seven f two, or in this case for a to six, but both cases work.
Jeff Terrell: Okay, so notice a couple of differences here rebates only has four commits, whereas merge has five commits
Jeff Terrell: And furthermore, what this says. And you can't read is that rebates has a not has a hit. Linear history but merge has a nonlinear history.
Jeff Terrell: And I mean, you can just tell by looking at it. This is more complex, right. This is harder to read and parse and understand because you have a nonlinear history, you have a commit with two parent commits and it's just a little bit harder to deal with this is a nice clean linear history.
Jeff Terrell: But it is rewriting history, and we'll see kind of some implications for that in a minute.
Jeff Terrell: I'm going to show rebasing with a slightly different view.
Jeff Terrell: Here, just to hopefully let it sink in a little bit more
Jeff Terrell: This is from the pro get book is, by the way, is a fantastic book pro get. It's all online for free. It's sort of the official book of get
Jeff Terrell: I've read it all of it I it was very helpful to me as I was trying to understand how it worked. Years ago. And this is kind of what I was talking about.
Jeff Terrell: Last lecture when I said this tool. I'm pretty sure it gets going to be around for many years to come.
Jeff Terrell: And so it might be worth taking some time and putting an investment into this tool to get good at it because you're going to be seeing a lot of it.
Jeff Terrell: And I made that decision. Several years ago and said, I'm going to sit down and read this thing so that I have a really good foundation here.
Jeff Terrell: It's well written illustrated better than my slides are I'll say that at least it's good book so
Jeff Terrell: So, chapter three, six talks about rebasing
Jeff Terrell: This is effectively kind of the example that I had set up with something a little bit more concrete, maybe it's better to just have kind of symbolic commit ideas here instead of having the, the ones that I showed with like
Jeff Terrell: 9971 if they're just other doing here is saying that see two or whatever it is, you know,
Jeff Terrell: But each one of these is commits and the commits are pointing to their parents, similar to what we saw with the get our output earlier.
Jeff Terrell: And we have our rafts, that is to say our branches pointing to some of these commits
Jeff Terrell: Alright, so here's our setup and in this case I might be the example I had was master was pointing to something and origin master was pointing to something else. This is a little bit different, but it's the same idea.
Jeff Terrell: Are emerged commit looks like this. All right. And that is just creating a new commit that has both parents in it and reconciles the two divergent histories
Jeff Terrell: Alright, so that's our merge example.
Jeff Terrell: Our rebates example is a little bit different. We undid see for walked forward to see three and then replayed see for to get see for prime which is the same diff, but a little bit different metadata.
Jeff Terrell: Get rebates will even tell you that first rewinding head to replay your work on top of it. So what that means is that
Jeff Terrell: It's going to rewrite head is pointing to experiment. It's going to rewind head.
Jeff Terrell: To see two
Jeff Terrell: And then it's going to replay your work on top of it replaying see for on top of master.
Jeff Terrell: And it says applying add stage command. This is the actual first line of the commit message that's replaying so it's going to tell you, applying this command applying that command applying that commit
Jeff Terrell: However, many commits, you have, and at the end of all of that you'll have see to C three and then see for prime with your replayed commit
Jeff Terrell: Then of course, you can push
Jeff Terrell: See for prime up to origin master to give to update update master don't have to be origin master could be local master, but either way.
Jeff Terrell: So hopefully that alternate illustration helps the idea of a rebasing can, but are there any questions about rebasing so far.
Jeff Terrell: Okay.
Jeff Terrell: A key collaborative decision for you and your team is whether to merge or to rebate as your merge strategy.
Jeff Terrell: I suggest that whatever choice you make your consistent with your teammates, it can be a little bit confusing if you're doing rebasing somebody else's doing merging.
Jeff Terrell: And also you lose a lot of the benefit of doing a rebate and having a linear history. If your teammates aren't also helping you maintain a linear history.
Jeff Terrell: So that's a good collaborative decision to make with your team.
Jeff Terrell: Some of the trade offs. I wanted to kind of inform some of the trade offs here rebasing is a little bit harder to understand the process than merging urging is a fairly straightforward process.
Jeff Terrell: But the output of rebasing is a little bit easier to understand, because it's a linear history. I would say it's significantly easier to understand, especially when you start getting into complicated situations with merges
Jeff Terrell: But the thing that rebates requires and that people object to about re basis that race involves rewriting history.
Jeff Terrell: And a lot of people say you should never rewrite history that's a bad idea. History is what happened. You can't change the past, and they're right, but it's just it comes down to a difference of perspective.
Jeff Terrell: I thought about this a fair bit and I think that there are two sort of philosophical perspectives that people have about using get
Jeff Terrell: One group who would say you should never rewrite history would say that get is a record of what actually happened.
Jeff Terrell: And that's fine you can totally use it that way. And that's fine to treat it that way.
Jeff Terrell: Another group would say that get is a history with an understanding of what actual history is history is an order telling of the past.
Jeff Terrell: History is not a straight record of the past. It's an order to telling of the past that emphasizes certain things and D emphasizes other things, and maybe follows a particular person or thread.
Jeff Terrell: And tells things in a logical way sometimes it's actually telling a story in a way that's out of order from how it actually happened.
Jeff Terrell: In order to pull related concepts together and then it'll go back in time to go back to something else. But the idea is that this is an order telling of what happened and I prefer the latter perspective.
Jeff Terrell: I prefer to think of it as history and if I'm telling a history of what happened then I'm okay with rewriting history because I'm writing a history right history needs an author.
Jeff Terrell: Somebody wrote that book that historical book talking about what happened and that's that's the author putting their perspective on things.
Jeff Terrell: So, so I'm okay with that. And I draw an analogy here to when you are writing code, it's rarely the case that you write it more often than you read it.
Jeff Terrell: It can happen sometimes. But most of the time you're going to read it a lot more often than you'll write it, even if it's not just your especially if it's not just you.
Jeff Terrell: Working on the code base, if it's your teammates working on the code base, they're probably going to have to read the code, you are as well.
Jeff Terrell: And so when we're talking about code we want to spend some time and clean things up and make it nice make it more legible make it more readable so that
Jeff Terrell: We can optimize for the fact that code is read a lot more than it's written and in the same way get histories tend to be read more than they're written
Jeff Terrell: You write each commit once, but you might read it multiple times. I mean technically replay could write your commit for you. But that's more of an automated process. So you don't. It's not really writing a new commit
Jeff Terrell: But I think it's worthwhile to get this right. When you're writing and make it a nice clean telling of your history so that you have a legible. History
Jeff Terrell: Later on in that can reap some benefits that will see later, as we talk about ways to leverage history to understand what happened. I'll talk about that later in this lecture.
Jeff Terrell: So yeah rebasing is harder, but I think it's worth it because
Jeff Terrell: It's just yes history is read more often and it's written and we should optimize for that so
Jeff Terrell: So I prefer a base for that reason Rebus can give you some nice readable linear histories
Jeff Terrell: You can even do some fine grained edits to your history, you can reward commit messages that are in the past, you can reorder commit messages.
Jeff Terrell: These are possible with what's called an interactive re base, which is the dash I switch to re base.
Jeff Terrell: I wish that I could show you that I don't really have time to you right now, but I do have a relatively targeted video on YouTube that perhaps I should link you to the shows how to do that.
Jeff Terrell: You can check out if you're curious.
Jeff Terrell: And then linear histories have other benefits will see an example of that later on when we talk about get bisect
Jeff Terrell: However, there's one big caution to doing rebasing or any sort of history rewriting
Jeff Terrell: Which is you should not replace commits that exists outside your repository, and that people may have based work on I'm stealing the straight from the pro get book.
Jeff Terrell: So it will talk about ways to honor that constraint, because it would be a bad idea to make to rewrite history that other people may be relying on
Jeff Terrell: But there are still clean ways to do that.
Jeff Terrell: And we'll talk about that with the advanced collaborative recipe.
Jeff Terrell: I remember the problem with the basic collaborative recipe is that
Jeff Terrell: The intervening teammate push issue, we can solve that with merge with our strategies either merging or a base, but there are some good ways to sort of work around this problem to where we don't. It's not as much of a problem for us.
Jeff Terrell: In general, I recommend a collaborative recipe called trunk based development.
Jeff Terrell: The way this works is that there is a single long lived branch, which is called the trunk and typically this would be named master. Although, as some students pointed out last time.
Jeff Terrell: It's like GitHub is going to try to move that to Maine in the future, or maybe get itself is I had a nice time I looked at that article.
Jeff Terrell: But Trump is to either kind of has to be a long lived branch, there has to be at least one because presumably development is going to be ongoing for more than a week at a time.
Jeff Terrell: If your entire project starts and finishes within a week. Okay, maybe it's not a very long lived branch. But even so, most projects are going to live longer than a week.
Jeff Terrell: So we'll call that branch, the trunk and the way that trunk based development works is that that's the only long have to branch in your entire repo.
Jeff Terrell: And in my opinion, long, long live branches are from the trunk are a bad idea. There are cases, especially if you're dealing with backwards compatibility where you might need them.
Jeff Terrell: But in general, you should try to avoid them as much as possible.
Jeff Terrell: It's basically just avoid a lot of complexity.
Jeff Terrell: So here's how the advanced collaborative recipe works when you start a new feature branch from master and ideally you should fetch your pole before you branch so that you're branching from the latest commit that you could
Jeff Terrell: And we call that branch that you created a feature branch and you could name it after your feature.
Jeff Terrell: Maybe you know you're using cello and you're using card numbers on it, you could say feature dash 123 if the card number that you're working on is 123 or maybe you'll name it like Feature. Feature dash
Jeff Terrell: Fixed Corps bug or something like that. You could you can name it that stuff like that. But the idea is that the branch name the branch is going to be unique to the feature that you're working on.
Jeff Terrell: When you're all done with the future.
Jeff Terrell: You want to merge that feature into master. And so what you want to do is replace a top the latest master and fast forward your master branch to your feature branch.
Jeff Terrell: You could also do a virgin stead. But either way, you're basically going to want to do what we talked about a minute ago with merge strategies either rebate or merge to
Jeff Terrell: Put the latest code. Put your new commits into origin master or well into master into local master and then after you do that you want to push local master up to origin.
Jeff Terrell: Finally, if you do not have continuous deployment enabled. You will need to deploy the latest master from origin.
Jeff Terrell: If you come across the term get hub flow that's very similar to trunk based development. I think there's just a technicality or two that's different between these two and this is very different. In fact, trunk based development is largely a reaction to get flow cash flow is
Jeff Terrell: I think it comes from, like, maybe 2011 or something and it was a popular way. Well, here's an interesting way. I think a lot of people started to use it.
Jeff Terrell: To manage their repositories. But it turns out that it's just a lot more complicated than you need. For most projects. This is where you have multiple long Lyft branches.
Jeff Terrell: So if you're curious about that. Feel free to look that up but trunk based development is the thing I I see most people moving to this these days.
Jeff Terrell: Alright, and I guess I could say, once you've merged your code into master, you can remove your feature branch don't need to keep that around.
Jeff Terrell: Okay. So I want to talk about a few topics related to this idea of
Jeff Terrell: The trunk based development kind of some related topics and considerations here.
Jeff Terrell: First of all, trunk based development gives you a pretty good scope for where it's illegal to rewrite history of where it isn't. Remember earlier I said quoting from the pro get book do not replace commits that exist outside your repository, and that people may have based work on
Jeff Terrell: So the and there's important
Jeff Terrell: Basically if you push your commits up on your feature branch up to origins feature branch, which I recommend doing to save a copy of your commits so that you don't lose them. If your computer crashes or something like that.
Jeff Terrell: Those commits do exist outside of your repository, because they exist on origin but people should not and you should not base your features on somebody else's feature.
Jeff Terrell: And other people should not base their features on your feature they should only base their features on master, which is where a step one comes from. You always branch from master. You don't branch from another feature branch.
Jeff Terrell: And so for that reason, you can consider that a feature branches owned by the developer working on that branch.
Jeff Terrell: By default, so maybe you can I mutual consent aside that this isn't the case. But it by default, a feature branch should be considered as owned by the developer working on that branch.
Jeff Terrell: Feature branches are intended to be short lived. I didn't think to mention that a minute ago. But the idea is you start a feature work on it till it's done and then push it up and that feature branch goes away. It's a femoral
Jeff Terrell: You might do three of these in an hour three feature branches in an hour. If you're that fast and the features of that small or it might be a few days. Hopefully not a few weeks, but
Jeff Terrell: The feature branches are intended to be pretty shortly. I've done a femoral
Jeff Terrell: Okay, so after you create a feature branch. I do recommend pushing to origin feature branch to avoid losing your commits in case of a computer failure, maybe also you want to share commits between multiple computers. This will be a way to do that.
Jeff Terrell: And you should feel free to do whatever history rewriting you want to do on your feature branch.
Jeff Terrell: To one of the things I do recommend doing that. I'll talk more about when I get to continuous integration is rebates a top latest master frequently
Jeff Terrell: That's a, that's a type of rewriting history and you should feel free to do that on your branch, even though you've pushed it up to origin.
Jeff Terrell: That's okay because you're only this is still sort of owned by you, the origin feature branch.
Jeff Terrell: Or I should say the remote feature branch, but no def should rewrite history for a master or for another dev branch except by mutual consent.
Jeff Terrell: Right. Maybe you need to help a teammate out who got stuck on some get issue and you need to rewrite their branch.
Jeff Terrell: That's fine, but presumably you're in contact with them and you can agree that, okay, I'm going to make this history altering command and you should just reset your state to my branch to my version of your branches history when I'm done.
Jeff Terrell: And history is shared. You know, people may have based work on master and so you definitely don't want to rewrite history there.
Jeff Terrell: Okay. Questions about this.
Jeff Terrell: Okay.
Jeff Terrell: Optional aspect of both trunk based development, but really, any, any sort of collaboration workflow that you have is a code review.
Jeff Terrell: code reviews are not an opportunity to shame your teammates, or to feel good about yourself, or how terrible the code that your teammate row is and had lousy a program where they are or something like that. That's not the idea
Jeff Terrell: The idea is to share knowledge among a team both about programming in general, maybe there are some tips and techniques for programming that you can share or you can learn by reading others code.
Jeff Terrell: But also it's a way to share knowledge about this code based on this project, in particular, you know, maybe your team and is working on a feature that
Jeff Terrell: You haven't really thought about but it'd be nice for you to know how it works, because in case you have to fix a bug or basic feature on now and
Jeff Terrell: So it's a good way to share knowledge.
Jeff Terrell: Remember, if you do code reviews that her Roku review apps, assuming you are deploying it back into her Roku are really nice because they let you see that proposed code in action.
Jeff Terrell: Okay, I recommend that you rebate before opening a pull request or question be kind of a mechanism for doing a code review on GitHub get lab calls the same idea and merge request but same difference
Jeff Terrell: And if you're a base. First, that means that the code that your reviewer is reviewing is more up to date than it would be otherwise.
Jeff Terrell: My pro tip here and this, this is something that can
Jeff Terrell: Help your reviewer, it can impress your reviewer with your skills of get and also just make life easier for your reviewer, if you
Jeff Terrell: Use fine grained single purpose commits before review so that what they're viewing is a series of small commits that are each single purpose. And then after your review before you merge. You can squash them together into a single commit. That's what squashing means
Jeff Terrell: squashing can be nice for your linear history, instead of having 20 little bitty commits, you could have
Jeff Terrell: A single big commit per feature. And that turns out to be more convenient. A lot of times for trying to understand what actually happened in the history of a repo.
Jeff Terrell: We'll see that a little bit later when we talk about leveraging history.
Jeff Terrell: The way that you squashes with an interactive rebates. I mentioned that earlier. But that's read base dash i
Jeff Terrell: One thing I forgot to mention here, I talked about
Jeff Terrell: Maybe rebasing a top latest master, stuff like that. A good
Jeff Terrell: command to use for this would be get push whenever you've finished rebasing and you need to tell the the remote feature branch that you have the latest version of the code and that history is no longer correct
Jeff Terrell: I should have talked about this more detail, but this would be the command to use would be get push dash dash force dash with dash lease.
Jeff Terrell: This is a little bit different than a get pushed force push dash dash force get pushed dash dash force is not as safe because it's going to overwrite what's on the remote unilaterally.
Jeff Terrell: But get pushed force with lease is going to only overwrite the history
Jeff Terrell: If you knew about all of the commits that you're overriding
Jeff Terrell: Locally, in other words, if you have all of the local sorry if you have all of the the remote state locally. You knew about all the commits that are going to be lost, whenever you do a force with lease.
Jeff Terrell: Push force with these than the force with we succeeds. If there happened new commits pushed to that branch, since you last
Jeff Terrell: Fetch the in the state than the force with least will fail. So that's a subtlety, but it's usually in the habit. There's hardly ever any reason to do a push dash dash force, you should always do a push, push for so if lease.
Jeff Terrell: Okay. Also if you squash your local feature branch will be different than your or your remote feature branch. And so that would be another case in which you would you have rewritten history and you will need to do a push force with lease.
Jeff Terrell: Okay, once subtlety about merging it when you're ready to merge your feature branch into master.
Jeff Terrell: It's a good idea to test your re based branch before pushing
Jeff Terrell: Especially if there's a conflict, while rebasing but even if there wasn't. It could be that your code on your feature branch passes all the tests and works. But then when you re base something about the interaction between the history that you
Jeff Terrell: Brought into
Jeff Terrell: your history and your new code, maybe something interacts weirdly, and there's a failure. So it's good to catch those before you actually push them up to the remote branch.
Jeff Terrell: Especially when you before you push it before you merge it into master and push master.
Jeff Terrell: There. Here's some tips. I'm not going to do this in much detail. It's kind of a subtle thing. But if you're not careful with the order of operations when you are merging a feature branch into master.
Jeff Terrell: Especially if you're squashing you can end up with a pull request that's marked as closed instead of merged.
Jeff Terrell: As though you had rejected the change when in fact you actually accepted it. So these steps will help you do things in the right order. So the cab won't be confused and think that you
Jeff Terrell: Actually just rejected the changes.
Jeff Terrell: I'm going to leave that there for reference. I don't think we need to walk through it.
Jeff Terrell: I'm eager to get to these other tips.
Jeff Terrell: Alright so continuous integration. The key idea here, which is similar, actually, in principle to the idea of trunk based development where we try to
Jeff Terrell: Minimize long left branches. The idea of continuous integration, continuous integration is that the longer the time gap is the more painful, the reconciliation processes.
Jeff Terrell: We actually saw this and deployment. Remember, we tried to minimize three gaps with the 12 factor app, the time gap, the personnel gap and
Jeff Terrell: I think the code gap or the environment gap or something.
Jeff Terrell: But basically longer the time gap here between the two diverging histories that you're trying to merge.
Jeff Terrell: The less each person who wrote one of these histories is going to remember about what the intent was and what sort of changes are allowable, that kind of stuff. So the sooner you catch this and reconcile the history, the easier it's going to be for everybody.
Jeff Terrell: And this is the case, regardless of whether you use merge or re base.
Jeff Terrell: So the idea of continuous integration is that you should merge or rebates often not just as a final step in fact continuous integration would suggest that you are continuously keeping everything integrated
Jeff Terrell: So keep your feature branch integrated with the trunk and the case of trunk based development CI is a broader concept and just trunk based development but but that's the application for trunk based development.
Jeff Terrell: So you could have a feature branch that you're in the, in the middle of and it's lasting for several days because you haven't finished the feature yet.
Jeff Terrell: You can actually just replace every day before you start work. Just keep it up to date and if there is an issue you can catch it sooner rather than later.
Jeff Terrell: Maybe your teammate push something up and you can ask them, okay, what, what did you actually change here because I have a conflict and work with them while it's still fresh on their mind.
Jeff Terrell: Some people will set up. This is probably a good idea for continuous integration to set up a server that integrates with origin, like a hub for example.
Jeff Terrell: And runs tests for you whenever it new commits get pushed to origin. There's lots of free services out there for public repos, if your, if your code. It can be public.
Jeff Terrell: Ci works great with CD continuous deployment and arguably, it is a prerequisite for continuous deployment.
Jeff Terrell: I recommend continuous deployment. I guess I really, really didn't talk about it anywhere else, but I love the idea of
Jeff Terrell: Having a completely automated pipeline for actually deploying things. So we saw an example of how that could work when we talked about her Roku and if you can do that. I, I suggest doing it. It's a really nice way to go really, really low friction for actually doing deployments.
Jeff Terrell: Okay, we're into our grab bag of tricks here.
Jeff Terrell: And I'm going to try to get through cash happen a lot, actually. I might not have time to get through it all before. We need to start our quiz, but we'll see how far we get
Jeff Terrell: stashing. So let's say you're beginning to work for the day and you're in the middle of work for your future grants, you're not at a committed point you have some stuff in your tree that's work in progress, but you haven't really
Jeff Terrell: You're not ready to actually call that a commit yet, you can actually stash all of your local changes.
Jeff Terrell: Using this gets dash command.
Jeff Terrell: And that captures your local changes that you've made since the last commit stole them away and restores your working tree to a clean state at the basically the state of the last commit
Jeff Terrell: And then you can come back and restore all of your stash changes later. So the idea if you wanted to integrate but your tree is dirty is to say stash and do whatever changes you need to do like integrate or rebates or whatever. And then you pop your stash you'd say get stash pop
Jeff Terrell: So that's a useful tool to have in your toolbox.
Jeff Terrell: Okay, this is pretty important. This might be the most important thing
Jeff Terrell: Of all of the the sort of tips and suggestions I have understanding how to leverage history.
Jeff Terrell: Kind of makes get a lot more useful and also exposes some of the reasons why I've recommended with things the way that I have
Jeff Terrell: But here are some tips and tricks to actually leverage history in your repository.
Jeff Terrell: Remember our code base is like a database database of code. And so you can do some fairly sophisticated queries of the code in your code base and understand where things that we're at and how they changed.
Jeff Terrell: So simple example would be, you can look at just the commits that affected a particular file by saying get log file.
Jeff Terrell: There's actually a lot of things you can do with it. Log. You can only print commits from certain authors.
Jeff Terrell: You could only print commits who's messages match a given string if you you were like, I know I touched the problem later.
Jeff Terrell: I can just search all the commit messages for province later. And I'll figure out which combat. I'm actually looking for
Jeff Terrell: Or you can match you can print commits only the ones, who's deaf smashes certain string. So maybe province is not even in the commit message, but if you look in the diff output. You can see that the variable name province later actually was changed in a given diff.
Jeff Terrell: So that's useful to know as well. Look at the get locked man page for more info on that.
Jeff Terrell: Getting blame is a useful tool.
Jeff Terrell: The sort of joke of blame the reason is comp claim is that if you see an error or a bug on a certain line of code get blamed can tell you who presumably introduced that bug and who to blame for it.
Jeff Terrell: So it's a bit of a tongue in cheek name. But the idea is actually really useful. You see a line by line output and with each line. You see, which commit was the most recent one to touch that line of code.
Jeff Terrell: So that's pretty useful to go deeper on a given file to see maybe this function was contributed by a certain in a certain command by certain person, you can look up the information for that commit
Jeff Terrell: Which I guess I didn't give you the command to do that but that would just be get show commit
Jeff Terrell: Anyway, so that's pretty useful. You can use get show commit colon file to see the version of file at the given commit and that works, not just with commit addresses, but also with refs. So you could say get show master colon source slash food JS.
Jeff Terrell: So that's pretty useful. You could also diff from there if is a command line tool that will give you output of how two things differ.
Jeff Terrell: Dash means standard input, which is the output of this command piped into diff.
Jeff Terrell: So basically saying what's changed from commit to now.
Jeff Terrell: Or again, commit could be some other RAF as well. You can refer to, for example, like the third parent commit. You could add three carats to the end of head or at as a shortcut for head.
Jeff Terrell: Or you can do till the three or actually three you can see get rough parse for full details and these compose just fine. So you could take it. Show you know activity three colon slash slash food at J. S. If you wanted to
Jeff Terrell: Alright. So the key idea here is like leverage your history.
Jeff Terrell: But history is only as useful as you make it
Jeff Terrell: And for that reason, you should spend some time crafting error messages and making them really useful. Think about commit messages as email messages to your teammates, or maybe to a future future developer in this code base.
Jeff Terrell: First line can be like the subject line of your email.
Jeff Terrell: I recommend imperative tense for this, as though it's a command mistress reads better. And ideally, this will be fairly short less than or equal to 50 characters.
Jeff Terrell: And there's a blank line and then the email body so include you know right write an email right paragraphs right lists. It's especially valuable to include
Jeff Terrell: Information about what alternatives, did you consider or why did you go with a particular approach.
Jeff Terrell: You don't necessarily have to duplicate everything that's in a travel card. For example, but you could, and even apart from a travel card, you could just have that they're saying like
Jeff Terrell: I looked at three different libraries for date parsing and this one didn't work because of that I tried this, when this happened and then this one was when I went with which just worked with when I tested having that all in the commit message is super valuable.
Jeff Terrell: And they're those commit this commit messages are attached to a particular commit, which is really useful to see, you know, this applies to this code.
Jeff Terrell: But also they don't get in the way of editing code. It's not just noise in your source files but they're still there on demand. If anybody wants to go look.
Jeff Terrell: Alright, I've got a couple of resources for you about merge conflicts, basically if get can't automatically merge two histories that have diverged.
Jeff Terrell: You have to do it. You have to tell get how to how to resolve that merge conflict.
Jeff Terrell: This is true regardless of whether you use merge or rebates, you'll run into a conflict under the exact same situations, regardless of your merge strategy.
Jeff Terrell: Just a couple of good reads from the pro get book. If you're interested in that, but the best tip that I can give you right now is just to think carefully about what emerged conflict actually is.
Jeff Terrell: And we go back to your get L output. For example, in order to better understand what the output you see means and what the choices that you can make here are
Jeff Terrell: All right.
Jeff Terrell: bisecting I'm glad I had time to get to this, this was one of my favorite topics. And this is one of the reasons why I like re basis, better than verges even though that can be a little bit harder to wrap your head around.
Jeff Terrell: If you encounter a bug that you don't think you caused first stash or dirty changes and test your belief to say, okay, get this bug exists. Before I started editing since the last commit
Jeff Terrell: If it does, and you have several comments unique to your feature branch. Go back to master when you first branched off of master to create your future and see if the commit or see if the body is still exists there.
Jeff Terrell: If it does, you can go to something old, or maybe head till the 20 meaning the 20th parent commit and see if the bugs still exists there. And at some point, you're going to get to a committed that does not have to bug.
Jeff Terrell: Where everything was working. Once you identify that working commit. You have your bounds of this commit worked at this command didn't. Maybe there's 50 commits in between.
Jeff Terrell: Get bisect will do a binary search on that list of 50 commits. You remember binary search. It's having at each step. And so it's very efficient and to get to the part to identify which commit actually caused the bug, which can I introduced it
Jeff Terrell: Basically it at each step, it'll check out a commit somewhere midway between its bounds and ask you is this bad or good. And whether you tell it bad or good. It'll, you know, refine from there and pretty quickly it can tell you exactly which commit is the offending on
Jeff Terrell: This is a good reason to have linear history, you don't have a linear history get bisect can still work, but it can be harder to understand what happens and you can run into some weird things
Jeff Terrell: Okay.
Jeff Terrell: Public Key authentication. I recommend setting that up.
Jeff Terrell: ref flog deep magic but it's actually not that hard to understand.
Jeff Terrell: Others other tips.
Jeff Terrell: Good chapter about reset if that's confusing and appropriate book.
Jeff Terrell: Magic is a get porcelain. That is so good. Am I compel you to switch to an ancient texts editor, namely Emacs. I used all the time. It's amazing. Very keyboard driven interface to get
Jeff Terrell: So it's really cool.
Jeff Terrell: If you have a nice porcelain, I get front end. Try your hand a selective commits and interactive re basis. It's kind of fun to get in the flow doing that.
Jeff Terrell: One other tip if you're experimenting with your local get repo try creating a branch with your pre experimentation state to avoid losing it.
Jeff Terrell: You're going to be messing around with commits and branches and stuff like that, just check out a new branch called 10 or safe point or something like that and do whatever you need to do and you don't have to worry about losing anything.
Jeff Terrell: Okay, with that we're out of time. I want to give you 15 minutes I said give you just slightly less than that, but
Jeff Terrell: I mean, you will have 15 minutes for your quiz.
Jeff Terrell: And I was trying to
Jeff Terrell: Kind of got live logged out of sekai so I have to re login to enable this quiz.
Jeff Terrell: You will have 15 minutes from the time you start the test or quiz to take it and I was just trying to get this in so that you could take it during class time I didn't quite get done in time, but
Jeff Terrell: You can use any resources that you want, apart from other people use the slides posted online. Use the book.
Jeff Terrell: And once you start taking it, you live 15 minutes and you are good to go. So I think if you go to sekai, you should be able to
Jeff Terrell: pull that up. I will stay on here muted to answer any questions that come up on the zoom group chat. I will also be checking piazza. If you want to post their so I'll be here at least until, let's say, four o'clock and you have until 415 at the latest to
Jeff Terrell: Turn this in
Jeff Terrell: Okay.