Jeff Terrell: Okay, today we're going to talk about
Jeff Terrell: Get and this will be part one of probably two lectures on get
Jeff Terrell: Yeah, we'll get into it. Alright, so some announcements, first of all, that was polynomial see by effects when I regret that I didn't have time to play the whole thing.
Jeff Terrell: Again, just because I like it. Fun little layered electronic music from the 90s.
Jeff Terrell: One note about I just, I love getting these mentor reports and hearing what y'all talk about in your mentor meetings. It reminds me of where everybody's at. And so the things that maybe I forgot to say in class and I think this is one of them.
Jeff Terrell: You should not have to pay for infrastructure. Alright, so I talked about her Roku last time and Roku is great. One of the reasons I like it is because it has a free tier
Jeff Terrell: And that's great you hopefully you can get by with the free tier of Roku and all the add ons. But some of you maybe have experienced with Google Cloud Platform or AWS or something else as your
Jeff Terrell: And sometimes clients will actually want you to use a particular thing. But you should note that
Jeff Terrell: There's no requirement whatsoever in class that you should have to pay for any of these items of infrastructure. And in fact, most clients.
Jeff Terrell: Are already aware that there may be infrastructure costs and have agreed that they can cover those. So be aware of that. Don't feel pressured to buy anything
Jeff Terrell: And if you feel like you need something that isn't a free option have a conversation with your clients and, you know, remind them that they agreed to pay for that if you're curious whether your client in particular agreed to pay you can always check
Jeff Terrell: I feel like there might have been one or two this time that had said no, but
Jeff Terrell: I think even when I followed up and said, did you really mean you couldn't do this, whatever they said, Well, okay, fine. Yeah, probably could. But anyway, if you look at the application itself for your project that will have the indication of how the answer that question. If there's any doubt.
Jeff Terrell: Time mentions that AWS free tier is also may be useful. He says neato.
Jeff Terrell: But only last 12 months. That is true. That said, there are, it can be a little bit tricky to stay within the free tier limit. So the AWS and if you're not careful, you can end up
Jeff Terrell: incurring costs us a little bit easier to do on something like AWS where everything is such a sliding scale as compared to something like a Roku where there are these tiers of service.
Jeff Terrell: Okay grades are up to date as of 11am this morning. That's
Jeff Terrell: partially why I'm running behind today is because I had a lot of mental reports to catch up on. And finally had time to do that this morning, although maybe I didn't have quite the time that I thought I did. But anyway.
Jeff Terrell: We're getting there. I'm sure some of you feel so much stress about just having too much to do. What else is new. Right.
Jeff Terrell: Um, my original plans forget where to follow more or less what I did last time I taught this course which wants to go in more depth about
Jeff Terrell: What the underlying concepts of get are. And I think there's some really interesting stuff there. Those of you who
Jeff Terrell: for some crazy reason decided to subject yourselves to my class last semester understand a lot of what those details are
Jeff Terrell: And actually implemented a get client from scratch. And so that's pretty cool stuff. I think there's some really neat computer science concepts there.
Jeff Terrell: But I'm not going to talk about it today, because these are the poll results. Most of you are actually pretty comfortable with get or at least fairly comfortable
Jeff Terrell: So there's maybe one person that's not at all comfortable
Jeff Terrell: If a couple of people handful of people that are not very comfortable with get but everybody else is at least a three out of five. In terms of get
Jeff Terrell: If you're one of the people in these bottom two categories here, I guess. Top two categories of not a, you know, less comfortable with get
Jeff Terrell: What I'm going to talk about today. It's kind of covered the foundational concepts. I'm going to cover them fairly briskly.
Jeff Terrell: So hopefully all the information that you actually need is in the lecture. And maybe if you rewatch the recording or something like that, you'll have all that you need.
Jeff Terrell: But there's also remember the get lab or sorry, the app lab, the lab is there to help with all manner of things related to app development, including get
Jeff Terrell: So if you are struggling with get that would be a totally fine thing to bring up in the app lab and say, could you just help me understand how I can use get
Jeff Terrell: Right. So the plan for today.
Jeff Terrell: Generally what my, my main goal is my high level goal for this class, and the next one, as well as to equip you to use get well together as part of a team.
Jeff Terrell: I do intend to cover the foundational concepts, but I'm going to try to move relatively fast in that considering the poll results that most of you maybe understand a lot of these concepts already
Jeff Terrell: I am going to cover my recommendations for how to use get there. There is room for opinions and how you use cat. There are different choices that you can make, especially as a team for how you're going to collaborate
Jeff Terrell: I'm going to include what I recommend from that which I think are there's not really a right answer here, but I have some pretty well considered opinions that hopefully will help you
Jeff Terrell: Right. And then I really don't like the idea that you could just be following a recipe for how to use get without understanding what it means.
Jeff Terrell: And so I'm going to do my best. You know, maybe you understand the basics about the commands that you actually type into the terminal or whatever to actually get work done.
Jeff Terrell: But I want to go into the concepts. I want you to understand at least at a high level, what are what's actually happening with kit and if you understand these concepts you will be much more equipped and successful and effective at using get
Jeff Terrell: But I will also include what the recipes are and maybe a few demos about how to use get for different sorts of topics. So, because that's important too. I'm not just going to do the concepts.
Jeff Terrell: That's the plan for today.
Jeff Terrell: I've been scrambling around trying to get these slides written and they're not even fully written for all these
Jeff Terrell: All these topics in the outline quite yet. So we'll just see how far we get we're going to spill over into next next lecture. Like I said, there's going to be two lectures here.
Jeff Terrell: So yeah, we'll just see how far we go alright so let's start with, I'm going to talk just kind of introduce get a little bit again some of these is basics about what good is and
Jeff Terrell: Then we're going to talk about what the actual foundational concepts are
Jeff Terrell: Then we're going to talk about a basic collaborative recipe that maybe many of you have already seen, or even used up to this point.
Jeff Terrell: But then there are some ways in which this basic strategy can go wrong. And so we'll talk about ways to resolve some of those problems and different strategies for doing merges in particular.
Jeff Terrell: And then we'll have that'll set the stage to talk about a more advanced collaborative recipe and this is what I didn't quite have time to right size for. So if we get that far. I'll just wing it. And we'll see how it goes.
Jeff Terrell: Show you some stuff on the command line on the fly. And then there are a bunch of other topics I'd like to get to. And I'm going to have to look through kind of that grab bag of topics and see what I think is going to be most valuable to you to talk about on Monday.
Jeff Terrell: So that's the outline
Jeff Terrell: So let's talk about what is good and why are we spending our time in class are precious class time for calm 523 talking about get and studying it.
Jeff Terrell: All right, what is get this again is pretty low level foundational stuff get is this is my definition, it is a tool for storing and sharing snapshots of the contents of a directory
Jeff Terrell: And that's a pretty
Jeff Terrell: Deliberate considered definition. I'm going to repeat it, because it's fairly important get is a tool for storing and sharing snapshots of the contents of the directory
Jeff Terrell: Know thing get is not the same thing as GitHub.
Jeff Terrell: A lot of people get this wrong and they talk about
Jeff Terrell: When they say get they really mean getting how they talk about posting their code on get or something like that, GitHub is a hosting service for get
Jeff Terrell: GitHub is a company. All right. And they have a web app that lets you use get and host your code there and some central place.
Jeff Terrell: But it's just a service as a company, it's not get itself. Now there are some nice things about provides, of course, but get itself is a tool. It's a command line tool. All right. So in your command line, you know, your terminal or something like that.
Jeff Terrell: Get is the command that you run when you type GI T enter. All right, that's what it is. There are a lot of different front ends for get these are you get calls these things porcelains
Jeff Terrell: And it kind of distinguishes between the idea of plumbing commands and porcelain commands which is kind of a funny metaphor.
Jeff Terrell: The porcelain commands are the ones that you should know as an end user of get the plumbing commands are a little bit lower level and maybe could be useful if you're a developer of get or if you need to do some advanced stuff.
Jeff Terrell: But anyway, I actually use a porcelain forget all the time. It's called Magic I maybe we'll get a chance to show you that next time in class. It's, it's pretty nice, but
Jeff Terrell: Alright, we're just going to focus on using the command line version of get as the common denominator that you all should have access to some of you are familiar with different front ends and porcelains
Jeff Terrell: I don't want to get into that. For one thing, because not all of you are going to have access to the same front end spitting on your operating system and things like that, things like that for for another thing sometimes these front ends will
Jeff Terrell: Hopefully obscure some of the underlying concepts that kid exposes and what I want to do is show you what those concepts are so that you can see them, and this will reinforce your conceptual knowledge and get which again is intended to
Jeff Terrell: Maybe I didn't say this yet intended to help you just get a mental map of of how this whole thing works.
Jeff Terrell: Okay. So why study get
Jeff Terrell: It is incredibly dominant in industry, nobody there. I've met one person. I'll say I've got one person actually he's a mentor in this class.
Jeff Terrell: Who even knows how to use other tools that can be with it this point if you're using anything other than get is probably one of these last generation tools like Subversion, or maybe even something as old as CVS yeah time mentioned some version.
Jeff Terrell: And these are I think it's fair to say inferior tools so version and CVS are inferior compared to get get has really advanced the state of the art with respects to the general category of this is called version control system.
Jeff Terrell: And so, Calvin mentioned a maybe a particular client for Subversion
Jeff Terrell: Gets far better. It's a far superior technology and it has really taken hold of the industry over the past
Jeff Terrell: I don't know 15 years. I remember first hearing about get when I was a grad student at UNC maybe about 15 years ago.
Jeff Terrell: And it was kind of experimental at that point. I mean, it was, it was established, but it was a little bit off guard. Not many people knew about it or knew how to use it at this point, it's just like, it's everywhere. And if you're still using something old, you are considered a dinosaur.
Jeff Terrell: I actually think there are certain technologies that are not going to go anywhere. Probably for our lifetimes.
Jeff Terrell: Which is kind of crazy to say. Considering how much the field has changed in my lifetime already AND LET ALONE. YOU KNOW, SINCE THE 60s or 70s.
Jeff Terrell: But in the computing field and in the software field. I don't think it is going anywhere, my other two picks for technologies to last into the lifetime of my grandchildren would be
Jeff Terrell: Email and spreadsheets, just for what it's worth.
Jeff Terrell: But actually think it has a lot of staying power. There are some competing tools for the forget. But as far as I can tell.
Jeff Terrell: They don't have any significant advantage over get that would cause people to actually switch from the mainstream at this point.
Jeff Terrell: So I see this sticking around a while so therefore it's worth spending a little bit time learning this tool, learning how to use it. Well, considering I think it's going to be around for a while.
Jeff Terrell: Such it's actually really neat. I think it's a really neat technology.
Jeff Terrell: It's, it's as maybe my students from last semester might tell you there's some neat aspects of it, maybe they would maybe they wouldn't tell you that maybe they would gripe about the terrible assignments. I don't know, but
Jeff Terrell: Anyway, I think it's pretty neat, both at a user level and at a conceptual level for how it works under the hood.
Jeff Terrell: Knowing how to use it can save you lots of headache. And that's really what the purpose of these two lectures is about is teaching you and equipping you with some tools to save us some pain and some headache, especially when you get into
Jeff Terrell: More collaborative work that involves multiple developers working on the same code base.
Jeff Terrell: Also you can win the respect of your peers. All right, when you graduate. Many of you're going to graduate and and move into some software development job.
Jeff Terrell: And would it be neat if you actually understood how to use get and how it works better than some of your professional colleagues.
Jeff Terrell: And this is actually this is possible. Not all developers. In fact, not a whole lot of developers understand get very deeply. So if you spend a little bit of time.
Jeff Terrell: Understanding get and how it works. You could be this sort of go to person for when one of your colleagues.
Jeff Terrell: Runs into some sort of confusing issue with get and you could become known as, like, Hey, you're the good expert so that can be fun. It can be a way to establish credibility early on as a fresh alumni are
Jeff Terrell: So anyway, that's just kind of fun.
Jeff Terrell: Okay. So with that out of the way. Any questions about what it is or why we're spending our time studying it.
Jeff Terrell: Get is good.
Jeff Terrell: Yes. Okay.
Jeff Terrell: No question. So I'll move on to some of the foundational concepts of get and some of the things that you really need to know to understand what in the world could it's doing when you take these various commands in
Jeff Terrell: So we're going to talk about things like repos commits branches remotes pushing and pulling things like that.
Jeff Terrell: I think there's maybe eight concepts that I want to cover here.
Jeff Terrell: So first concept is a repository, and this is the maybe the most basic of concepts that we need to understand to use get repository, often called repo is just a code base, ie a code database to database of code.
Jeff Terrell: Each repo contains code.
Jeff Terrell: That said, I get does not actually need to try to contain code, per se, it can contain other files even binary files or contain it can contain markup files like HTML.
Jeff Terrell: Basically any sort of content get can handle and actually use it for example for the class website. I don't have any code in there.
Jeff Terrell: All I have is HTML and a little bit of CSS and actually I don't have HTML. I have marked down, but it's not code, it's marked up but it's not code.
Jeff Terrell: And get is perfectly happy with that. It doesn't have to be code. But for the purposes of this class, and for talking about get I might refer to the code base, even though technically it could be something a little bit more general than that.
Jeff Terrell: Importantly, each repo has its own history.
Jeff Terrell: So basically, a repo is a place to store some code. But you can also, you also will be storing information about how that code has changed in time.
Jeff Terrell: So as an example, if you go to the code for your project on GitHub, or get lab or wherever it is that you're hosting your, your get code, assuming that you are
Jeff Terrell: That's showing you information from the repo.
Jeff Terrell: From the code base, and all of the data that get as tracking in the code base.
Jeff Terrell: And another example. When you clone something
Jeff Terrell: Your cloning a repo. That is the the thing that you clone your repo.
Jeff Terrell: When you clone a repo, you are storing a repo locally on your hard disk in a directory and that directory is kind of the home of the repository.
Jeff Terrell: If somebody talks about the repo route. That's what they mean is that directory that is the top level directory of that repo.
Jeff Terrell: And I mean you can move that around wherever you want on your hard drive, you can rename the name of that top level directory. It doesn't matter. All that matters is what's inside that directory
Jeff Terrell: And as long as there is a dot get subdirectory within that directory that is a get repo and get is where all the code base data actually lives. And they're just files on your file system, which I think is one of the
Jeff Terrell: One of the genius things about kit is that you don't have to have a server running to use it all it's doing is manipulating files on your hard disk, no matter what command you're running
Jeff Terrell: I mean, it can talk to remotes to. We'll talk about that. But what I mean is, you don't need to have like a database server running in order to use get this is a departure from something like some version where you had to have a server.
Jeff Terrell: Right. Remember my definition of get get is a tool for storing and sharing snapshots of the contents of a directory. And so that would be
Jeff Terrell: This repo root directory that lives on your hard drive.
Jeff Terrell: That's what you're taking snapshots of and sharing, sharing those snapshots.
Jeff Terrell: Okay concept to a commit
Jeff Terrell: As I just now said, Remember my definition of get get is a tool for storing and sharing snapshots of the contents of the directory
Jeff Terrell: For the purposes of this lecture, we will call those snapshots commits. That's the name that we use.
Jeff Terrell: Technically a commit is a little bit different than a snapshot. I'll talk about that in a second, but it's close enough to the same concept. The reason it's different is that snapshots continue or sorry commits contain a snapshot and meta data about that snapshot
Jeff Terrell: As opposed to a tree, which is more sort of properly a snapshot alone.
Jeff Terrell: So the kinds of meta data that a commit is going to contain includes the author was actually a different concept for computer and in some cases you'll have a different author and commit or on a commit
Jeff Terrell: The timestamp and you actually have different timestamps for the authoring date versus the committing date.
Jeff Terrell: The message.
Jeff Terrell: This is what you're typing in whenever you have to create a commit, as well as parents commits
Jeff Terrell: And parent commands are going to link a comment that you create with a parent, so that you can kind of create a linear doesn't have to be linear, but
Jeff Terrell: basically create a history of related commands and how this can that was derived, you can actually have more than one parent commit in a command. We'll talk about what that means later.
Jeff Terrell: commits are addressed by their contents. This is a content addressable system.
Jeff Terrell: And so effectively what you have is that commits are immutable. If you needed to create a new commit with something changed, you would end up with a different address for that commit and so that commit would be stored somewhere differently.
Jeff Terrell: Based on that address and the old address would still be around and that old commit would still be around so that that commit is basically immutable, and the change that you make is resulting in a new commit rather than changing the old one.
Jeff Terrell: So if you've noticed whenever you if you type get committed a command line or maybe with your, your own porcelain, you might create a commit
Jeff Terrell: You have to type in a message right and that committed. It's time stamped with the current timestamp.
Jeff Terrell: And you probably had to initially when you set up your get config and your get client whatever whichever one you're using. You had to say who your
Jeff Terrell: What's your name was, what's your email address was. And so that's included in a committed as well. And it's ran out of your usually your global get configuration.
Jeff Terrell: And then finally we create a combat with get good man or similar command in a different porcelain, you are
Jeff Terrell: The, the front end that you're using whatever that is, is linking that connects to create to the previous comment that it's based on
Jeff Terrell: If you ever noticed I can get have if you're looking at a list of commits or you see a brief summary about a particular commit like the most recent commit
Jeff Terrell: You might notice these like random looking IDs. That's the address. All right, that's the actual it's usually a shorter address like it's an abbreviation of a longer 40 character address, but that's the address of the commit
Jeff Terrell: And it's all based on the contents of what's actually in the commit
Jeff Terrell: Again, the contents of the commit is the metadata that we talked about, as well as the snapshot of the contents of your repo route.
Jeff Terrell: Questions about repositories or commits so far. If not, we'll move on to the next concept.
Okay.
Jeff Terrell: The working tree is actually what's on your heart desk.
Jeff Terrell: And you might hear the term dirty tree and what's meant by that is that you have changed something since the last commit and therefore the, the state of your working tree is considered dirty. In other words, not saved.
Jeff Terrell: It's not pejorative its technical
Jeff Terrell: And get status is always a good go to command to see what you've changed. That is the working tree that's what's actually on your hard disk.
Jeff Terrell: It's not me with any questions you have. Alright concept for is the index. This is another piece of genius that isn't innovation get introduced
Jeff Terrell: compared to something like some version. And I should say, maybe it's not completely fair to attribute all of this to the creators of get they were actually inspired by a sort of Next Generation version control system called bit keeper.
Jeff Terrell: And it turns out that the creators of get are also the creators of Linux they they had such
Jeff Terrell: It's incredible. The, the scale that the Linux kernel development community operates at how many different
Jeff Terrell: Developers, they have in our project. And how many different commits are created per day and it's insane. It's a huge project.
Jeff Terrell: And they were really frustrated with the lack of the state of the art. Many years ago, and so they switched to fit keeper will bookkeeper was proprietary. And so they basically wrote their own bookkeeper
Jeff Terrell: I don't remember. They actually switched a bookkeeper and then changed or if they just saw it keep her and liked it and then wrote their own
Jeff Terrell: Or what. So I think a lot of these concepts actually come from bookkeeper and i don't know i don't know much about the keeper. Other than that, so I don't know exactly what get innovated on
Jeff Terrell: Compared to not and I guess Linus Torvalds was also very influential in the creation of gets and yeah that's part of the legend, I guess of Linux and Linus.
Jeff Terrell: Anyway, getting back to this. This is one of the other innovations of get that I think is really important. Get slash bookkeeper or whatever.
Jeff Terrell: When you say get commit. You are not committing the working tree instead you're committing the index and the index is this staging area that you can use to repair a commit and to specify exactly what is it, it's going to be committed
Jeff Terrell: So version would not let you do that. So version. I'm pretty sure if I remember right, I have used to version in the past.
Jeff Terrell: You had to commit everything that was in your working tree. And so it was difficult to say, Well, I don't want to commit everything I just want to commit
Jeff Terrell: This piece. And so you had to like maybe move some files out of that directory and then do a commitment of files back in. It was a pain, but with kit, because of the index, you get to say exactly what you want to include in the next commit
Jeff Terrell: And you can actually have some pretty fine grained control over what you put in the index and therefore what's included into commit
Jeff Terrell: And because this index exists. You, you have some set of changes in your working tree. Well some of that you put in your index maybe other parts of the changes you just leave in your working tree, but not in the index.
Jeff Terrell: And so you can be moving stuff back and forth between your index and you're working tree.
Jeff Terrell: But still not lose what's actually in your working tree if it's in
Jeff Terrell: Can I say this anyway these are two different concepts, but the, the point is that
Jeff Terrell: If you have a set of changes that you want to make, but you only want to commit part of them. You don't have to lose all the other changes that you don't want to commit. You can just keep them around and you're working tree.
Jeff Terrell: This is exactly what is meant by indirection.
Jeff Terrell: Introducing index to interact between the working tree and to commit. So if you remember that concept from like maybe calm.
Jeff Terrell: Same exact thing that we see in programming is applied here. It's just interaction.
Jeff Terrell: To adjust the index. The most common command that you use is get add to see a list of all of the commands that you can use as well as just a summary of what has actually changed get status is your friend.
Jeff Terrell: So good status is a very common command that you will use a lot if you're actually using it on the command line. Some people abbreviate this define an alias in their command line just to hit enter and they get that's that's alias to get status because it's such a commonly needed command.
Jeff Terrell: Okay, stop me if you have any questions or just jump into the chat.
Jeff Terrell: Concept five branches and reps. These are actually the same thing. If you've heard the term ref all that's meant as a branch.
Jeff Terrell: And branches, you know that if you see the word ref in in a man page or something like that, then what's meant as a branch, branch is kind of the user friendly name for a rough
Jeff Terrell: But it's called a rough because all it does is it refers to a commit
Jeff Terrell: This is effectively the same as a pointer and C or c++
Jeff Terrell: And the only thing that you have for a branch, the only data that you have other than just what commit YOU'RE ACTUALLY POINTING TO is the name that's it branches, just a combination of a name and commit ID that is a commit address
Jeff Terrell: This is actually a pretty important concept to remember and it has some deep implications that are pretty key to really understanding what good is doing.
Jeff Terrell: So,
Jeff Terrell: I'm not sure how to talk about those implications until we get farther down talking about more things. But there's a lot that hinges on this idea that all branches.
Jeff Terrell: Is a pointer to a commit commit are really the core concept here and branches are important. You need branches, but they are built on the idea of commits commits are the core concept.
Jeff Terrell: Branches and graphs are just pointers to them.
Jeff Terrell: Last thing I mentioned get branch is a command that you might use to list all the branches, aka refs in your repo.
Jeff Terrell: You can also do get branch dash a I think it is to list all of the branches, including remote branches, and we'll talk about what we're Mozart in just a minute.
Jeff Terrell: Six important concept to understand in get I believe out of eight is the idea of the head RAF
Jeff Terrell: Ahead ref is a little bit meta, it can refer to a combat like a raft, but it can also refer to another ref normal refs cannot refer to other refs normal rafts referred to commits only, but the headdress can actually refer to a ref
Jeff Terrell: So it's kind of like maybe a meta ref, but then again it doesn't have to refer to the method can refer to it, just to commit
Jeff Terrell: This indicates what is currently checked out, which is to say if it's pointing to a commit, then it's the head is what's indicating what the current sorry I said that wrong if had is pointing to a branch then head is indicating what the notion of the current branch is
Jeff Terrell: And get branch will also hopefully put a little asterisk by the branch that is currently checked out, which is to say the branch that the head ref is pointing to, if it is
Jeff Terrell: As a
Jeff Terrell: An example. This is kind of more of a plumbing command, but you can say get rev parse head.
Jeff Terrell: Which will resolve head into a commit address it will if it's pointing to a raft will look that up and then it will look up whatever come in addresses that graph is pointing to.
Jeff Terrell: Rev par speeds revision parse
Jeff Terrell: Anyway, it's parsing what what had means
Jeff Terrell: I get checkout is the key command to actually change what had is pointing to.
Jeff Terrell: So you can say, you know, get checkout branch name to
Jeff Terrell: Update your head raft to point to a different branch.
Jeff Terrell: You can also get check out and give it a command address. And in this case, you're considered I think it calls this a detached head state, which means that had is not pointing to a ref it's pointing to a commit. And the reason it's considered attached
Jeff Terrell: Is that I guess this next bullet point if had points to a ref then get commit will update that rough
Jeff Terrell: So if you're in detached head state, meaning your hand is pointing to a commit then get committed is not going to make any changes to any of your branches.
Jeff Terrell: Into only going to create a new commit and maybe later you could associate that with the RAF if you wanted to, but you'd have to remember to go and do that.
Jeff Terrell: And that's why I get warns you about being in a detached head state because it's easy to create commits and then just lose track of them.
Jeff Terrell: One interesting thing to know is that get status.
Jeff Terrell: Actually depends not only on the working tree. It also depends on head get status is telling you what has changed since
Jeff Terrell: Whatever had is pointing to whatever the currently checked out commit is. And so it's going to resolve head for you figure out what's in that commit
Jeff Terrell: And do a comparison between the most recent commit ahead is pointing to either directly or indirectly, and the conscience of your current working tree.
Jeff Terrell: So if you went in and you actually changed the I believe it's the docket slash head file is that's where get actually stores this and it's code base.
Jeff Terrell: And that hidden get directory. You can go and literally change this file, and you can have
Jeff Terrell: Get status telling you one thing, and then you go and change had to point to a different branch name or a different commit
Jeff Terrell: And you'll see different output for get status because it's going to be comparing your working tree to something else. So it's kind of a fun thing that you could try
Jeff Terrell: Okay.
Jeff Terrell: Questions so far.
Jeff Terrell: Okay.
Jeff Terrell: Concept seven is a concept of remotes. This is where get leaves the confines of your local computer and can actually start talking with other computers.
Jeff Terrell: All right, you and your teammates, as well as, you know, GitHub, or get lab or wherever else you might be storing the repo each have an instance of the same repo.
Jeff Terrell: And each instance has its own state.
Jeff Terrell: All right, get is effectively a distributed system.
Jeff Terrell: At least if you have multiple instances, each with its own state.
Jeff Terrell: In get a remote is something that you store in your local instance that is a URL pointing to another instance. So each each repo instance has its own
Jeff Terrell: List of remotes and you're not going to be sharing remotes between
Jeff Terrell: remotes between these different instances.
Jeff Terrell: Whenever you clone something get clone you know URL get will automatically add a remote named origin that is that URL that you cloned from
Jeff Terrell: So that's where origin comes from, and that's
Jeff Terrell: That's why origin, a special that's why a lot of times you have that already. When you get started on a repo.
Jeff Terrell: So this is a really key idea.
Jeff Terrell: collaboration works by to use the terminology sharing commits with remotes
Jeff Terrell: And that's important. So I'll say it again collaboration works by sharing commits with remotes. So here we see two of the foundational concepts that we've been talking about. This is what enables collaboration between you and your teammates.
Jeff Terrell: As well as anybody who's using get this is how collaboration works.
Jeff Terrell: All right. Alright, good as decentralize which is actually kind of cool. It does not require an authoritative server or source of truth to do what it's doing.
Jeff Terrell: You can share directly with a teammate. You can bypass get having get lab, you don't actually need to get haven't get lab to use get
Jeff Terrell: Now, what you would need is an ability to talk directly with your teammates computer which can be a pain to set up because you need to get into
Jeff Terrell: Maybe networking and firewalls and host names and domain names and stuff like that, which gets complicated. That's one of the reasons people use GitHub and you know centralized service like that just because it's easier but
Jeff Terrell: Not everybody does that. And in fact, again, the Linux kernel development is really fascinating in this regard because
Jeff Terrell: They do all kinds of distributed stuff they've got different groups working on different categories of the, the overall Linux kernel repo and so they're sharing commits among themselves are sharing comments on mailing lists.
Jeff Terrell: There's, there's all manner of sophisticated stuff that get itself can do because the the kernel developers use it that way. And they don't have mean yeah kernel.org has maybe the official mirror but there's lots of collaboration that happens without touching kernel.org
Jeff Terrell: So anyway, that's kind of a fun case study that you can look up if you're curious.
Jeff Terrell: But remotes are really central concept commits and remotes might even be the most important concepts that you need to understand them get
Jeff Terrell: Questions so far.
Jeff Terrell: Okay.
Jeff Terrell: Alright, next I want to talk about fetching pushing and pulling
Jeff Terrell: These are not actually other concepts as as much. I mean, there are more just ways of interacting with remotes but they're foundational enough that I figured it's worth talking about these particular modes of collaboration or modes of awkward of sharing commits between remotes
Jeff Terrell: Get fetch is maybe the most basic of these all get fetched does is it downloads data from a remote
Jeff Terrell: So you could say get fetch origin and you would get all of the latest data that you that maybe GitHub knows about. If your repo lives it GitHub and you clone from there.
Jeff Terrell: Now the data in this case would be two things commits and graphs.
Jeff Terrell: So you get all of the commits that's GitHub knows about. And you also get the refs AND THESE REFS do not conflict with your current your local Refs, you actually have
Jeff Terrell: A difference between remote rafts and local refs. For example, Master is a local rough but origin slash master is the remote master rough on the origin remote
Jeff Terrell: Alright, so when you fetch, you're getting commits and rafts and those restaurant conflict, you could think of them effectively as being names based to that origin or to that remote
Jeff Terrell: A pool is sort of a superset of fetch and includes a fetch.
Jeff Terrell: But it takes it one step further and it goes ahead and merges new commits from the remote branch into the current branch.
Jeff Terrell: And so for example if you said, Get pull origin master you first would fetch from origin from the origin remote and then you would merge commits from origin slash master and new raft that you fetched.
Jeff Terrell: You would merge those commits into your current branch, maybe you'd have emerged conflicts, maybe there are other things that can happen merging itself can have conflicts and we'll talk about that but effectively a poll is equal to a fetch plus emerge.
Jeff Terrell: Get push is kind of the opposite of
Jeff Terrell: It. Well, it's not exactly the opposite of fetch or pole. It's a little bit different than either one of those, but
Jeff Terrell: It is moving the other direction from fashion pole, it's it's pushing commits to the remote rather than pulling them from the remote. So it's more of an upload and download
Jeff Terrell: The reason it's not quite symmetric with either of those is that it it is actually updating the remote rafts and so you're pushing to a branch and your update updating the rough on the remote to be that new command that you pushed up
Jeff Terrell: So for example, if you say get push origin master.
Jeff Terrell: You will share your current branches commits with the origin remote
Jeff Terrell: And you will update origins master branch to point to your current head commit
Jeff Terrell: All right.
Jeff Terrell: This. This assumes that you're on your local master branch. But, but, yeah. So you have two new commits
Jeff Terrell: You know about but origin doesn't you sent get push origin master, you're going to send those to commits up to origin and you're also going to make sure origins master remote or master RAF
Jeff Terrell: Points to your latest commit rather than the ones who committed more than it put that pointed to before you push
Jeff Terrell: Push can also run into some problems you might have seen probably if you use to get very much. You have seen the idea of a rejected push
Jeff Terrell: Push has rejected when the push branch does not include the remote branches head commit and this is kind of what is meant by a non fast forward merge.
Jeff Terrell: Usually most remotes are set to refuse to accept a push that doesn't involve fast forward merge. We'll talk a little bit more about what that is in a minute.
Jeff Terrell: But what that means is that basically your push can get rejected.
Jeff Terrell: And if for your push, not to be rejected. You have to push
Jeff Terrell: You have to push a commit that includes the remote branches current had in its history.
Jeff Terrell: As a tip.
Jeff Terrell: It's a convenient idea to set an upstream tracking branch for your local branches by adding the dash you option to get push. So instead of just saying let's say you're on your local master branch.
Jeff Terrell: Instead of just saying get push origin master say get pushed dash you origin master. And what that will do is set your local master branch track origin master.
Jeff Terrell: And that's how when you say something like, get status and it says you're ahead of origin master by one commit or gives you some some input like that. That's what it's doing it notices that you're trying to track origin master.
Jeff Terrell: And compares what it knows about origin master to what it knows about your local branch.
Jeff Terrell: That's sad. I mean, I guess one thing to be aware of is that you only have the latest information based on the last time that you fetched. And so if you said, Get status and it says that your to convince ahead of master or of origin master.
Jeff Terrell: That might not actually be up to date. You might be to commit to head and three commits behind and your histories of diverse, we'll talk about what that means in a little bit.
Jeff Terrell: But the fact is that you because you haven't fetch recently, you might be out of date.
Jeff Terrell: Okay, so that's a lot. As I said, there was kind of risk. I'm thinking that most of you who were more comfortable with get have seen a lot of these concepts already
Jeff Terrell: I hope that that wasn't too boring, but that you got some useful information out of that. Or maybe just solidified your understanding of those concepts.
Jeff Terrell: Those of you who were less experienced with getting less comfortable with it. Maybe that was too fast. I'm sorry. I'm trying to kind of have a happy medium here. But if that was too fast, again, feel free to rewatch the lecture or go to the app lab for some some custom help one on one help
Jeff Terrell: Those of you who have tuned out because you know all this stuff already.
Jeff Terrell: I guess I was gonna say you can tune in. Now, but this next section might also be a little bit of a rehash so we'll see. Anyway, hopefully you're not too bored.
Jeff Terrell: Any questions so far.
Jeff Terrell: Okay, let's talk about a basic recipe for collaboration.
Jeff Terrell: Actually have this all just on one slide. But I'm going to walk through
Jeff Terrell: Each one each one of these steps.
Jeff Terrell: So first up, you'd say get pull origin master.
Jeff Terrell: Maybe you have if you've already set up origin master as an upstream tracking branch for your master branch, then you could just say get pull. But in any case, you want to fetch the latest code and update the working tree to include all of that code.
Jeff Terrell: And then you make whatever changes you need to make right you add your feature you fix your bug somehow you are updating the files and you're working tree.
Jeff Terrell: To do whatever you need to do and improve the code, some way
Jeff Terrell: When you finish with your feature you can say get status to see a summary of what's changed.
Jeff Terrell: If you want to inspect it in more detail what the changes where you can say get diff. You can either do that just get diff by itself will show you all of the changes and all of the details.
Jeff Terrell: Or you can specify it like scope it to a file and just see what's changed for that file since the last commit again that's comparing head to the contents in your working tree.
Jeff Terrell: If you decide that. Yeah. You want to go ahead and add this these changes to the index, then you would say get add file.
Jeff Terrell: You could also get add on a directory, including period, which is the current directory. And if you're at the repo route can add period would add everything
Jeff Terrell: You can confirm. What's going to be committed with get status because to us, will hopefully show you kind of what's changed. According to the index versus what's changed on your working tree.
Jeff Terrell: Into different sections. And by the way, good status also tells you commands that you need to manipulate the index in various ways. So again, good statuses very useful.
Jeff Terrell: And when you're satisfied with the contents of the index and you want to save that snapshot as a commit and you would just take it commit
Jeff Terrell: To create a new command from that index.
Jeff Terrell: And what that would do is you have to create the new snapshot, it would add all of the appropriate metadata, it would prompt you for a message.
Jeff Terrell: If you're doing this on the command line. It's going to be using the value of your editor environment variable all caps editor.
Jeff Terrell: And so if you're wanting some other editor to fire up. Besides, whatever the default. One is you can actually export that environment variable in your shell so that you can have something different fired up whenever you say get commit
Jeff Terrell: And then finally, once you've created the commits, you can push that up to origin master or wherever you need to push it again if you've already set up an upstream tracking branch, you could just say get push
Jeff Terrell: And that's going to update GitHub, or wherever your code is hosted it's going to update the master raft to include the new command that you just created.
Jeff Terrell: Alright, so that's the basic recipe. You've probably seen something like this before. I'm guessing and this is ok for as a start. It's a good place to start from. But it's not
Jeff Terrell: It's not maybe what you need, day to day there are some complications and we'll talk about that. But any questions about this.
Jeff Terrell: By the way, if you want more fine grained control over what you're adding to the index rather than just adding an entire file, you can say get add dash p file.
Jeff Terrell: And that puts you into it's a little bit tedious, but you can actually control exactly which changes are added to the index from that file.
Jeff Terrell: Various porcelains make this a lot easier. That's one thing I like about magic is that I can do this a lot easier.
Jeff Terrell: But you can do it with good ad dash p. All right. No questions about this. I'm going to keep moving.
Jeff Terrell: Okay, now I want to talk about different merge strategies and I'm going to start with just talking about the
Jeff Terrell: The problem with the basic recipe, which is what if somebody pushed a commit in between your pole and your push
Jeff Terrell: In that case, your push will fail because your remote origin is going to say,
Jeff Terrell: This is not a fast forward merge anymore. I don't accept it. I reject your push
Jeff Terrell: What should we do about that.
Jeff Terrell: So just to make this more clear. You get pull at the beginning.
Jeff Terrell: And you do a bunch of changes and then you push at the end. But what if somebody else pushed somewhere in here.
Jeff Terrell: Right, because maybe, maybe there's several days between your get pulling your get push
Jeff Terrell: Or maybe it's just an hour, but maybe somehow your teammate was active then and was ready to push up a commit at that point. So that commit got pushed in between. You're pulling your push
Jeff Terrell: At that point, you can't push. And so what do you do
Jeff Terrell: Okay. Now, if you
Jeff Terrell: See if you've been tuned out a little bit, because obviously is basic stuff, this would be a good time to tune in. I suspect this will be new for most of you, maybe not all of you.
Jeff Terrell: Before I actually answer the question I'm going to leave you in suspense, just a little bit and talk about a different way to log different way to see the history of get
Jeff Terrell: And this is going to be a really important tool for your toolbox. If you're using get on the command line.
Jeff Terrell: So yeah, let's talk about that. So get log is going to show you the recorded history from your current head it's going to show you all the commit meta data, maybe not quite all but it's going to show you like author and commit or username and timestamp.
Jeff Terrell: It's going to show you
Jeff Terrell: The, the commit message, obviously it's going to show you the commit address and
Jeff Terrell: It's going to also kind of walk up the chain of parent commits until it finds the initial commit and then it will stop.
Jeff Terrell: So get log will show you a lot of useful information but it maybe isn't the best way to diagnose certain kinds of issues and understand what's happening at a higher level.
Jeff Terrell: If it can be really helpful to see the chain structure more clearly and for the purposes of seeing the structure of the chain get logged by itself.
Jeff Terrell: Can be a little bit hard to parse, there's a lot of information there. And it's hard to kind of see the forest for the trees.
Jeff Terrell: Because there's a lot of details there. So if we can get those the noise out of the way and focus on the structure that can be really helpful. And so that's how these instructions do
Jeff Terrell: It turns out you have a good config file.
Jeff Terrell: I'm not quite sure where windows hosts this, but I know I'm Mac OS and Linux. This up home directory slash config file in your home directory windows, it might be like underscore get config in your
Jeff Terrell: Your user directory or something. If anybody knows what it is, feel free to post that in the chat.
Jeff Terrell: Anyway, somewhere, you have a good config file. If you don't have one you can create one. And that's your global get configuration for for all of get
Jeff Terrell: You can you can define your own aliases that work globally for using get anywhere on your system. If you don't already have an alias to section you can add that to your file.
Jeff Terrell: And then under the aliases section Adeline like so what this is doing is defining an alias called L that is a shorthand for get log dash dash graph dash dash decorate dash dash one line.
Jeff Terrell: So obviously you don't want to be typing that every single time you want to do it. So this is a nice shorthand, to to do that. And this is a tool that I use a lot. I mean, when I'm not using magic and I'm using it on the command line. I'm using it a lot. I find it very useful.
Jeff Terrell: And it will show the change structure more clearly. Again, the chain, meaning the chain of parent commits, because every commit except for the initial one as a parent, at least one parent
Jeff Terrell: And you can also give get log, as well as your get L alias multiple commits, by default, it will only print the log for your head.
Jeff Terrell: Meta ref, but you can also give it multiple graphs and it'll print the histories of all of those which, at some point, probably converged down to the same parent and then have the same history.
Jeff Terrell: But this can be a really helpful tool to be able to show you visually what's going on and give you more understanding about this.
Jeff Terrell: Okay, so it says Windows users might actually have the exact same file Duncan config.
Jeff Terrell: I'm not a Windows user. So that's, I just don't know. But, sounds good.
Jeff Terrell: Okay, so without of the way let's go back to are actually before you that
Jeff Terrell: One line is perhaps the most useful of these options and what that's doing is showing you one commit per line of output. And so it's a much more dense format of
Jeff Terrell: The history. And that's one of the ways that you can cut a lot of noise out of the get log and just focus on the structure of the chains.
Jeff Terrell: Decorate is adding
Jeff Terrell: The Ref names to the output. And so you're not just going to see the one line output.
Jeff Terrell: You're also going to see
Jeff Terrell: You know, this one is, is, is your local master. This one is origin master. This one is something else you'll decorate the output with these tag these rough names.
Jeff Terrell: Tags as well. Get out of there. We haven't really talked about tags. And I should say one line is really just taking the first line of your commit message and displaying that
Jeff Terrell: So that's actually a good idea. In most cases have multi line commit messages. We'll talk about that later. But one line is just showing you that first line.
Jeff Terrell: And then finally graph is showing you
Jeff Terrell: It's kind of visually displaying the chain. And so it's showing you how different commits are related by parent ID explicitly sort of in the left hand margin of the output. So let's see an example.
Jeff Terrell: So again, remember we have this problem of intervening teammate push. In other words, a teammate pushed before you had a chance to but your teammate pushed before you pulled or after you pulled rather so
Jeff Terrell: If you had that problem. The first thing to do is to make sure you have the latest convince you can say get fetch origin for that.
Jeff Terrell: And let's see, we talked about this already. This is origin master is the remotes ref name. So this is your local understanding of what origins master ref points doing
Jeff Terrell: This is current at the time of the most recent fetch origin. So this might actually be out of date.
Jeff Terrell: Me because somebody has pushed since we last did get fetch, but this is still useful because you can refer to your own local understanding of what origins master branch is pointing to.
Jeff Terrell: Another note to understand this output is that the at sign as a synonym for head.
Jeff Terrell: And for the purposes of this example we're assuming had points to master.
Jeff Terrell: Okay, that's a good point at time mentions that
Jeff Terrell: It might be easier, rather than editing your get config file and finding it. There's actually a command that
Jeff Terrell: You can use to set this alias globally yourself without trying to find that file in editing it, so thank you for that. I probably should have. I knew that, but I didn't think about it when I was writing the slides. So I'm glad you said that. That is better.
Jeff Terrell: bookcase has GitHub is going to change the name of the default branch from master to Maine. I haven't seen GitHub do that as far as I know, GitHub still uses master everywhere, but maybe I'm wrong about that.
Jeff Terrell: Okay, so anyway, we're getting back to this get L outputs.
Jeff Terrell: Okay, live says this change is going to take effect on October 1 very interesting was not aware of that.
Jeff Terrell: Good to know. So I'll have to at least update these slides. Next time I teach this course.
Jeff Terrell: Thank you.
Jeff Terrell: Master branches will remain on old repos. That's the only change new records going forward. Okay, interesting.
Jeff Terrell: And if that's a GitHub thing.
Jeff Terrell: Get is still going to put you in a master branch by default when you clone. So I wonder how they resolve that I guess maybe there's more information in this article.
Jeff Terrell: So anyway.
Jeff Terrell: Moving on to this example. So when we say get L or Ellis alias that we defined and then we give it head and origin master. Again, that's the remote branch.
Jeff Terrell: It's our local understanding of the remote branches, a better way to say that.
Jeff Terrell: You'll see something like this. Obviously the commit details might change, like the commit IDs and commit messages, but you'll see something like this.
Jeff Terrell: And in most cases this will actually be color eyes which I couldn't really capture here, at least not easily
Jeff Terrell: Which is kind of convenient, you know, these this rough decoration is going to be a different color than the commit message and that kind of thing. But the thing to note about this is the structure here on the left hand side, as provided by dash dash graph.
Jeff Terrell: And this is where we see some something interesting here we have potentially a lot of commits down the chain here that are just linear
Jeff Terrell: Just one commit after another. Each prefixed by a star and all this means is that we have one commit and it has a single parent committed, which is this one.
Jeff Terrell: Maybe that one as a single parent commit, which is the next one that chain and down we go. Just linearly. But at this point, we actually have two different children have
Jeff Terrell: Of this commit
Jeff Terrell: So what does this mean
Jeff Terrell: We basically have two competing theories on what the commit after F6 add two to three is
Jeff Terrell: Locally, we say that the next commit is 2162 but origin master says that the next commit is 971 f
Jeff Terrell: Alright, so, in a word, the histories have diverged.
Jeff Terrell: I didn't notice it some content was cut off there.
Jeff Terrell: Anyway, typically, because we are using origin as the source of truth. And we usually use GitHub. That way we would say that 971 F wins, because it was the first commit to hit origin master.
Jeff Terrell: And so our job. And this is what this last bullet point is supposed to say, our job is to update our local understanding of what things are so that we can incorporate this change into our local master branch.
Jeff Terrell: So we can't really change that and we can change that by pushing new commits. But before we can push new commits, we have to change what we're pushing so that we use this commit as a an ancestor of whatever we're trying to push
Jeff Terrell: Alright, so that's our job. How do we, how do we change our local understanding of master to include 971 if
Jeff Terrell: There's two different ways to do this.
Jeff Terrell: I would say this is a way to talk about this is to reconcile the histories, the histories of diversion. We need to reconcile those two. So the first strategy is merging.
Jeff Terrell: And this is provided by the get merged command which is going to incorporate the changes from a different branch into your current one.
Jeff Terrell: So in this case, if we said get merged origin slash master that would meet our goal and try to reconcile our histories by only making local changes.
Jeff Terrell: So how does this actually work. Well, there's kind of a conditionality to this. There's a couple different cases.
Jeff Terrell: If the other commit contains our current commit in its history.
Jeff Terrell: Emerge will merely update our raft to point to that commit. This is what's known as a fast forward merge.
Jeff Terrell: And there's no competition possibility for conflict here because clearly the other commit is newer
Jeff Terrell: Because it already knows about our old commit and because it hasn't been in history. And so all we have to do is fast forward to get to the current state of history.
Jeff Terrell: So that's a pretty simple reconciliation. All that means is that one branch or one commit is behind
Jeff Terrell: I should say branch one branches behind another. So all we do is fast forward that branch to catch up to the current state. Okay, so that's the case, again, that's called a fast forward merge and that's what's meant by a fast forward marriage. If you ever see that anywhere.
Jeff Terrell: If your head commit that you're you're merging into already contains the other one, then it's a no op you already have that history merged into yours. And so to say get merged on that history is a no op you already happen.
Jeff Terrell: Otherwise, as is the case here. We actually have divergent history, neither a see 971 f is not a an ancestor of 2162
Jeff Terrell: Neither vice versa.
Jeff Terrell: Nor vice versa. I don't know how to say that anyway but 2162 is not a parent of or an ancestor of 971 F either. So we have divergence. And in this case, what get merged will do for us is create a new commit with two parents
Jeff Terrell: Remember that a commit can have multiple parents commits
Jeff Terrell: Remember that a committed is just a snapshot. Remember our definition of kits.
Jeff Terrell: And in many cases, the two different changes that each branch introduced
Jeff Terrell: Are compatible, there's no actual conflict there. And so get can handle those kinds of merges without any any difficulty.
Jeff Terrell: It just handles it automatically. It's not ambiguous. There's just no possibility for conflict because maybe you change file a and the other branch change file be and so it's like okay, fine. I can handle both of those things without any conflict.
Jeff Terrell: Otherwise, we're in a merge conflict situation and you will need to manually intervene. There are ways of doing that. We'll talk about that later. Probably not today.
Jeff Terrell: But yeah, you might run into that from time to time. Alright, so let's look at what happens when we merge.
Jeff Terrell: If we said get merged origin master and then we did our get L command to see the results of both branches. Here's what we would find
Jeff Terrell: This takes a minute to, I don't know why I didn't notice.
Jeff Terrell: These lines are getting cut off. I feel like they weren't for me earlier but anyway.
Jeff Terrell: Um, yeah, let me see here anyway. Okay, so this takes a minute to look at and understand what's going on. And this is where this dash dash graph and dash dash decorate really help in that get al alias.
Jeff Terrell: This graph is really useful. So
Jeff Terrell: Again F6 is our common ancestor that both branches share
Jeff Terrell: origin master. We didn't change origin master.
Jeff Terrell: I think I forgot to say something. I'm wondering if something earlier was cut off anyway. Sorry, I could get myself distracted here.
Jeff Terrell: The thing I forgot to say earlier was that get should enable agility, maybe I have this later in my slides.
Jeff Terrell: Get really should enable agility and one of the ways that you can do that is by being confident that what you're doing is going to be reversible, you're going to be able to fix any problems that you make.
Jeff Terrell: And one thing that's really important to note it because of remotes and the whole concept of get having remotes is that you're not ever going to be affecting any of your teammates or collaborators until you push
Jeff Terrell: To get merged is not a push. So you can do this and you can cause all kinds of problems for your local repository.
Jeff Terrell: And probably, if you're experienced enough and get you can fix whatever problems you create, but you don't have to worry about affecting any of your teammates by running these kinds of local commands. Because the only thing you're affecting is your own local instance of your repo.
Jeff Terrell: So as a consequence of that, when we say when you look at the results. So again, merge origin master didn't change.
Jeff Terrell: This was your teammates commit that got pushed before years since we didn't say get push
Jeff Terrell: We're not affecting anything on origin. Alright. So today's word is the difference here is that now we have a new commit that is a
Jeff Terrell: Child of both origin masters command your teammates commit and your local commit to one six
Jeff Terrell: Alright so this can be, it has to parents see how it has lines that go to this star and that star.
Jeff Terrell: And the commit message is usually chosen for you automatically merge remote tracking Brad George master into branch master.
Jeff Terrell: But anyway, that's how get merged works.
Jeff Terrell: And so notice there's kind of some parallel there's there's kind of two parallel tracks going here in the get graph output.
Jeff Terrell: Get log graph output. This is a non linear history, and this has implications that we'll discuss later.
Jeff Terrell: I tend to prefer to avoid nonlinear histories, they're harder to understand their visually noisy and this kind of output pay they have other difficulties so that we'll talk about.
Jeff Terrell: So that's that maybe a downside here, but at the end of the day, you can maybe barely read this at the bottom, the merge commit includes origin masters commit in its history. So I push will succeed.
Jeff Terrell: So this origin master commit is included in the history of our new merge commit. Therefore, we can now push to origin master successfully.
Jeff Terrell: Alright, so we've reconciled our history, using strategy one merging questions about this.
Jeff Terrell: Okay.
Jeff Terrell: Oh, I might regret this.
Jeff Terrell: But I wonder if we should try to do this.
Jeff Terrell: Let me briefly mentioned. Let me briefly walk through what rebasing does and probably we will cover this again at the beginning of next lecture because I'll probably go through it too fast for it to really sink in right now.
Jeff Terrell: Another strategy here is to replace your commits and so starting from the same place what what every base will do is it will first. I mean, I guess, step zero maybe is to identify the merge base.
Jeff Terrell: So the merge base here is the the closest shared ancestor of both the branch that you're basing on to and your current branch.
Jeff Terrell: So in this case, we're trying to re base this on to this and the shared ancestor is this
Jeff Terrell: So in this case, rebates is going to identify that merge base and then it's going to walk back up from where we are to the merge base. And in this case, that's just one step and at each step of the way it's going to push the changes, represented by that step onto a stack.
Jeff Terrell: In this case, there's only one set of changes because we only have one step.
Jeff Terrell: Finds the merge base.
Jeff Terrell: Then it advances the local RAF which is master up to the thing that we're rebasing onto which in this case is origin master. So that would be a fast forward merged kind of thing. We're just advancing the history
Jeff Terrell: We get up to this day. And then we replay those capture changes popping one thing off the stack at a time and at each step of creating a new commit same commit message going to be different. Commit address because we had different contents our different parent IDs.
Jeff Terrell: But we replay each of those commits and then we have the same commits replayed on top.
Jeff Terrell: The thing that we're going, we're basing on to. So the end result of doing get repaid origin master looks like this.
Jeff Terrell: You have a common parent commits, then we have our teammates COMMIT, AND THEN WE HAVE MY replayed commit. It's not the original commit, but it has the same changes different ID because different contents with respect to that metadata but same diff.
Jeff Terrell: Effectively same def
Jeff Terrell: Alright so changes. Here are the same as in my first commit. There could still be some merge conflicts here. So I'm assuming there aren't for the sake of simplicity here.
Jeff Terrell: And now, again, we're at a point where my rebates to commit includes origin masters commit in its history. So therefore I am able to push to origin master.
Jeff Terrell: Okay, so I flew through every base. Next time we'll talk about the
Jeff Terrell: Kind of analyzing merging versus Freebase and making a decision about which one is preferred.
Jeff Terrell: But for now, I'd like to just get your input on how that went. And whether it was an effective lecture for you as well as anything I can improve on.
Jeff Terrell: So I will stop recording now and
Jeff Terrell: I'll stick around if you have any questions or want to chat about anything later.