Jeff Terrell: Working on projects and getting really good clickable prototypes together and things like that, so it sounds like many of you are off to a good start.
Jeff Terrell: that's great.
Jeff Terrell: Today we're going to pick up where we left off with gifts.
Jeff Terrell: And this will be the only other time that all spend time talking about gifts.
Jeff Terrell: will move on to other things later, we also have a quiz three today.
Jeff Terrell: So keep that in mind will reserve some time at the end of class for quiz three.
Jeff Terrell: And then, before we get back into get I had just a couple of miscellaneous tips that don't really fit into get or.
Jeff Terrell: Anything but I figured we're relatively timely and we're talking about so first of all.
Jeff Terrell: One of the things I really like about this class in the way it's set up is that I get to learn, not only from all of you, when you give your tech talks sometimes you teach me about a technology I don't have much experience and or maybe haven't even heard of before which is pretty cool.
Jeff Terrell: But I also get to learn from mentors.
Jeff Terrell: And you know there's so many different technologies out there and so i'm always learning about new things, something that I learned about from mentor def doshi the mentor for team em.
Jeff Terrell: was something that might be helpful to y'all for your architecture diagrams which are due on Monday.
Jeff Terrell: So I thought I would pass this along, just in case you're in the market for such tips I maybe you already have this assignment finished and, if so, you can tune out for this, but.
Jeff Terrell: But if not if you're still kind of struggling to wrap your head around exactly what the diagram is going to look like this was helpful to me, this is the sea for model for visualizing software architecture.
Jeff Terrell: So this is just a way to think about an architecture diagram and talks about four different layers of.
Jeff Terrell: of concepts and talking about relationships between those concepts in terms of those four layers was, I think it can be kind of a helpful model.
Jeff Terrell: I don't expect that you'll be able to read.
Jeff Terrell: The details on this image, but the gist of it is that level one is kind of the highest level, like the 10,000 foot overview.
Jeff Terrell: And it's talking about how your APP is going to connect with other things.
Jeff Terrell: Level two containers is talking about like it's kind of zooming in on one of the pieces of the Level one diagram and giving a diagram for that piece, as you zoom into it, and so this is talking about the.
Jeff Terrell: I might have it wrong.
Jeff Terrell: I just learned about this, so my have it wrong but anyway it's you know zooming in one level of detail and then zoom in one more level of detail, and you can get down to the actual components within one of your systems.
Jeff Terrell: And you can even go further and talk about code I don't think any one of you will want to do that, for your architecture diagram assignment but anyway that's the sea for model, and there is a.
Jeff Terrell: tool.
Jeff Terrell: kind of a little mini language for actually creating diagrams like this just from text.
Jeff Terrell: This is structure Iser calm i've got this link from the slides, but you specify your your concepts and their relationships.
Jeff Terrell: In whatever level of detail that you want, and then you specify your views and it'll just generate these images for you so anyway, if you're in the market, maybe that'll be helpful.
Jeff Terrell: To pass that along.
Jeff Terrell: The other tip I had was mentor tips, I was surprised i'm a little bit disappointed, but it's okay that nobody shared any mentor tips with me.
Jeff Terrell: I guess none of you.
Jeff Terrell: Maybe just slipped your mind, or maybe you didn't have any mentor tips to share so i'm going to share some of my own.
Jeff Terrell: and hopefully that'll be worthwhile and it I get it, you know this wasn't required it's i'm not i'm not upsetting anybody, but.
Jeff Terrell: But I do think like it can be helpful to talk about different ways of engaging mentors to help y'all get the most value from your mentor meetings that you can can get I think this is a potentially like a pretty big important relationship that you can have professionally so.
Jeff Terrell: I just want that to be all that can be.
Jeff Terrell: So a couple of tips for today, I might share more tips and future lectures, as I think about them.
Jeff Terrell: Today, think about I mean if you're interviewing or maybe you've interviewed recently, or maybe you're planning to interview in the future, whether for an internship or I think for many of you for a full time job after graduation.
Jeff Terrell: You know your mentor has been through that process, most likely if they've landed a full time job.
Jeff Terrell: And might have some tips for how they landed their job or what their interview process was like and how many stages, or whatever, so they might be a useful resource to ask about.
Jeff Terrell: about that and the sort of subtext here is that you don't have to stick within the confines of just your project in your mentor meetings you know these are people that you can learn from more broadly just based on their professional experience, so thank you so that.
Jeff Terrell: that's that it might be kind to your teammates before you go off on a big tangent to check with them first like hey would it be alright with you, if we talked about this as well during our mentor meetings and sets their time to but.
Jeff Terrell: We have you know feel free to be creative with that and find ways to learn from your mentor.
Jeff Terrell: My other tip is to cultivate a habit of capturing questions and ideas of topics to discuss with your mentor somewhere, as they occur to you.
Jeff Terrell: And you know you might be in the middle of some code and realize oh I should probably ask my mentor about this one thing it's just this thought that flits across your mind.
Jeff Terrell: write it down somewhere have a notes file open or something like that, and then just cultivate the habit of doing that, when those thoughts occur to you and then remembering to open up that notes file whenever you're actually in a mentor meeting.
Jeff Terrell: That will really help.
Jeff Terrell: get some value from those meetings.
Jeff Terrell: Okay, so now, I want to just review the rebasing stuff I got some feedback, I appreciate your feedback on a takeaway questions, a number of you said that yeah I didn't completely understand rebasing.
Jeff Terrell: I think some of you kind of already understood rebasing before the lecture and you had no problems following along, but for those of you, for whom rebasing was new.
Jeff Terrell: I think I was moving kind of fast, I only actually explained what was happening once, and so it makes sense that you'd be confused by that, so I want to just spend a little bit more time refresh that.
Jeff Terrell: Because that's something that we're going to build on, when we talk about our advanced collaborative recipe which is the one that i'll actually recommend that y'all use if you, you know don't have other preferences for your get collaboration.
Jeff Terrell: So, remember, we talked about how history diverges somebody some teammate maybe pushes a commit to origin main and, meanwhile, you have a commit and both of those commits are based on a common ancestor.
Jeff Terrell: And there might even be more than one commit here, you might have three commits of your own and there might be seven new commits on origin main that you didn't know about and the histories have diverged you know more than one commit away.
Jeff Terrell: But in any case, you have a divergent history, and if you do just emerge.
Jeff Terrell: Then you would be getting.
Jeff Terrell: you'd be getting a new merge commit.
Jeff Terrell: that combines the the history is together sort of converge to those two divergent histories this commit seven six would be a.
Jeff Terrell: It wouldn't really have any changes of its own, but the important fact would be that it has to ancestors.
Jeff Terrell: To parent commits nine seven and two one.
Jeff Terrell: And that means your history isn't linear.
Jeff Terrell: And that means you have five commits instead of four.
Jeff Terrell: If you do a re base.
Jeff Terrell: Then what happens is, and this is where i'll explain the mechanism of rebasing again what happens is if you're on.
Jeff Terrell: Let me see here.
Jeff Terrell: yeah I didn't I didn't fully explain rebasing from origin main but anyway, if you're doing every base.
Jeff Terrell: The idea is that you will.
Jeff Terrell: rewind this commit to one that's the one that's unique to your branch.
Jeff Terrell: And you're going to rewind it all the way back into segments.
Jeff Terrell: This you're going to rewind this this fork this branch all the way back to the common ancestor the nearest common ancestor which is called the merge merge base.
Jeff Terrell: And then you're going to go down the other path of origin main.
Jeff Terrell: get to whatever origin man is currently at and then you're going to replay whatever commits you rewind in reverse order like a stack.
Jeff Terrell: So we can see if we compare these two, we have a D for committed both we never touched the default whenever we did a race, we have an f6 in both.
Jeff Terrell: The next one after f6 is actually origin main and so you can see, these two commits have actually reversed their position.
Jeff Terrell: It might be that to one happened chronologically before nine seven but because we're rewriting and replaying it it's now happening logically after.
Jeff Terrell: nine seven.
Jeff Terrell: And this commit here, for he corresponds with this commit to one on the left hand side it's the same set of changes, but it has a different address because.
Jeff Terrell: Its parent committed different right the parent committed, for he.
Jeff Terrell: Is nine seven.
Jeff Terrell: The parent committed to one is f6.
Jeff Terrell: So that's why the address actually changed but that's, the only thing that changed in this commit everything else is the same.
Jeff Terrell: And now you have a nice linear history and, as I said before.
Jeff Terrell: I prefer rebasing it, there is a bit of a learning curve to understand what it's doing.
Jeff Terrell: You have to have a little bit of discipline about what you do i'll talk about what kinds of discipline, you should have and what sort of things are no knows when it comes to rebasing.
Jeff Terrell: But if you get in the habit of doing it it produces these nice understandable histories.
Jeff Terrell: And that has long term dividends, not only for you and your teammates but also any future developers on the project, so I like doing that, for the same reason I like refactoring code make things readable in the future.
Jeff Terrell: Questions about this example.
Jeff Terrell: Okay.
Jeff Terrell: I thought it might be worthwhile to just see that in a graphical way.
Jeff Terrell: So this is a from the get book it's free online same kind of thing histories of diverge and if we want to re.
Jeff Terrell: Re base see, for, if you want to read base experiment on top of master, then what happens is, we have to rewind see for to get back to see to.
Jeff Terrell: We advanced to see three.
Jeff Terrell: And then we replace the four on top of C three.
Jeff Terrell: And we're left with a new committee for prime which is effectively the same, but just has a different address because, as a different parent commit and then we have a linear history, and then we can do a fast forward merge of master.
Jeff Terrell: We can tell master hey merging experiment and master can do that without creating emerged combat because it's just a fast forward merge it just updates the.
Jeff Terrell: The ref to point to see for prime instead of C three.
Jeff Terrell: that's what fast forwarding means.
Jeff Terrell: question about this example.
Jeff Terrell: OK.
Jeff Terrell: So, now that we've covered rebasing and hopefully everybody understands rebasing at this point.
Jeff Terrell: I want to talk about the advanced collaborative recipe.
Jeff Terrell: And like I said, this is actually the one that I would recommend you use.
Jeff Terrell: In your project if you don't have other preferences, if you have other preferences that's totally fine i'm just trying to give you sort of my opinions on this so that.
Jeff Terrell: Those of you who don't really have an opinion formed about how to collaborate with good effectively can just borrow my my opinions and hopefully hit the ground running.
Jeff Terrell: So America meditation is the same there's actually a lot of people out there professionals who have the same recommendation and this this This approach has a name and the name is trunk based development or tbd.
Jeff Terrell: So if you I linked to a page that talks more about trunk based development but that's actually a term you can look up online and learn more about.
Jeff Terrell: The idea here is that there's only one.
Jeff Terrell: Long lived branch.
Jeff Terrell: And everything else sort of branches off of that long lift branch and is a short term branch that long left branches, called the trunk everything is branching off of the trunk.
Jeff Terrell: trunk trunk is typically going to be named main or master.
Jeff Terrell: master used to be the default branch name for get repositories I think the new default is main so that's i'm using main in the slides, but you can substitute master for any there anything there.
Jeff Terrell: And let me point out here that.
Jeff Terrell: Long lived branches you definitely want to minimize the number of long left branches.
Jeff Terrell: Because, if you have long live branches What that means is that you need to do some maintenance on those branches and potentially emerge new things in those branches.
Jeff Terrell: And if you've got more than one of those that can be pretty tricky to keep track of and keep everything sort of up to date.
Jeff Terrell: And I think a key sort of design principle of trunk based development as a process is to say let's minimize the number of long lived branches, you have to have one.
Jeff Terrell: Right that's going to represent the main line of development for your project doesn't really make sense to have zero long term branches, if you have development happening over a long period of time.
Jeff Terrell: But if you have one you don't actually need more and so trunk based development is giving a set of processes about.
Jeff Terrell: Using short term feature branches basically.
Jeff Terrell: So the basic approach here is, first of all, when you start a new feature that's when you create a new branch.
Jeff Terrell: This is called a feature branch, meaning that it's a branch specific for one feature.
Jeff Terrell: And you want to branch off of main the trunk.
Jeff Terrell: And before you branch you want to check out the latest you know fetch the latest changes for your trunk so that you are branching from the latest man, not a stale man.
Jeff Terrell: And then you do your development add whatever commits you need to add to actually implement your feature.
Jeff Terrell: Step three is optional i'll talk about code reviews in a minute, but you can open a pull request to get a code review from a teammate.
Jeff Terrell: Whenever you're ready to merge whether that's after a code review or not.
Jeff Terrell: You would fetch the latest changes to main.
Jeff Terrell: rebates your branch on top of those changes.
Jeff Terrell: And then switch to maine and fast forward merger really based commits.
Jeff Terrell: met again just like we've seen with rebasing That gives you a linear history.
Jeff Terrell: alternately for step four you could do a merge if you'd rather do that.
Jeff Terrell: I think that's still considered trunk based development.
Jeff Terrell: could be wrong about that, but I think it is.
Jeff Terrell: Step five you push main to origin, this is typically not going to be rejected, remember, it would be rejected if there wasn't intervening teammate push intervening teammate commit.
Jeff Terrell: But typically it's not going to be rejected in this case.
Jeff Terrell: And then finally step six is, if you have if if it's not happening automatically due to a continuous deployment pipeline, then you would manually deploy the latest main commit to work from origin.
Jeff Terrell: So if you don't have a process try that one out and see if you like it.
Jeff Terrell: might take some practice before you get used to it and feel like this is natural, but at least there you have the information there.
Jeff Terrell: This is almost exactly the same as a github flow model if you ever see that and the github flow model is very different from the get flow model to get flow model is not one I recommend.
Jeff Terrell: It has multiple long lived branches and it's kind of difficult to deal with, but the github flow model is is is fine i'm i'm in favor of that as well.
Jeff Terrell: Questions about this recipe.
Jeff Terrell: Okay.
Jeff Terrell: All right, I glossed over one thing.
Jeff Terrell: And i'm going to ask a poll about this, why.
Jeff Terrell: Why is this typically not rejected this push and step five.
Jeff Terrell: let's go to poll everywhere.
Jeff Terrell: polivy.com slash Jeff terrell.
Jeff Terrell: All right, why is push typically not rejected and trunk based development because the remote side merge is a fast forward merge.
Jeff Terrell: Yes, this is true.
Jeff Terrell: That is that is an aspect of it.
Jeff Terrell: Be pushes are rarely rejected any way that's not a feature of trunk based development that is actually true also.
Jeff Terrell: If you're doing merging as your merge strategy, instead of rebasing you're not usually going to have any problem with pushes being rejected, either because you're only going to be a pending to the history you're never going to be rewriting history.
Jeff Terrell: and see is incorrect.
Jeff Terrell: They are not often rejected D is actually correct also does have a very small window to push a commit up between when you fetch and when you push.
Jeff Terrell: Because when you're ready to merge you fetch your rebates and you push and it, it can happen that quick if you know what you're doing and so there's a very small window where it def could actually push something up in between and interrupt that that pushing process.
Jeff Terrell: So yeah three out of four of these are actually correct.
Jeff Terrell: Okay questions about this.
Jeff Terrell: Okay.
Jeff Terrell: Now I do need to talk about if i'm going to be recommending that you do rebasing I need to talk about when it's okay to rebasing when it's not.
Jeff Terrell: and, fundamentally, this is just about you know agreeing with your teammates about when to do this, and when not to but a pretty standard operating procedure for rebasing if you're on a team that does rebasing.
Jeff Terrell: Is that you do not replace commence.
Jeff Terrell: That exists outside your repository and that people may have based work on.
Jeff Terrell: Those are the two conditions if both are true, you should not replace that commit.
Jeff Terrell: I recommend considering, and this is probably going to be pretty natural for you, whenever you create a feature branch consider that that's yours and any feature branch that you didn't create is not yours.
Jeff Terrell: So, in other words the feature branch whatever feature branches owned by the developer that created that branch.
Jeff Terrell: I do recommend pushing your commits that you're working on for that future up to origin, up to the same name to remote branch on origin, so that'd be like origin slash feature xyz.
Jeff Terrell: And this helps you, you know, in case, your hard drive fails, or something like that that means there's a backup copy.
Jeff Terrell: Also, if you have more than one computer that you're doing development work on you can more easily share commits between your computers.
Jeff Terrell: And in general yeah you should feel free to re base a top the latest main we'll talk more about continuous integration in a second.
Jeff Terrell: or otherwise rewrite history, however, you like on that branch because.
Jeff Terrell: Other people should not have based work on your feature branch.
Jeff Terrell: And trunk based development you're not branching off of a feature branch you're always branching from trunk.
Jeff Terrell: Okay, so um so yeah you should feel free to do rebasing a top latest main or doing whatever history of your writing you want to as long as you're on a feature branch that you own.
Jeff Terrell: But you should not rewrite history in any way, including rebasing for main or any devops branch except by mutual consent.
Jeff Terrell: So if you get together with your teammates you say hey we this this actually happened sometimes turns out, we pushed a commit that includes some sensitive credentials in it.
Jeff Terrell: And yeah we added a new commit that removed that but that's still visible in history of somebody was going to.
Jeff Terrell: scroll through our get log or whatever they'd be able to see that there were sensitive critical credentials and repo.
Jeff Terrell: So we actually need to edit the history to expunge that information from the history and so everybody stop what you're doing don't don't branch don't commit don't do anything let's re rewrite the history and then everybody can reset their.
Jeff Terrell: Local instances two three written history.
Jeff Terrell: So that would be by mutual consent, a case where you would actually change one of these commits.
Jeff Terrell: An important technique for doing this kind of work is the force with lease option to get push.
Jeff Terrell: So if you have a remote branch like origin feature xyz and let's say that you own the future xyz branch.
Jeff Terrell: you're going to be rebasing a top man and that's going to be changing the history of what is on feature xyz.
Jeff Terrell: And when you want to push that up to origin origin is going to say it's going to reject your push.
Jeff Terrell: Why.
Jeff Terrell: Because there are commits that you would clobber if you actually successfully pushed right it's a safety measure saying, if I accept those changes.
Jeff Terrell: it's going to remove this history that I have.
Jeff Terrell: And so, for your safety i'm not gonna let you do that.
Jeff Terrell: What you can do is you can say get pushed dash dash force.
Jeff Terrell: And then you will clobber whatever's there so that's one way to do it, however, a safer way is to say force with lease the difference between force and force with lease is that force is going to unconditionally club or whatever history, the origin has.
Jeff Terrell: been forced with Lisa is only going to clobber histories, that you already knew about.
Jeff Terrell: And so you're not going to accidentally cloud or something that you didn't know about.
Jeff Terrell: So if you get if if you get rejected push from a force with least you would need to say get fetch origin, so that you know about all of the commits and you need to make sure that in fact you do intend to clobber everything there and then you could say, for us, with least again.
Jeff Terrell: This makes sense we good we're tracking.
Jeff Terrell: Okay.
Jeff Terrell: questions.
Jeff Terrell: Okay.
Jeff Terrell: All right, I said we talked about code reviews.
Jeff Terrell: This is not an opportunity to shame your teammates don't do that be nice.
Jeff Terrell: Now you might not do code reviews at all that's a choice it's up to you, you can discuss them on your team, whether you think it's worth it or not.
Jeff Terrell: But if you do it don't don't shame your teammates don't rub their faces and mistakes that they made or or laugh at how immature their coding style is or something like that.
Jeff Terrell: i'm good reasons to do code reviews, one would be that you can share your knowledge among the team, so you worked on some feature and now other people get to learn from your approach learn about the design that you took.
Jeff Terrell: Maybe you've got one person working on the front end one person working on the back end something like that, and if the front end person is reviewing the backend.
Jeff Terrell: Code and the back end pull request, then the front end person can learn a thing or two about the back end and might be able to step in and a pinch, maybe the backend person gets coated you know, God forbid and there's a.
Jeff Terrell: important feature that is is due and needs to happen and maybe the front end person because of this knowledge sharing will be able to sort of maybe somewhat clumsy delay, but at least be able to get the job done so knowledge sharing can be a good thing.
Jeff Terrell: Not that you might be sharing knowledge, not just about your project, but maybe in general, maybe you might get exposed to different ways of solving problems and you've seen before.
Jeff Terrell: be kind of eye opening and mind expanding to see how different people approach problems and yeah you can learn from that.
Jeff Terrell: If you're doing code reviews and pull requests on github remember that her roku review Apps if you're using her roku are a pretty useful thing let's just let you see lets you see that code animated in a system.
Jeff Terrell: see what it looks like and how it behaves.
Jeff Terrell: One thing so mostly i've just been talking about get features, but this is one case where i'm actually talking about a github or get lab feature pull requests are not a thing in command line get this is only a feature of github or get lab.
Jeff Terrell: Good i've actually calls a merge requests, but same thing.
Jeff Terrell: I recommend rebasing before opening the pull request, so that you kind of have the latest changes.
Jeff Terrell: And something if you're going to do a code review that can make it easier, is to use fine grained single purpose commits.
Jeff Terrell: A lot of small commits are going to make it easier to review code, especially if you have a lot of changes like that are just.
Jeff Terrell: noisy in terms of a diff but not actually meaningful like if you're indentations all messed up in one file and you go and fix it, I would say, let that be one commit all by itself, and your commit message could say like white space changes only.
Jeff Terrell: You can ignore this I guess unless you're using Python.
Jeff Terrell: Also, if you want to even you know if you don't like fine grained single purpose commits in your ultimate sort of history of the project and the get log on the on the trunk.
Jeff Terrell: One thing you can do that i'm not going to talk much about is you can squash multiple commits down into one.
Jeff Terrell: This is a another type of history or rewriting and I linked to an article that talks more about that.
Jeff Terrell: But you can do that, and that can actually be beneficial if you want to have a longer sort of more thorough commit message.
Jeff Terrell: i'll talk about commit messages in a bit, but I guess squashing can can can make sense in some projects, if you want to do that.
Jeff Terrell: One just tip about that, if you are going to do a pull request and if you're doing a rebasing style then github isn't going to be able to know whether something is merged unless it can compare that everything in this pull request all these commits are now in the main line.
Jeff Terrell: And so, if you re base the feature branch and don't tell github about those changes, but you just merge them directly into your main line and push that up and get hub is going to say well and it looks like the these commits are not merged yet.
Jeff Terrell: So forget how to properly mark the pull request has merged you've got to push the re based branch up as well.
Jeff Terrell: Any questions about code reviews anything so far.
Okay.
Jeff Terrell: All right now i'm just going to kind of get into a lot of just random tips about using gets maybe you've seen some of these if you had an internship or something like that, but maybe not.
Jeff Terrell: Continuous integration, this is actually something anybody heard this term before continuous integration or ci.
Jeff Terrell: If you few hands okay.
Jeff Terrell: This is one that I find kind of like devops that.
Jeff Terrell: I think a lot of people don't actually use it, the way it was originally intended.
Jeff Terrell: And it took me a while to understand even I mean, I think that was part of my confusion, I heard the term continuous integration.
Jeff Terrell: And I was like I don't understand what that why it's called that, like the actual name of it didn't make sense knows, because I I didn't know, there was kind of a meaning that made more sense that people have kind of straight away from but.
Jeff Terrell: The idea of continuous integration is that the longer the time gap, the more painful the reconciliation.
Jeff Terrell: So any sort of whether you're doing merge or rebates any sort of merge strategy.
Jeff Terrell: it's going to be a more painful reconciliation if it's been a long time since you since anybody developed on one of those two branches.
Jeff Terrell: And so the idea behind continuous integration, and this is where the term actually makes sense is to merge or rebates often you want to integrate often continuously even.
Jeff Terrell: Every day you sit down to start doing development for the day and you're on your feature branch, and you, you go ahead and.
Jeff Terrell: rebates that feature branch when you get started, you just keep keep doing that all the time don't just wait until the end to do it, and if you do that, then you are shrinking that time gap.
Jeff Terrell: At that point, whatever you're using if you run into some sort of a conflict.
Jeff Terrell: Your changes are going to be at the top of your mind, relatively speaking, and whatever branches are in the main line that are conflicting or at the top of somebody else's mind, and so the reconciliation process is a lot less painful.
Jeff Terrell: So basically, the idea is that you're keeping your feature branch integrated with the trunk.
Jeff Terrell: And this is where the term has been kind of.
Jeff Terrell: I don't know, maybe i'm missing something, but to me it seems like it's misused people talk about ci servers.
Jeff Terrell: And anymore, in practice, what this means is that you have a server that is connected to your you know your github repo to your origin.
Jeff Terrell: or get lab or whatever and anytime it sees a new commit on that repo it's going to run your test suite on that code.
Jeff Terrell: And that's really valuable I actually think that's a great idea, but I don't really think that's continuous integration.
Jeff Terrell: I think if it was actually doing your rebasing for you, maybe that would be continuous integration, but as far as I know, no ci server is going to be doing that.
Jeff Terrell: So I actually do recommend using a ci server.
Jeff Terrell: Even with the caveat that I don't think it's named well, and there are a lot of ci services out there that are actually free for public repos to use.
Jeff Terrell: One that I like is circle ci.
Jeff Terrell: And I would say ci is actually really useful pairing with continuous deployment, if you have continuous deployment setup remember that that means.
Jeff Terrell: anytime I commit hits your main line and the tests pass that's the ci step then it's automatically deployed where it needs to go that's the CD step.
Jeff Terrell: And if you're doing CD without ci.
Jeff Terrell: That could be a little bit risky might be deploying something broken.
Jeff Terrell: Questions about continuous integration.
Jeff Terrell: Okay.
Jeff Terrell: Now, one of the things you'll run into if you actually try to do continuous integration is that you can't really integrate if you have 30 changes in your tree.
Jeff Terrell: And a quick solution of that would be stash if you ever heard of that basically you just stash all of your dirty changes and then you get a clean working tree.
Jeff Terrell: Then you can do whatever integration, you need to can switch branches, if you need to re base do whatever you need, and then you can pop those changes from the stash get them get them back from the stash so it's kind of like a lightweight commit.
Jeff Terrell: That doesn't need a message, but just to kind of a temporary storage area for for changes and it works like a stack that's why it's called pop you can actually have multiple stashes and you can pop the top one off and then go from there.
Jeff Terrell: Get is actually we talked about how good is effectively a code base it's like a database for code.
Jeff Terrell: And if you think about you know what is, what can you do with the database, you can query it right.
Jeff Terrell: Most databases are going to give you a pretty rich set of facilities for doing sometimes pretty complex queries on the data that's in the database.
Jeff Terrell: You know, with sql if you've taken for 21 or 521, then you can do joins you can do where clauses and select certain fields and all kinds of stuff you can aggregate things and group things and anyway there's a lot of stuff you can do with sql.
Jeff Terrell: No sql databases, you can do a lot of stuff will get is actually kind of similar in a lot of ways, you can do kind of Center rich querying of the history of code in your repo.
Jeff Terrell: This is a code base you kind of have to learn how to do it and so i'm going to give you a few techniques for actually doing that here, but.
Jeff Terrell: You know, if you think about it as a code base, it makes sense that there would be some facilities like this and get.
Jeff Terrell: an easy one, is that you can filter your log to see only commits that affect a certain file.
Jeff Terrell: So if you know you have a file that you're curious you know what's changed on that file, you can say get logged and give it that file name and see only the commits that the fact that.
Jeff Terrell: there's a ton of options for get log there's a lot of things you can do some examples would be only print commits from certain authors.
Jeff Terrell: Only print committees messages match a given string or who's dis match a certain string there's a lot of other things you can do with blog that would basically be filtering.
Jeff Terrell: filtering of commits but it's not just that that you can do you can also do.
Jeff Terrell: Breaking down a file line by line.
Jeff Terrell: To see who touched that line, most recently.
Jeff Terrell: And what was the commit that touched that line, most recently and that's called a get blame.
Jeff Terrell: i'll show an example of what that output looks like in just a minute, but that can be a pretty useful way to just.
Jeff Terrell: get a view you know you've got some section of code in a file and you're thinking that I don't understand.
Jeff Terrell: Where that's coming from that seems different or I wonder if there's a bug there something like that you can actually pull up and get blame.
Jeff Terrell: For that section of your file and look to see okay is maybe somebody made that change, more recently, than the rest of the file, maybe it's a recent addition or something like that.
Jeff Terrell: You can also pretty easily look at the version of a particular file at a given commit.
Jeff Terrell: And this works with rafts to you can say on whatever branch colon file name and see the version of that file at that rough.
Jeff Terrell: And then you could even define it with the current file.
Jeff Terrell: Get show commit colon file pipe that two diff comparing standard input against the file and that would tell you how has this file changed.
Jeff Terrell: Since this commit.
Jeff Terrell: There are other ways there's like a syntax for referring to different commits relative to a rough.
Jeff Terrell: A rough forehead so, for example, the the third parent command the parents of the parents of the parents, you would say head carrot carrot carrot.
Jeff Terrell: Or you could say had till the three.
Jeff Terrell: Those refer to the parents of the parents of the parents have had.
Jeff Terrell: And because had can be abbreviated with at these two things are equivalent as well at carrot carrot carrot or at till the three.
Jeff Terrell: Get REV parse is going to tell you, if you look at the man page for that it's going to tell you.
Jeff Terrell: All the details there man page meaning manual page.
Jeff Terrell: I forgot to say with blame it's not just the most recent commit you can also do a blame relative to a certain commit So you can see.
Jeff Terrell: relative to this come out what, what are the file look like and what were the most the lines that touch those are sorry what were the key message touched each line before then.
Jeff Terrell: And here's an example of what get blamed looks like.
Jeff Terrell: So you've got your actual source code over here.
Jeff Terrell: I think this is the line number.
Jeff Terrell: This is the timestamp of the commit when it touched that line, the author.
Jeff Terrell: And the commit ID.
Jeff Terrell: So this is pretty neat pretty neat to see who touched the lines of a file and when.
Jeff Terrell: This is an example from that get book.
Jeff Terrell: And it's an it's an example with a line range given.
Jeff Terrell: Actually don't know what that means that might be like the very first commit.
Jeff Terrell: Interesting okay.
Jeff Terrell: Okay let's do another poll.
Jeff Terrell: Now you're paying attention.
Jeff Terrell: Just checking.
Jeff Terrell: I was gonna say this one manually choice see here, you can manually close a pull request, but i'm pretty sure it's not going to market as merged all right it'll show up as closed, and if it detects that it's merged, it will automatically close it.
Jeff Terrell: But if you manually close it that then github is not going to show up show show that it has been merged.
Jeff Terrell: Questions about this.
Jeff Terrell: I tried this this morning, just to make sure that's up to date with what github does.
Jeff Terrell: Okay.
Jeff Terrell: All right, let's talk about commit messages now if you're looking at and something also going back to here, ideally it'd be nice to say okay.
Jeff Terrell: Now that i've looked at looking at get blame I can look at this committee and say what is the message for this, and hopefully there's some useful information that will tell me what was happening at this point in time, what motivated these changes, you know what's going on.
Jeff Terrell: So history is really only as useful as you make it.
Jeff Terrell: And if you take some care with your commit messages, this can actually be super valuable.
Jeff Terrell: misinterpreted layer of your repo this is, these are messages to humans.
Jeff Terrell: So I recommend thinking of commit messages as email messages to your teammates.
Jeff Terrell: are potentially even to a future developer on this project.
Jeff Terrell: Again, imagine if you could go and read the email message that Chang anquan wrote to describe what this change is and why it's important and maybe even what alternatives, they considered.
Jeff Terrell: So the first line of a commit message should be what you might think of as a subject line of an email.
Jeff Terrell: And a tip for this pro tip would be used imperative tense like as a command and there are reasons for this, but basically it makes for a kind of more readable.
Jeff Terrell: Get message summary.
Jeff Terrell: So using paired up tents, ideally, keep it less than or equal to 50 characters and that's the subject line and then have a blank line and then there's what you can think of as the email body.
Jeff Terrell: and for this I mean it's a plain text format, but but go wild I mean I will often have multiple paragraphs i'll often have bulleted lists like you know hyphen list item one hyphen item to hyphen item three that kind of thing.
Jeff Terrell: I do all that kind of stuff in my commit messages just whatever is readable, these are basically plain text emails to future developers on this project.
Jeff Terrell: Something that would otherwise be pretty lost or maybe even if you captured in a trailer card, it would still be pretty hard to find later for future developers is what else did you try.
Jeff Terrell: Maybe somebody comes along and they say man, you really should have used this so and so widget for this thing instead of this other thing.
Jeff Terrell: That you end up ended up using and if they were able to go in your commit message and see that, actually, you can you try using that, and the reason didn't work was this.
Jeff Terrell: that's really important information that makes perfect sense to have an A commit message, but it's really hard to get to and really hard to share that information with future developers otherwise.
Jeff Terrell: And I actually think this is a much more valuable approach than adding comments to your code because they're attached to a snapshot not just a file.
Jeff Terrell: Right they're attached to a specific version and a specific point in time of that file and they're not in the way when you're looking at the source code.
Jeff Terrell: I think comments or you know some sort of documentation or description of what you're thinking is really valuable, but having them in the source code where it's.
Jeff Terrell: getting in the way of you actually looking at the code I I don't personally think that's just as helpful I think it's really nice to have them and get commit messages.
Jeff Terrell: So this is my plug for spending a little bit of time to write good commit messages.
Jeff Terrell: What you're learning in this class remember is.
Jeff Terrell: To some extent APP development but, to a large extent collaboration.
Jeff Terrell: learning how to collaborate effectively, and I think this is one of the ways to do that.
Jeff Terrell: spend some time writing well crafted messages.
Jeff Terrell: Right let's talk about merge conflicts.
Jeff Terrell: This is something that can happen to people, maybe you're editing the same file and maybe even the same line of a file.
Jeff Terrell: And in that case, get is going to throw up its hands and say I don't know how to reconcile these changes.
Jeff Terrell: So maybe you're in the middle of a emerge and you can't merge because there's a conflict or this can happen in a race to same underlying problem.
Jeff Terrell: Now if you're editing different files there's no problem, and if you're editing different sections of the same file get a smart enough to understand that these are different sections and it can automatically merge those.
Jeff Terrell: But otherwise you need to do it.
Jeff Terrell: there's a couple of sections in the appropriate book that are useful reading to understand what emerged conflict is.
Jeff Terrell: not going to really go there now, but that can be some useful background and I don't really have anything that can help you, you know depends very much on what.
Jeff Terrell: Which to commence are conflicting right so there's not a lot of general advice I can give you, I would just say in general um think carefully about what these different changes were.
Jeff Terrell: And, and you have to really understand what emerged conflict is for that to make sense.
Jeff Terrell: So.
Jeff Terrell: yeah and it's not a fun part of get this is, this is probably.
Jeff Terrell: The most stress inducing part of using it is dealing with merge conflicts, because you that's when you really get worried about making a mistake and throwing things away that clobbering other changes or whatever so.
Jeff Terrell: So I think you know if you run into that situation Another thing I would say, besides understanding what's happening here reading, you know those sections of the book is.
Jeff Terrell: Get with your teammate you know if you figure out Mike committed conflicting with my teammates conflict.
Jeff Terrell: My teammates commit get with that teammate and say hey there's emerged commit or merge conflicts can we pair program and figure out what we're supposed to do here if you're doing continuous integration.
Jeff Terrell: The commit will be at top of mind for both of you, and it should be relatively easy to remember oh yeah I was doing it this way, I made this change because whatever whatever.
Jeff Terrell: Yes, I really do need that piece of it, but you need that piece so let's figure out how to merge those two things together.
Jeff Terrell: Questions about merge conflicts.
Jeff Terrell: Anybody run into this yet running the merge conflicts, either in this project, or some other project.
Jeff Terrell: yeah a few okay yeah.
Jeff Terrell: Also, all the time, and definitely okay.
Jeff Terrell: Remember that this is something that APP that people might be able to help you with as well if you really don't know where to go and nobody on your team knows how to do it.
Jeff Terrell: bisecting This is where things I think it really, really cool and get.
Jeff Terrell: I trust you on the reading the debugging book.
Jeff Terrell: And one of the rules is to divide and conquer.
Jeff Terrell: And that's effectively what bisecting is.
Jeff Terrell: And what it does with the by section.
Jeff Terrell: If you encounter a bug that you don't think you caused.
Jeff Terrell: tests that belief stash or dirty changes and see if you're right.
Jeff Terrell: If you are not encountering that bug anymore, then maybe you did cause it actually and so it's something to do with the changes that you made.
Jeff Terrell: But if you stash your dirty changes and then you don't see or you do see the bug then yeah you didn't change it, you didn't cause that but it didn't have to do with your changes.
Jeff Terrell: And, of course, you might have several commits that are unique to your feature branch, and so you might want to you know after your stash your dirty changes, you might want to switch back over to me and see if you still see the bug.
Jeff Terrell: But anyway, at some point.
Jeff Terrell: You want to figure out okay when did this bug get introduced I mean you could want one strategy here, of course, is to just say.
Jeff Terrell: i'm going to figure this bug out and fix it and you can dig in and understand what's happening and the debugging book hopefully can help you with that, but it can be really helpful.
Jeff Terrell: to pinpoint exactly which commit.
Jeff Terrell: introduced that bug.
Jeff Terrell: You can say it was this commit there were only 20 lines change, and so I know it's one of these 20 lines that made the problem and a lot of times at that point becomes pretty obvious how the bug got introduced and how to fix it.
Jeff Terrell: So, once you verified your belief that you did not cause this bug or at least that it isn't recent, then you want to figure out, you know what you want to basically find a commit old enough that it does not have this bug in it.
Jeff Terrell: That would be your your good commits to start from.
Jeff Terrell: And once you've identified a start a good commit and a bad commit.
Jeff Terrell: Then you can do it by section on that and do.
Jeff Terrell: A binary search on that space, if you remember binary search from.
Jeff Terrell: i'm not sure which class you learn that in but.
Jeff Terrell: Surely you all have seen it before do binary search that's an order login operation, so if you're dealing with 1000 commits you figure that out in 10 steps.
Jeff Terrell: Pretty powerful stuff.
Jeff Terrell: So at each point bisect is going to jump to sort of the middle of the exist, the current range i'm just going to say hey is this one good or bad.
Jeff Terrell: And you tell it good or you tell it bad and it's going to chop off half of the search space half of the remaining search space and iterate is this one good or bad Okay, and eventually you bought them out, you get to the end and it says Okay, this is your commit.
Jeff Terrell: So it's pretty cool.
Jeff Terrell: You can also script it so, for example, you maybe you have a test suite and maybe you're trying to figure out.
Jeff Terrell: The tests got broken at some point i'm not sure which commit actually started breaking them, so you could just say.
Jeff Terrell: You know hey get run bisect and here's the command to run to tell whether the given committed good or bad.
Jeff Terrell: it'll just go off and do it, and every time you know it'll it'll check out a committal to run the tests and if it tests failed it'll say Okay, that was a bad commit and just automatically iterate itself until it bottoms out and finds the the answer.
Jeff Terrell: And this is also a good reason to do rebasing instead of merging so that you can have that linear history because it's a lot harder to figure out what in the world bisect is doing, if you have this complicated web of commits rather than if you just have a single line of commits.
Jeff Terrell: So here's an example i'm kind of aligning various details that some get will tell you, but.
Jeff Terrell: You can say hey get started by section.
Jeff Terrell: And the current committed bad good bisect bad.
Jeff Terrell: And the commit at version 1.0 was good.
Jeff Terrell: This is actually a raft of some sort of might actually be a tag.
Jeff Terrell: And you're telling get yeah the the commit that this points to was good.
Jeff Terrell: And so maybe let's say that gets says okay.
Jeff Terrell: we've got six revisions left to test.
Jeff Terrell: And so it checks out commit at the midway point.
Jeff Terrell: And you test it out and you figure out that this commit is actually good so you say get bisect good.
Jeff Terrell: we're good on this one, and so get says Okay, let me check out another one, and so, then it says there's three revisions left to test it's it's having the search space at each step, just like you'd expect from an order login operation.
Jeff Terrell: So now there's three commits left to check you tell it that this one's bad so so it's just one left to check.
Jeff Terrell: You say okay that one's good and then it says that is the first bad commit you've pinpointed it to super cool it tells you exactly what to commit broke, whatever it is that that got broken.
Jeff Terrell: So that's by section any questions about that pretty powerful technique.
Jeff Terrell: Anybody used to buy section before.
Jeff Terrell: know that this is new to everybody anybody online.
Jeff Terrell: Now anybody heard of get bisect before one.
Jeff Terrell: Just one Okay, so this is this is new stuff good.
Jeff Terrell: alright.
Jeff Terrell: here's the blog all right, this is kind of one of the more advanced tips.
Jeff Terrell: A lot of people are really scared of the ref log if they've even heard of it, because some you know get wizard they got into some weird state with the repo and they asked the local get expert.
Jeff Terrell: hey, what can I do about that and the good expert gave them this command it had to do with the ref log or sort of poking around in the ref log and they're like ooh I don't know what that is I look scary it's actually not that bad.
Jeff Terrell: All it is, is that get maintains a log of which commit a ref points do, and in this case a raft including had.
Jeff Terrell: So, every time any of these refs get updated, including head.
Jeff Terrell: Get is going to keep a log of.
Jeff Terrell: What was the last thing that that ref pointed to what was the last commit that appointed to.
Jeff Terrell: And so you can actually fix some pretty big mistakes this way.
Jeff Terrell: You can look at just to get ref log which would show you the red flag for head or if you give it a ref it'll.
Jeff Terrell: show the red flag for that ref.
Jeff Terrell: And now you can be the person that's people come to you and say hey I got into some trouble here I don't know what I did with my repo and you can you can figure it out.
Jeff Terrell: So, for example.
Jeff Terrell: Let me see here i'll actually actually do this one, I think I have enough time.
Jeff Terrell: So I have i'm.
Jeff Terrell: Sorry, I have an alias.
Jeff Terrell: je SS get status.
Jeff Terrell: And let's say I accidentally.
Jeff Terrell: wiped out my last two commits.
Jeff Terrell: they're gone.
Jeff Terrell: My my master is now to commits behind where it was and those top two commits are gone from master I mean it turns out, in this case I could re emerge origin master and i'd be fine but let's pretend I didn't have an orange and remotes or I didn't know that they were on origin master.
Jeff Terrell: I would just be out of luck, I get status says.
Jeff Terrell: This is where it tells me I actually can fast forward my local branch origin master but again pretend that doesn't that didn't work.
Jeff Terrell: And I just lost two commits that I thought I didn't need, but then I realized oh dang I needed those I just throw away work that I I needed I don't have to go back and do that.
Jeff Terrell: I can say get flogged.
Jeff Terrell: And it tells me.
Jeff Terrell: i'm.
Jeff Terrell: This top line here I can't quite see it all on the screen here but.
Jeff Terrell: It tells me what happened it's reset it's moving to the grandparent commit and then the commit that it was at before then was three zero EB.
Jeff Terrell: So.
Jeff Terrell: If I was at three zero EB, can I do this nope.
Jeff Terrell: 0740 wait no sorry the one before that 3168363.
Jeff Terrell: Okay, now I got back to where I was.
Jeff Terrell: So I threw those commits away, they were gone, but the ref logs still knew about him.
Jeff Terrell: Alright, so that's an example of the red flag actually saving the day.
Jeff Terrell: Okay, also, if you want there's a nifty repo here get flight rules.
Jeff Terrell: it's just an example of like different things you might want to do and get and how to do it.
Jeff Terrell: What did I just commit or I made the wrong thing and a commit message and just basically had it back out of various things so that could potentially be useful.
Jeff Terrell: right questions about the ref log.
Jeff Terrell: Anybody seen the blog before.
Jeff Terrell: one.
Jeff Terrell: Okay, one person online as well.
Jeff Terrell: Okay sounds like it might be new to most of you, though, so good.
Jeff Terrell: glad i'm glad i'm not.
Jeff Terrell: there's at least some new things, even for experience to get users good.
Jeff Terrell: Okay.
Jeff Terrell: i'll close out with just some other tips here.
Jeff Terrell: do get command dash H to get a quick synopsis of command options, if you forget and then dash dash help is going to give you the full manual page for that command.
Jeff Terrell: If get reset confuses you reset demystified section in the program book is a good treatment of it.
Jeff Terrell: magic is the get porcelain that I really like it's actually built into emacs or it's not built in a nice it's a package that you can add to emacs or in my case space Max it's I love it super good very keyboard driven.
Jeff Terrell: I feel like it's it's a really suits me well, at least.
Jeff Terrell: And if you have.
Jeff Terrell: Another porcelain or if you even want to try this on the command line, you can but try your hand, some time at selective commits.
Jeff Terrell: To be, in other words, being able to say, like not just staging an entire file, but just staging a piece, out of a file.
Jeff Terrell: and try your hand to interactive re basis to do something like squashing or or you can actually rearrange the order of commits with an interactive freebase.
Jeff Terrell: Things like that.
Jeff Terrell: If you're experimenting with your local get repo and remember those changes are isolated to your local repo they are not going to affect other developers unless you push.
Jeff Terrell: But if you're experimenting you can always create a branch with your pre experimentation state to avoid losing it.
Jeff Terrell: So you're going to rewrite history, you know you're going to do some stuff, but you can just create a branch, and you know that that's going to save where you were in case you mess something up and want to get back to where you are.
Jeff Terrell: And that's all I got about get i've stopped a little bit early so that we can do quiz three, but any final questions or comments about good that's really all I intend to talk about unless anybody has questions.
Jeff Terrell: Okay we'll switch to quiz three.
Jeff Terrell: When you finish this you can go remember you only have 10 minutes and remember you can use, you know the the notes and the slides and everything online just don't talk to each other.
Jeff Terrell: i'm going to actually stop recording and then i'll open up the quiz.
Jeff Terrell: Oh, actually, I think it might be open, if you go to sekai.
Jeff Terrell: Is it open okay good.