Jeff Terrell: hey everybody.
Jeff Terrell: gonna be talking about get today.
Jeff Terrell: And before we dig into that.
Jeff Terrell: A few announcements okay so Simon five was do this morning assignments, six and seven having to do with your architecture choices are do in a week.
Jeff Terrell: I want to recommend that you know it's okay to change your mind about the choices that you make you don't have to know everything in advance.
Jeff Terrell: so that you can make the very best decision about your architecture it's okay to make the best decision that you can with the knowledge that you have right now.
Jeff Terrell: And then change your mind later.
Jeff Terrell: So I think it's not going to be completely unexpected if you make some choices now for application architecture and then.
Jeff Terrell: Once it comes time to actually use those choices and integrate things various things together, you realize and that'll happen in assignment eight you realize oh actually I don't really like that thing that I that we had decided on.
Jeff Terrell: And it's okay to change your mind remember.
Jeff Terrell: Well, it depends on how many how much stuff you've piled on top of that choice, maybe there's a lot of stuff that you have piled up on top of it and.
Jeff Terrell: You have to undo a lot of work and throw away a lot of work to change your mind about it because you're already based other things, on top of it, so you know, there might be a cost there, but you can weigh that cost as part of the decision that you're reevaluating.
Jeff Terrell: Also assignment six is designed to reacquaint you with the choice that you made, and why you made it if you are considering changing your mind Simon six can remind you why you chose that made that choice and that can sort of.
Jeff Terrell: help you make a wise decision, instead of an emotional one once you're trying to climb a learning curve of some new technology or something like that, but anyway.
Jeff Terrell: If you do, change your mind update your design artifacts i'd recommend that keep those up to date, these do not even though you turn them in.
Jeff Terrell: They don't have to be static all right, and in some cases, no diagram at all is better than a diagram that is lying to you because something has changed in the diagram hasn't reflected that change.
Jeff Terrell: So if you do make a change to your architecture or your design in some way feel free to update those things.
Jeff Terrell: Also, something that I like to do when possible, as if I have a clickable prototype and i'm working on some feature that isn't in that prototype.
Jeff Terrell: I will just like we we did and sort of the big picture view I like to do the same thing when talking about a particular feature and just prototype first.
Jeff Terrell: come up with the ux that actually works figure out where you want that new button to live or whatever and iterate there in the clickable prototype and then implement once you have a prototype that you like.
Jeff Terrell: So, remember that you can do that as well, but the big idea here is like these things, even though you turn them in they don't have to be static and, in fact, it might make sense for the health of your project and the sanity of whoever's taking over your work after you're done.
Jeff Terrell: To keep those artifacts updated.
Jeff Terrell: Also, as I emailed on Thursday, remember that I am soliciting your ideas on how to maximize the value that you get from the time that you spend meeting with your mentors.
Jeff Terrell: mentors are resources for you, I hope that you all feel like they are worth the time.
Jeff Terrell: I know some of you absolutely do I think, maybe some others of you don't feel like it's worth your time feel like it's just another hoop that you have to jump through.
Jeff Terrell: And you know I can't change your mind on that that's if you really maybe maybe you don't like your mentor maybe your mentors and doing a good job that's good for me to know as well.
Jeff Terrell: But sometimes you know, depending on what you take into it and kind of how you approach it, you can unlock a lot of value in those meetings.
Jeff Terrell: These are people who have been in industry a while know a lot of stuff and so, if you figure out the right questions to ask and how to engage your mentor you can it can really level you up.
Jeff Terrell: So I am interested if any of you have figured out ways to interact with your mentor that seemed really effective or maybe even your mentor had those ideas.
Jeff Terrell: Or maybe you have questions that you're really glad you asked your mentor anything like that I would love to know about that, so that I can share it with the rest of the class and maybe benefit other other teams.
Jeff Terrell: So feel free to email me any of those ideas i'll share that either in class Wednesday or potentially in an email that I send maybe on Thursday.
Jeff Terrell: I want to start our discussion of get by just checking how comfortable do you feel using get so let me open up this.
Jeff Terrell: poll polivy.com slash Jeff terrell.
Jeff Terrell: Okay.
Jeff Terrell: Okay, so looks like so far from the responses we received you got a small portion of the classes, not at all comfortable or not very comfortable, but most of you are at least fairly comfortable and about half of you are somewhere between comfortable and very comfortable so that's great.
Jeff Terrell: I had my seat here to reactivate that if you're still working on a response Okay, I had a pretty similar breakdown last year, when I taught this.
Jeff Terrell: seems like most of you have had some experience with get and i've used it some and i've gotten to some level of comfort with it.
Jeff Terrell: And so the slides I think are pretty well targeted for this distribution, if you are in the.
Jeff Terrell: somewhere between fairly comfortable and very comfortable.
Jeff Terrell: i'm going to give you some tips on get i'm going to move fairly quickly hopefully it'll be sort of high value for per unit of time.
Jeff Terrell: For all of you, if you are in the top couple of ranks here, not at all comfortable and not very comfortable then.
Jeff Terrell: I would say a couple of things, one is that's Okay, I get I think for some of you was never part of anything you had to learn for classes and it's not expected that you should know get at this point Okay, if you don't.
Jeff Terrell: But this is not going to be the jump to list or friendliest of tutorials on get so if this isn't doesn't work well for you, if i'm moving too fast, or something like that.
Jeff Terrell: For one thing, remember that the slides are always available for you to review after the fact, as well as the recorded lecture but for another thing.
Jeff Terrell: should ask your teammates work with your teammates on get if you have questions if your teammates don't know.
Jeff Terrell: Or, if you want a diversity of opinion of opinion, then you're definitely welcome to stop by the APP lab.
Jeff Terrell: pretty much I think all of the staff members there know how to use get and can help you if you get into trouble with it, or something like that so.
Jeff Terrell: that's a good resource and, of course, you can always ask your your mentor who probably has some good experience with good and maybe some well well reasoned opinions as well.
Jeff Terrell: So, my primary learning objective for today as as well as wednesday's lecture or will also be covering it is to equip you to use get well, not just by yourself, but together with other people so collaboration strategies for using get i'm going to be talking about.
Jeff Terrell: yeah just how to use it well together.
Jeff Terrell: I will briskly cover the foundational concepts it's kind of quick, as I can, while doing full service to those concepts, but i'm not going to spend a lot of time there i'm going to try to lay that foundation, so that we can move on to how to actually use it well.
Jeff Terrell: And i'm going to cover my recommendations for how to use it well collaboratively and I will include recipes but I really y'all probably seen various recipes for collaboration and get before.
Jeff Terrell: And that's fine that's that definitely serves its purpose, but I want to do better than that by telling you why.
Jeff Terrell: I would recommend this or that i've been sharing my video this whole time have I sorry for you, those of you on zoom.
Jeff Terrell: There we go sorry about that.
Jeff Terrell: yeah so it's just including a conversation about why you would do this or that what are the trade offs and what are the things intention here, and when might you reasonably make a different choice than what's listed in a recipe or guideline.
Jeff Terrell: Okay.
Jeff Terrell: So today i'll do just the intro we know why are we studying get what is get.
Jeff Terrell: going to cover those foundational concepts, there are eight concepts that will cover there we're going to give a basic collaborative recipe and talk about some shortcomings of the basic recipe talking about merge strategies, including merge Andrey base.
Jeff Terrell: And then we'll give an advanced collaborative recipe which preview is actually trunk based development if you've heard of that and then they're just kind of a smattering of other tips and tools and topics forget to help you be equipped to use it well collaboratively.
Jeff Terrell: Okay, so what is get and why are we spending our class time studying it.
Jeff Terrell: Get is this is the definition that i'm giving the definition that get gives, by the way, as a stupid content tracker, which is actually.
Jeff Terrell: Like the word get in English means kind of stupid, so that it get is intentionally stupid that's their word but anyway, my definition is that good is a tool for storing and sharing snapshots of the contents of a directory.
Jeff Terrell: And will be referring back to that definition with some of these foundational concepts, a tool for storing and sharing snapshots.
Jeff Terrell: Of the contents of a directory.
Jeff Terrell: Nothing get is not the same as github.
Jeff Terrell: A lot of beginners make this mistake i've heard even faculty members make this mistake github is a service for hosting I get repository, it is a commercial company get is an open source tool.
Jeff Terrell: And in fact get is a command line tool, there are a couple of.
Jeff Terrell: graphical user interfaces that are even included in the get distribution, but at its heart get as a command line tool.
Jeff Terrell: And there are a lot of different ui that people will use for cat so you probably have something integrated into your ID.
Jeff Terrell: To do get stuff this would be what get would call a porcelain forget, in other words kind of a bright and shiny interface, as opposed to get get distinguishes between it's porcelain commands on the command line and it's plumbing commands so it's kind of a fun analogy.
Jeff Terrell: The plumbing ones, are the ones you're not you're not usually going to use unless you wanna do something well level anyway yeah I actually use a porcelain forget called magic and my emacs based editor I love it it's very keyboard driven.
Jeff Terrell: it's kind of a funny sort of porcelain but it works really well, a lot of people just swear by it and i'm one of them.
Jeff Terrell: But anyway, we're not going to cover get with any particular.
Jeff Terrell: graphical user interface, because I think it's a little bit harder to figure out, what are the underlying concepts when you're looking at it that way, maybe your view of a of a gooey your porcelain is different than what I would show you so.
Jeff Terrell: we're going to be using command line get as the common denominator, that we all have access to, and which I think reveals the underlying concepts, a little bit better.
Jeff Terrell: Okay, so why study get.
Jeff Terrell: This is one of the most dominant technologies in software development when you think about it, like.
Jeff Terrell: there's not much that has the sort of market share that get has.
Jeff Terrell: You want to talk about programming languages, even the very most popular ones I don't know what the numbers are but i'd be surprised if any single programming language covered, more than half of the market.
Jeff Terrell: Not even operating systems, you know.
Jeff Terrell: Nothing I can think of, except maybe email or spreadsheets or something like that is as popular in terms of technology.
Jeff Terrell: Maybe http or tcp or something like that, but but anyway it's a very, very dominant tool that pretty much everybody these days uses.
Jeff Terrell: This wasn't the case when I was in school in fact it wasn't even around when I was an undergrad and when I was in Grad school I first started hearing about it and yeah anyway so.
Jeff Terrell: it's probably not going to go anywhere anytime soon, I honestly when I think about like.
Jeff Terrell: A lot of software I use i'm like well.
Jeff Terrell: You know if I were doing this from the ground up and I were designing it I would do I would make a little bit of a different decision here and there, and whatever and if I spent some time I could come up with a list of things like.
Jeff Terrell: You know, given infinite time if I wrote my own here's what I would do differently with get.
Jeff Terrell: I don't know what I would change.
Jeff Terrell: I really don't I actually think it's extremely well designed.
Jeff Terrell: Okay, maybe, if I were designing a front end for it, I would make a little bit different choices in terms of ux although.
Jeff Terrell: Actually, with magic I probably wouldn't actually really like that, too, but in terms of the actual design of the system, I think it's fantastic and it's really interesting to study, in fact, if you took my 590 course three semesters ago which I don't.
Jeff Terrell: Think well, maybe one or two of you did I don't know anyway.
Jeff Terrell: That was a software architecture three semesters ago yeah I don't know if anybody from there still around here, maybe, maybe so but.
Jeff Terrell: Anyway, I had my students actually implement a version of get including all of the mechanisms for how it stores data in the code base and everything else and it's a really it's a really neat system.
Jeff Terrell: we're not going to go into that much detail here you don't have to know all of the the mechanisms, but.
Jeff Terrell: But it is really neat and if you understand some of the concepts, then it can help you just save you some headache you're probably gonna have to be using it anyway.
Jeff Terrell: If you think about just mentioned this as a pro tip.
Jeff Terrell: Some technologies aren't worth really investing in.
Jeff Terrell: Like you could probably find something really niche for one project that you're you know you're probably not going to use for any future project, and if you have a technology like that you just kind of want to do the minimum that you need to to get things working.
Jeff Terrell: But if you know you're going to be using something in the future, especially if you know you're going to be using it a lot, like every day.
Jeff Terrell: It can really make sense to actually go and read the manual right like that's time lost compared to stuff that you could be working on and making features, or whatever, but the usually those kinds of investments pay off if you know you're going to be using something every single day.
Jeff Terrell: And I kind of made that choice I made that choice, a number of times one with them bi style editing I that's a big learning curve, but if you climb it, you can be so much faster editing text.
Jeff Terrell: I switched to the call MAC keyboard layout any call MAC users know.
Jeff Terrell: A lot of people have even heard of komack.
Jeff Terrell: it's a good it's a good layout anyway, not qwerty something different.
Jeff Terrell: And and get actually read a book on get just to understand more deeply what it was because I could kind of recognize like this technology is here to stay and if I actually understand more deeply what's happening here it's going to help me in the long run.
Jeff Terrell: Okay, why do we need to use version control at all.
Jeff Terrell: Why do we need a code base like a database of code, why not just have a shared drive.
Jeff Terrell: Occasionally, I get this question and I think if you haven't considered this it's a question worth considering like why what would the disadvantages of a shared drive be compared to something like get.
Jeff Terrell: access control yeah although with Google drive, you can do access control.
Jeff Terrell: yeah going back to an old version I don't know anybody know whether something like Google drive can actually do that go back to like an old version of ups in the drive.
Jeff Terrell: dropbox can.
Jeff Terrell: Okay, I know, Google drive can be like old versions of like a spreadsheet or whatever, but I don't know about the drive but but at dropbox can so imagine that you had a shared drive that actually did have.
Jeff Terrell: The ability to go back in time and say what was what were the contents of this folder on this date.
Jeff Terrell: Right, would it still be worth using something like that, or would that be enough of a you know powerful enough tool that there's not much point to learning a new system might get.
Jeff Terrell: So, if you think about I think the key question really is the last one here, how can you be confident you're not clobbering your teammates changes.
Jeff Terrell: So even if you had a shared drive, even if you could go back in time.
Jeff Terrell: And even if you had the discipline of sending a message out to your team every time you made a change to something in that shared drive, which would basically be like the commit message and get.
Jeff Terrell: Even if he had all those things there's still the question of like well how do I know you know I edited this file or these you know these five files I edited these five five files and the drive.
Jeff Terrell: How do I know that.
Jeff Terrell: I started from a version that nobody has changed since So what if I added these five files, but one of those files was also edited by my teammate how am I going to know.
Jeff Terrell: probably be pretty tedious to actually compare like okay what's changed since I last copied my files over and are any of those changes in compatible with what i've done.
Jeff Terrell: I can get really tedious really quick, especially if you start thinking about you know your your project has multiple sub directories in it and nesting and lots of different files and get basically automates a lot of this.
Jeff Terrell: and
Jeff Terrell: It avoids a lot of the tedium of doing something like that, and a lot of the errors that you would get if you're manually doing that so so it's it's worth learning it's worth using there's a reason it's such a popular tool.
Jeff Terrell: But questions about you know what it is, or why we're studying it.
Jeff Terrell: Okay.
Jeff Terrell: We have eight foundational concepts to cover so i'm going to go through this briskly, although I will pause at each step and ask if there are any questions.
Jeff Terrell: First concept is a repository.
Jeff Terrell: aka a Repo for short.
Jeff Terrell: This is a code base, which is another way of saying a database of code.
Jeff Terrell: Although that's kind of a loose term I mean it doesn't have to be code.
Jeff Terrell: It can really be any sort of file based data, whether that's code or some other text based data like markdown, which is what I use for the website.
Jeff Terrell: I write my content and markdown it's not code it's just content in a certain format that gets compiled in html at some stuff but I store that and get get can handle that just fine.
Jeff Terrell: And in fact it can even handle binary files that are not text based at all it's maybe not as easy to use, in some ways, if you do that kind of stuff but like your deaths are going to be kind of weird put some it works.
Jeff Terrell: and note that there is history for each repo, but that is a concept that is owned by the repo so a repo has a history and a different repo has a different history.
Jeff Terrell: Now, if you go to the like your project on github that's not your repo right that's information that github is showing you about your repo your repo is the database.
Jeff Terrell: All right, alright.
Jeff Terrell: And when you clone something what you are cloning is a repo you're not cloning, a a folder you're not cloning, a project you're not cloning, a commit your cloning, a repo.
Jeff Terrell: Not cloning, a branch.
Jeff Terrell: If you clone something than a repo would be stored locally in your on your hard drive in a certain directory.
Jeff Terrell: you've you've all seen this.
Jeff Terrell: And remember the definition here good as a tool for storing and sharing snapshots of the contents of a directory so that code base is containing those snapshots and some metadata.
Jeff Terrell: And that's all included in a Doc get subdirectory.
Jeff Terrell: When you clone it's a top level subdirectory of your project.
Jeff Terrell: And that has all of the data in the in the code base and the repo questions about repositories.
Jeff Terrell: Okay.
Jeff Terrell: concept to is a commit.
Jeff Terrell: We are storing and sharing snapshots of the contents of a directory and those snapshots are called commits.
Jeff Terrell: Technically trees are commits are sorry trees are snapshots and commits are trees, plus some Meta data about the tree.
Jeff Terrell: So if you want to get technical that's the difference between a tree and a commit but effectively most people's mental model is that a commit contains snapshot and some metadata.
Jeff Terrell: Now, if you think about taking a snapshot of like.
Jeff Terrell: I don't know the weather conditions from Cape hatteras right you take a snapshot at a point in time and that snapshot is immutable right.
Jeff Terrell: you're not going to go back and say at this point in time, it was actually different than what the snapshot said.
Jeff Terrell: it's immutable that's it that's what I snapshot really is it's it's an immutable sort of representation of the state at that point in time and that's exactly what it is here in get.
Jeff Terrell: commits are immutable and the way that get does that, as part of the design that I think is really neat is that commits the database and get his content addressable so the address for that content is actually computed as a function of the content.
Jeff Terrell: So if you change the content, the address is going to be different, which means that that old address is still pointing to the original content can't change.
Jeff Terrell: So some of the Meta data in a commit is going to include like the author info like.
Jeff Terrell: name and email the timestamp.
Jeff Terrell: message.
Jeff Terrell: and any parent commits that might be attached to this commit.
Jeff Terrell: There can be zero or more parent commits.
Jeff Terrell: Zero means you're at the initial commit of a repository.
Jeff Terrell: I was like the starting one, there were no committed for it, but a typical use cases you'd have one parent company, you can have more than one like if you're doing emerge between two different branches, you would have a commit with two parents.
Jeff Terrell: In that address of the commit is actually that thing you've probably seen addresses like this if you're on github or are looking at a get log output something like that these random seeming hex ids, these are the addresses of the commits.
Jeff Terrell: Okay questions about commits.
Jeff Terrell: yeah I realized this is probably review for many of you that's fun trying to go quick, but maybe this will fill in some like you have some understanding of these concepts from experience, but sometimes it's nice to hear like.
Jeff Terrell: A clear articulation of what these concepts actually are so that you can standardize your vocabulary and fill in some background knowledge that you missed, and maybe just get some more clarity about your understanding.
Jeff Terrell: Constant over three, the working tree.
Jeff Terrell: Working curious what you actually have on your hard drive.
Jeff Terrell: Okay, so you, you might have something that is clean, meaning that you haven't changed it, since you last got the latest commit.
Jeff Terrell: And the stuff that's on your hard drive is the same as what's in the code base and you would have a clean working tree give a dirty working tree, that means you've made some change since the last commit.
Jeff Terrell: kind of like you know your your document hasn't been saved.
Jeff Terrell: and get status is always the go to i'll tell you what's changed.
Jeff Terrell: and give you commands to us to.
Jeff Terrell: Change what's going to be committed which we'll talk about next does that make sense, the working tree.
Jeff Terrell: Okay.
Jeff Terrell: concept for is the index.
Jeff Terrell: When you say get commit you are not committing the working tree you're committing the index the index is a staging area to prepare exactly what's going to be committed and what isn't.
Jeff Terrell: Even if you haven't used to get the get command line you probably are familiar with this concept, you have to like add files to the index to prepare the commit.
Jeff Terrell: Change what's going to be committed maybe your ID or whatever tool you're using forget doesn't call it the index maybe it does, but.
Jeff Terrell: That is the term that get users.
Jeff Terrell: And you can actually have a lot of control over exactly what gets added to the index it's one of the things that I really liked about magic is that i'll just select like within a file, I only want to be committing a piece of that file of changes that I made to that file so.
Jeff Terrell: I like select a section of the changes that I made to that file and i'll only stage that piece of the changes, rather than the entire file.
Jeff Terrell: But that's what the index gives you and you can do that on a command line to it's not as easy, but you can.
Jeff Terrell: But that index gives you that control over exactly what you're going to include in the commit.
Jeff Terrell: without losing any of your changes.
Jeff Terrell: I used to use subversion back before it was the thing it's a version was a great improvement to CBS but which was kind of the original thing, I guess, maybe rcs was early too, but.
Jeff Terrell: Anyway, so version didn't have an index, it would just commit everything that was in your working tree, and so you didn't have a lot of control over exactly what you committed, and I think this is a good innovation.
Jeff Terrell: This is an interaction right, I mean we've heard about interaction from maybe.
Jeff Terrell: classes like that.
Jeff Terrell: But this is an example of indirection we're not committing directly working tree to commit where we have a level of indirection there.
Jeff Terrell: Get status will tell you the commands to use to adjust the index So if you ever don't know just say get status.
Jeff Terrell: they'll say yeah you can use get add to change what's going to be committed, you can use get restored to undo the stage.
Jeff Terrell: Get back get the index back to where was.
Jeff Terrell: Questions about the index.
Jeff Terrell: Okay.
Jeff Terrell: concept five is branches aka refs.
Jeff Terrell: A branch is a ref those two terms are completely interchangeable if you're talking about a branch you're talking about a raft if you see the word ref in a get man page it's talking about a branch same exact thing.
Jeff Terrell: And what a ref does is it points to a commit it refers to a commit to reference that's why it's called ref if you know C c++, this is the exact same idea as a pointer.
Jeff Terrell: If you don't that's fine.
Jeff Terrell: The only data that a branch contains is its name.
Jeff Terrell: Well, its name and I guess the commit that is pointing to.
Jeff Terrell: But apart from that, it does not have any data in itself.
Jeff Terrell: All it does is refer to a commit and if you get this this might be the the missing sort of piece of understanding that can take you to the next level with get this is really important to understand branches all branches are is just a pointer to a particular commit that's it.
Jeff Terrell: depending on where you created it from it'll point to the same commit that your current branch pointed to by default, so you didn't have a new ref that referred to the same commit as your current branch did.
Jeff Terrell: yeah but you didn't create a new commit you didn't really add anything to the.
Jeff Terrell: The set of commits in your repo or anything else you just added a new RAF.
Jeff Terrell: and get branches, the command that you can use to list out your branches.
Jeff Terrell: Any questions about refs or branches.
Jeff Terrell: Okay.
Jeff Terrell: Then there's the head.
Jeff Terrell: The head of your repo.
Jeff Terrell: Ahead ref is kind of like a Meta ref.
Jeff Terrell: Now it can refer to a combat just like a ref can, but it also can refer to a ref.
Jeff Terrell: Normally refs cannot refer to refs refs only refer to commits but head is kind of Meta in that it can refer to a rough and what had is telling us is what is currently checked out.
Jeff Terrell: So that little piece of information has to be stored somewhere, so that get to know what is currently checked out and that the place where that is stored, that the concept, where that is stored is called the head of the repo.
Jeff Terrell: So it's the current branch, if you have a branch checked out otherwise it's the current commit that you have checked out.
Jeff Terrell: and get branch will also tell you which branch is currently checked out if a branch of struck down.
Jeff Terrell: If you want to resolve had to an actual commit address you can say get revved parse head.
Jeff Terrell: REV is short for revision here, which is effectively like a commit.
Jeff Terrell: and get switch will change had it'll change the currently checked out branch.
Jeff Terrell: Old command to do this, by the way, is get checkout but they added get switched within the past year or two.
Jeff Terrell: Now if had does point to a ref, meaning that you are on a branch currently then whenever you say get commit that's actually going to update that ref right it's going to create a commit.
Jeff Terrell: The new commit is going to have the old commit as the parents.
Jeff Terrell: And then, whatever branch, you have checked out is going to be updated point not to the old one, like it did, but to the new one that you just created this is what you would expect, we actually think about it.
Jeff Terrell: Not that the output of get status, you know it's going to tell you what changes in your working tree are dirty if any.
Jeff Terrell: But note that that question is actually a function, not just to the working tree it's also a function of head.
Jeff Terrell: and saying what's dirty relative to head.
Jeff Terrell: So you could have the exact same working tree and it might be clean with one value have had and dirty in different ways, with a different value have had.
Jeff Terrell: Questions about the head ref.
Jeff Terrell: Okay.
Jeff Terrell: Two more concepts, so far, everything we've been talking about has just been your local repo we haven't talked about how to actually share any data between repos yet that's where the concept of remotes come in.
Jeff Terrell: You and your teammates each have your own local instance of the repo.
Jeff Terrell: Or maybe a better way to say to you, each have a repo of your own.
Jeff Terrell: But then to actually share information between those different instances, you need a concept called a remote and a remote is just a URL pointing to some other instance.
Jeff Terrell: that's it.
Jeff Terrell: If you go to you know the page on github for your projects and you click the clone button, then you copy the URL to clone it, you said get clone and paste that value in that URL is the URL of a remote it's actually what it is.
Jeff Terrell: And when you clone from a URL.
Jeff Terrell: One of the things that happens automatically whenever get clones, a new a new repo.
Jeff Terrell: Is it will set up a remote for you named origin.
Jeff Terrell: That points to that URL that you clone from.
Jeff Terrell: that's like the default default remote and it's usually named origin, although I think you can change that.
Jeff Terrell: yeah remote is just a URL pointing to another instance.
Jeff Terrell: And the key idea of collaboration and get is that collaboration works by sharing commits with remotes.
Jeff Terrell: And i'll say that again because it's important.
Jeff Terrell: Collaboration works by sharing commits with remotes.
Jeff Terrell: that's actually what's being shared.
Jeff Terrell: Get itself is actually a decentralized version control system.
Jeff Terrell: Which means that you don't have to have github get lab you don't have to have a centralized server holding an authoritative copy of the repo.
Jeff Terrell: Each person can have their own notion of what's in the repo and you can get work done without there ever being a centralized server at all you can contact your appears directly make sure that they have your code or and that you have their code all your all their updates.
Jeff Terrell: Now that's not going to be as efficient way to do it that's like a.
Jeff Terrell: Many too many connections, rather than having kind of a hub and spoke model but, but you can do it that way and get us set up to allow that.
Jeff Terrell: That said, most people are going to find it easier and more efficient just to use a service like github or get lab or some other centralized source of truth, I would expect that you do that in your project as well.
Jeff Terrell: If you're ever interested in the meat case study Linux kernel development is really neat like this about this, because they.
Jeff Terrell: I think there is a an official version official repo somewhere, but a lot of Linux kernel development happens through sharing patches over email there's like different subgroups there's a ton of different subgroups within Linux kernel development and somebody will come up with some.
Jeff Terrell: Some new feature or some bug fix or whatever and they'll share the patch over email and that's I don't know it's it's kind of different there's no pull requests there's no github.
Jeff Terrell: And there's a ton of commits, by the way.
Jeff Terrell: Now one closely related concept to remotes is that of remote branches.
Jeff Terrell: And these are the branches that are remote contains Okay, just like your local instance can have multiple branches multiple rafts I local or a remote.
Jeff Terrell: instance can as well.
Jeff Terrell: And so, whenever you are getting all the data from a remote you're updating your own notion of what is contained in that remote.
Jeff Terrell: But.
Jeff Terrell: There is no process that is actively sinking data from the remote.
Jeff Terrell: So, most of the time.
Jeff Terrell: Well, maybe not most of the time, depending on your project, but a lot of the time, the information that you have about the remote is going to be out of date.
Jeff Terrell: it'll be stale because you you fetch all that data, but then you did some work and day passes and three days pass and then, in the meantime other people are pushing new data to the remote, but the stuff that you have locally about the remote is stale.
Jeff Terrell: And that's by design you don't want to have to spin up a server to like sync things up all the time that would add a lot of complexity, to the to what it is.
Jeff Terrell: As well as just how to use it that's actually why they decided to name get get and why they call it the stupid content tracker is that this isn't like.
Jeff Terrell: You know, a postgres database or a mongo database, where you have to have a server listening all the time for new connections and so on it's a lot more complex.
Jeff Terrell: This is stupid and that it only interacts with stuff during the command execution and then it's over and it doesn't do anything else.
Jeff Terrell: Anyway, so remote branches are tracking a branch out the remote and that is often stale a key part of just collaboration strategies with get is how to deal with the fact that information you have about the amount of stale or can be still questions about remotes.
Jeff Terrell: Okay last concept here is being able to.
Jeff Terrell: I had made some changes, but I forgot to save okay basically just how to share data between remotes talked about what remotes are there just to URL pointing to some other instance of the repo but how do you actually share data.
Jeff Terrell: there's kind of three main commands that you'll want to use.
Jeff Terrell: Get fetch is going to download data from a remote.
Jeff Terrell: And this includes mainly commits but also rafts.
Jeff Terrell: And you have to tell it which remote to download from so you'd say something like get fetch origin.
Jeff Terrell: Get pull is going to do a fetch and then it's going to emerge new commits from a remote branch into your current branch.
Jeff Terrell: So if you said get pull origin main you would be fetching everything from origin and then merging new commits in origin man into your local branch.
Jeff Terrell: and push is kind of the opposite of pull it's going to send commits from a current branch to a remote branch.
Jeff Terrell: So you've got new commits that the origin doesn't or that the remote doesn't know about you're going to push those over to a remote branch.
Jeff Terrell: A tip would be to set a tracking branch for load your local branches with get push and the dash you switch it's going to it also means set upstream.
Jeff Terrell: And what this means is that you can just say get if you're checked out on that branch, you can say get pull and get push without specifying the origin and branch name that you're pulling or pushing to or from.
Jeff Terrell: yellow probably experienced the idea that a push can fail, sometimes.
Jeff Terrell: You get some cryptic error message about non fast forward merges or something like that, and if you don't understand the concepts this doesn't really make sense, but if you understand what what a commit is what a ref is what a remote is then this actually makes a lot of sense.
Jeff Terrell: What happens is that if the if you're trying to push a commit that does not include all of the information that the remote knows about.
Jeff Terrell: Then, if the remote allowed that which you can actually force it to accept it, if it accepts that then you're going to be erasing something that the remote knows about that you didn't know about.
Jeff Terrell: Or that you don't have incorporated in your history and so usually that's a bad idea, usually that means you're overriding your clobbering somebody else's work.
Jeff Terrell: And it's accidentally lost and deleted so that's usually a bad idea, in some cases, you need to do it like I said, you can you can force.
Jeff Terrell: An unsafe push but, by default, the remote is going to disallow that and going to say no, you don't have all the data so at that point, you need a merge strategy to figure out how to incorporate that remote data into your local understanding.
Jeff Terrell: we'll talk about that.
Jeff Terrell: But it key implication of just the whole design of get is that nothing you do is shared until you share it.
Jeff Terrell: And the only way to share information is with get push.
Jeff Terrell: So you can be brave and try things out without worrying about affecting your teammates or breaking something for them, as long as you make sure it works before you push.
Jeff Terrell: Also, I mentioned, speaking of confidence that you there's very little and get that you can do that can't be undone, especially if you're not dealing with the plumbing commands.
Jeff Terrell: we'll talk about the ref log on Wednesday, if we have time and the red flag can.
Jeff Terrell: flag is deep magic it's actually not that complicated but.
Jeff Terrell: It saves well we'll get into it basically it helps you undo complicated things if you get into some really funny situations, knowing what the replicas can help you on do.
Jeff Terrell: Anyway, be brave try things out if you're courageous that's one of the enablers of agility because then you, you have the confidence to experiment.
Jeff Terrell: And, knowing that you are protected from affecting your teammates until you push can help you feel feel braver about trying things up.
Jeff Terrell: Questions about anything here.
Jeff Terrell: Okay, so to review a repo is a local copy of a code base the data is actually in that Doc get directory at the root of the project.
Jeff Terrell: commit is a snapshot of the contents of the directory with some metadata associated.
Jeff Terrell: Working tree is what's actually in your project directory on disk.
Jeff Terrell: might be clean might be dirty.
Jeff Terrell: The index is a staging area to prepare commits to figure out what's going to be committed or not.
Jeff Terrell: branches are also known as refs, and that is simply a reference to a commit nothing more.
Jeff Terrell: head indicates what's currently checked out.
Jeff Terrell: A remote is simply a URL pointing to another instance of the same repo.
Jeff Terrell: And to share data with remotes you would either fetch to bring in information from the remote, you would pull to do a fetch and emerge into your local branch.
Jeff Terrell: Or you would push.
Jeff Terrell: to share your data with or not.
Jeff Terrell: Okay.
Jeff Terrell: Think about i've got a few questions for you.
Jeff Terrell: feel free to answer or not, as you like that i'm not necessarily expecting an answer, but I want you to at least think about the answer to these questions, what does it mean to have a branch checked out.
Jeff Terrell: That means that head is pointing to that rough right to get that.
Jeff Terrell: Any questions about that.
Jeff Terrell: Okay, all right, think about this one what's the difference between a rough and a commit you know this.
Jeff Terrell: Just checking understanding here.
Jeff Terrell: yeah the commit is the snapshot and the ref is pointing to that commit.
Jeff Terrell: To get that.
Jeff Terrell: yeah.
Okay.
Jeff Terrell: here's one that might make make you think a little bit when would you want to do a fetch instead of a poll.
Jeff Terrell: Well, the the pool includes the fetch.
Jeff Terrell: yeah if you need to get a new branch, and you don't know the branch name with Paul, you have to specify the branch with fetch you down that's good point I had I had not actually considered that but you're right.
Jeff Terrell: So i'll just tell you all the new branches.
Jeff Terrell: I answer is, if you want more control over the merge step that'd be another reason.
Jeff Terrell: by default you're going to fit a pool is going to fetch and then merge But what if you want to fetch and then re base, for example.
Jeff Terrell: Then you won't want to do a poll you'll want to do a fetch.
Jeff Terrell: Okay, how about this one.
Jeff Terrell: How are the ideas of cloning and downloading related.
Jeff Terrell: Sagan.
Jeff Terrell: Cloning yeah cloning will get the whole repo that's true.
Jeff Terrell: Other ideas.
Jeff Terrell: Okay.
Jeff Terrell: there's a few things here cloning is only gonna happen once initially when you create your local copy.
Jeff Terrell: Of the repo.
Jeff Terrell: Cloning is a kind of downloading, so I would say it's like a subset of downloading you are downloading data.
Jeff Terrell: But fetches are also downloads and fetches are going to happen on an ongoing basis, whereas cloning only happens initially so Those are a few ideas about how to relate those two.
Jeff Terrell: concepts.
Jeff Terrell: yeah, I just wanted to check your understanding see if people are tracking we feel we feel good about getting the Foundation.
Jeff Terrell: If so, i'll move on okay.
Jeff Terrell: cool.
Jeff Terrell: Alright let's cover a basic collaborative recipe.
Jeff Terrell: i'm going to assume that the head is pointing to maine and remember what this means.
Jeff Terrell: Right, this means that main is the branch is checked out locally.
Jeff Terrell: i'm going to assume that we've already set up a upstream tracking branch for men to point to origin mean.
Jeff Terrell: That was that get pushed with the dash you switch.
Jeff Terrell: And i'm also going to assume that you only have one piece of work in progress, at a time so you're not trying to have multiple threads of development, at least within your local development, environment.
Jeff Terrell: So here's a basic recipe first you pull what's going to fetch the latest code and update your working tree.
Jeff Terrell: menu update the working tree to add whatever features are fixed whatever bugs or make whatever changes to the source code that you need to.
Jeff Terrell: And then you would say get status, which would tell you what which files are dirty.
Jeff Terrell: And it also gives you commands on how to change the index update the index to include those changes.
Jeff Terrell: You might want to say get diff maybe just just get this by itself, or you might want to say get def on a file to see exactly what changed in that file, since the since had.
Jeff Terrell: And if you do want to stage it into the index, then you would say get add on that file.
Jeff Terrell: And you would sort of rinse and repeat to the gets status get diff get add, however many times you wanted to to get stuff into the index.
Jeff Terrell: And once you're satisfied that the index is where you want it to be, then you would say get commit to create a new commit from the index that would also update your.
Jeff Terrell: Local main ref to point to that new commit.
Jeff Terrell: And then you would say get push to update get hubs main raft to include that new commit.
Jeff Terrell: other words to share that content with your teammates.
Jeff Terrell: Now i've probably seen recipes like this before i'm expecting this is probably not anything new, for most of you.
Jeff Terrell: But.
Jeff Terrell: What happens if I actually you know question about this first, are there any questions about this.
Okay.
Jeff Terrell: One problem would be what if you had multiple things in progress.
Jeff Terrell: What if you start one feature and then you're you get to a point, you realize that you need more information from your clients to.
Jeff Terrell: Finish that that feature and your client is not responsive and so you're like well i've got time to spend I just can't make any more progress on this particular feature, what can you do, then.
Jeff Terrell: You basically want to park this thread of development and create it spin up a new thread with doing some other feature.
Jeff Terrell: How do you do that.
Jeff Terrell: Well, first, you can say I kind of highlighted the new commands in green here.
Jeff Terrell: Get switch dash see name this is going to create a new branch named name.
Jeff Terrell: And it's going to check out it's going to point to the same place that had is already pointing to sorry it's going to point to the same commit that had is pointing to that with a new name.
Jeff Terrell: So, in other words, instead of being maybe you have five new commits on main.
Jeff Terrell: When you say get switched ashy name you're going to create a new RAF named name is also pointing to that fifth commit that's new, but now had is pointing.
Jeff Terrell: Had is pointing to name, rather than two main.
Jeff Terrell: Hopefully that makes sense.
Jeff Terrell: Then you can switch back to the main branch you're not creating a branch this time you're switching to an existing branch.
Jeff Terrell: And reset man to point to origin main.
Jeff Terrell: So what's that doing if you had five new commits on.
Jeff Terrell: Your feature branch.
Jeff Terrell: Then this command is wiping out those five commits and getting you back to the last place that you knew about origin man being at.
Jeff Terrell: From there you can continue get pull is going to update your local main branch with anything that's new in origin man you do your changes update the working tree.
Jeff Terrell: Add diff commit.
Jeff Terrell: And you push here, you would need the dash you flag and you need to be explicit about the remote and.
Jeff Terrell: branch name.
Jeff Terrell: But that would actually push things up and set the tracking branch, and then you can switch back to.
Jeff Terrell: Name actually that's that's kind of not quite right.
Jeff Terrell: Sorry, what what I would say is before you commit you would want to switch back to.
Jeff Terrell: Maybe, maybe, maybe even up here, you could say.
Jeff Terrell: Get switch name to get back to the name branch.
Jeff Terrell: Okay, so that's an error in the slides.
Jeff Terrell: Anyway, that's one way to resolve that situation if you if you didn't need to park that threaded development and create a new one any questions about this been.
Jeff Terrell: that's true you you're working tree, you only have one working tree you don't necessarily have a working tree per branch you just have one working tree if you're doing switch dash see name that's going to leave your working tree alone.
Jeff Terrell: And so you don't need to stash or anything else you should be able, just to create the new branch as as even if you have a dirty working tree.
Jeff Terrell: yeah good question.
Jeff Terrell: Okay, so.
Jeff Terrell: Osama says you needed this one good glad this is helpful.
Jeff Terrell: Okay, so, then the new recipe for collaboration would be something like this, assuming that this is kind of.
Jeff Terrell: hang on a second.
Jeff Terrell: Oh right sorry this is this is to fix the problem if you notice you're getting blocked and you want to start new work, this is how you would adjust midstream, but if you knew.
Jeff Terrell: You want it to always have the ability to have multiple feature branches in progress at a single time then basic recipe for collaboration version two that eliminates that earlier assumption.
Jeff Terrell: here.
Jeff Terrell: would be this.
Jeff Terrell: And this, this does not have that same error on it, so this is actually correct.
Jeff Terrell: The new things would be again, you still have it gets switched dash see you do that initially as soon as you pull on your main branch, you would create a new branch based on that.
Jeff Terrell: Do your development and then, once you're all done, you would switch back to main you would merge your feature branch intimate.
Jeff Terrell: And then you could delete your feature branch you don't need that anymore, because those commits are now in maine and then you would push your push main rather than pushing your feature branch.
Jeff Terrell: Questions about this that make sense.
Jeff Terrell: cool.
Jeff Terrell: Okay let's talk about merge strategies.
Jeff Terrell: The second problem with our basic recipe is what if.
Jeff Terrell: You pulled your stuff you did your work and when it came time to push you found out that Sure enough, your notion of what was on origin man was stale.
Jeff Terrell: So when you try to push you got that rejection that says refusing to do a non fast forward merge.
Jeff Terrell: And then you you realize oh okay my one of my teammates is actually pushed something up to origin, since I last pulled.
Jeff Terrell: it's good that the push fails right you don't want to clobber their work, but what do you do about the situation i'm sure you all have faced this at some point if you've been working on any collaborative project.
Jeff Terrell: Re basis one approach yeah.
Jeff Terrell: yeah so here we're going to talk about merge strategies, including me base.
Jeff Terrell: The other is merged, but before we get there, I want to talk about how to do, how to create a log format that's a lot easier to read.
Jeff Terrell: For the command line get in this, you know if you're using a different porcelain maybe you have something like this already that makes it easier to see.
Jeff Terrell: The changes it's very easy to see the history in a concise way, but if you don't have that or if you're just curious about this here's a command that you can run in your command line, and this will add a new alias named El.
Jeff Terrell: To be short for log dash dash dash dash decorate dash dash one line.
Jeff Terrell: So this is a good fundamentally I get log command but it's a good log command with a certain format and certain options.
Jeff Terrell: graph is going to include a sort of ascii art graph of the history of changes like which which parent which.
Jeff Terrell: free to commit which parents, does it have it's actually going to connect all the little dots with ascii art and stuff kind of neat.
Jeff Terrell: decorate is going to show you.
Jeff Terrell: The branch names, if there is a raft that's pointing to that commit it'll include that ref in that one line.
Jeff Terrell: And one line is saying, rather than have.
Jeff Terrell: verbose output, including author name and email and timestamp, and all this other stuff it's just going to have a single line of output for each commit so it's easier to see the structure of how commits are related.
Jeff Terrell: So this is a really useful alias I do this, all the time if i'm on i'm using it on the command line.
Jeff Terrell: i'm going to be saying get l a lot anytime you say get a little show you that view.
Jeff Terrell: And you can also give it multiple refs just like you can with get log and then it'll show you the all the history of all of those refs until at some point, maybe down the chain, a little bit they join up.
Jeff Terrell: And I guess what I forgot to say is that anytime you say get log command typically unless you tell it otherwise it's going to show you everything all the history from head.
Jeff Terrell: whenever you have checked out and it's kind of follow the chain of parent commits all the way up until the initial commit.
Jeff Terrell: Okay, so, for example.
Jeff Terrell: This is what we would see as an example.
Jeff Terrell: In this problem where we have an inner post push from a teammate.
Jeff Terrell: So there's this grandparent commit that we both have in our history.
Jeff Terrell: there's the common parent commits also called the merge base.
Jeff Terrell: We have my commit notice that this is decorated with the branch both both the head metal graph and the ref name that we're currently on hand is pointing to maine and that's what's.
Jeff Terrell: that's what those are what point to this commit.
Jeff Terrell: And then we also have this other commit that we learned about an origin man, we would have had to do it get fetch origin to know this.
Jeff Terrell: So you try to push you get rejected and then you'd say get fetch origin to update your local understanding of what the remote has.
Jeff Terrell: And notice the graph on the left, see this little ascii art stuff each star is a commit and the lines in between are connecting these different commits.
Jeff Terrell: By the way, this information is like the commit message, the first line of the commit message so anyway, this is a really useful view.
Jeff Terrell: At is a synonym for head, so if you don't want to type head out if you're if you're as lazy as I am about that you can just type at.
Jeff Terrell: In here yeah this output is actually specifically from get out at origin main so you have to specify, both in order to see the history of both of those branches.
Jeff Terrell: Does this view, make sense any questions about what's going on here, this is the problem of inner post push from teammate.
Jeff Terrell: Okay it's important that you understand this, because a lot of what i'm about to talk about is not gonna make sense if you don't.
Jeff Terrell: Okay.
Jeff Terrell: So so right, we have two competing theories of what the commit after f6 is.
Jeff Terrell: I have my theory.
Jeff Terrell: Which is that the next commit should be to one.
Jeff Terrell: But origin has a different theory, which is the next commit should be nine seven.
Jeff Terrell: So, in a word, the history is have divergent.
Jeff Terrell: Typically, we would consider origin, as the source of truth, and so we would say that nine seven wins, because it was the first commit to hit origin man.
Jeff Terrell: And so we have to figure out.
Jeff Terrell: What do we do to.
Jeff Terrell: create a history that includes both the changes that are represented by this commit and the changes that are represented on origin man.
Jeff Terrell: In other words, we're trying to reconcile the divergence we're trying to update our local repo to include.
Jeff Terrell: commit nine seven.
Jeff Terrell: make sense.
Jeff Terrell: Okay.
Jeff Terrell: So one approach to do this is to merge.
Jeff Terrell: i'm going to tell you two different strategies for doing this and then i'm going to contrast them.
Jeff Terrell: First, one is to merge, this is just what the get merge command, this is going to incorporate changes from another branch into the current one, so if we're on.
Jeff Terrell: The our main branch and we said get merged origin man, giving it that remote branch name that would actually work.
Jeff Terrell: So um.
Jeff Terrell: yeah.
Jeff Terrell: I guess I didn't really want to talk about this, but I guess.
Jeff Terrell: i'm going to skip it for now.
Jeff Terrell: What happens in this case is that we create a new commit with two parents.
Jeff Terrell: Remember that commits can have more than one parent.
Jeff Terrell: And if there were no incompatible changes between those two commits then get will handle it automatically, but if there is something that was incompatible that get can't automatically resolve you'll have to do you have to fix the merge conflict we'll talk more about that later.
Jeff Terrell: And then you'll get a history that looks like this.
Jeff Terrell: All right, we still have nine seven.
Jeff Terrell: We still have to one now we have a new merge commit that really doesn't have any changes by itself, it just has a commit with two parents in it.
Jeff Terrell: So now seven six is the commit that includes nine seven and now if we were to say get push that would work, because the origin is going to say.
Jeff Terrell: you're trying to push seven six okay oh yeah I see you know about nine seven already, and you have incorporated that into your history we're good to go.
Jeff Terrell: And this history as nonlinear.
Jeff Terrell: Right you can't you can't make a line from these commits because now we have a commit with two parents.
Jeff Terrell: So we'll talk more about that in a minute.
Jeff Terrell: approach number two is to rebates actually before I talk about that any questions about the merge.
Jeff Terrell: Okay.
Jeff Terrell: approach to is to replace.
Jeff Terrell: And the way that you might talk about this, is to replace your commits onto origin main number origin main as the remote branch has committed at that you didn't know about.
Jeff Terrell: You can also say rebate a top origin man.
Jeff Terrell: So, starting from the same place, the history divergence after f6 I have commit to one origin has committed nine seven.
Jeff Terrell: The way rebasing is going to work is that first i'm going to push the changes represented by going from f6 to to one onto a stack.
Jeff Terrell: so effectively be to get diff output, if you said get diff from here.
Jeff Terrell: or sorry, maybe get show that show that command that will show you the full def output.
Jeff Terrell: So we're going to push those changes onto a stack.
Jeff Terrell: And we're going to keep doing that, until we get down to the merge base, which is the nearest common ancestor of both branches.
Jeff Terrell: Once we get there we're going to fast forward.
Jeff Terrell: up to nine seven and we'll continue fast forwarding all the way, until we get to origin man.
Jeff Terrell: And after we get there, then we will replay the changes from our stack in reverse order.
Jeff Terrell: So in this case, we only had one set of changes so we would replay the changes that go from f6 to to one on top of nine seven.
Jeff Terrell: And, as a result, we would end up not with Okay, here we had two one was our commit and the remote one was nine seven we still have nine seven.
Jeff Terrell: But now we have a different address for the same set of changes as we had in our branch.
Jeff Terrell: Two different address, because the parent commit changed so therefore the content of the commit changed.
Jeff Terrell: But these are, this is the same set of changes, and now we have a nice linear history.
Jeff Terrell: And now, if we push.
Jeff Terrell: will be telling the origin remote hey i'd like to push for a up to you.
Jeff Terrell: And the origin says Okay, let me check the history oh yeah I see, this is just one new commit compared to what I have so yeah sure I can accept that, let me update my branch and we're good to go.
Jeff Terrell: So that makes sense ribbit racing makes sense.
Jeff Terrell: By the way, have you all seen rebasing before.
Jeff Terrell: Some of you have.
Jeff Terrell: view okay.
Jeff Terrell: In the interest of time i'm going to skip this, but if you let me briefly show you if you're not quite comfortable with those ideas, yet.
Jeff Terrell: This is the sort of standard book it's online for free about get.
Jeff Terrell: And section three six talks about rebasing and it has some good examples to walk you through how this works some nice graphics and everything, so if you're curious, and this is kind of a more complex example if you're curious, I recommend that resource.
Jeff Terrell: So the history is created by merge versus three base.
Jeff Terrell: are different.
Jeff Terrell: right here, we have.
Jeff Terrell: A nonlinear history.
Jeff Terrell: On the left with with get merge.
Jeff Terrell: But here we have a linear history and we only have four commits on the right, instead of five on the left, because we on the left, we needed that extra merge commit that really was just about having two parents.
Jeff Terrell: Okay, so to round out the discussion of merge strategies, I want to just give my opinions about which one to pick these are only opinions their opinions, based on a lot of experience so i'd like to think they're worth something, but they are only opinions.
Jeff Terrell: So if you're trying to decide, is our team going to merge or replace, for one thing you could let everybody do their own thing that's fine, but if you wanted to standardize your approach and which one would you choose.
Jeff Terrell: rebasing is a little harder to understand it and merging so that's important to keep in mind.
Jeff Terrell: It takes a little bit of time to get used to the idea of rebasing to understand the concept and know how to do it.
Jeff Terrell: But rebasing produces nice linear histories that are easier to read and reason about.
Jeff Terrell: Also rebasing it's important to note does involve rewriting history, in other words the log of what has already happened in the past rebasing is going to change that.
Jeff Terrell: you're going to take a commit that happened chronologically before and you're going to replay it as though it happened now.
Jeff Terrell: And so we should be careful with that, but some simple rules suffice to still be sufficiently careful in a collaborative environment.
Jeff Terrell: While rebasing and i'll talk about that in a bit.
Jeff Terrell: there's a bit of a philosophical divide on this issue you'll have people i'd be interested to hear actually if you talk to your mentor about this, whether they agree with me or not, and they might disagree, this is definitely still something that the Community has varying opinions on.
Jeff Terrell: But the way that people view it is either they're they're thinking about get as a record of what actually happened on the project.
Jeff Terrell: In which case they're going to be more likely to do emerge, because that more accurately reflects the fact that you are merging more work into something that already happened.
Jeff Terrell: or they're going to view it as history.
Jeff Terrell: Which is an order telling their up right you don't ever read a history book and it's just a chronological record of all the events you're reading a history book and it's like it's telling the story in a way that makes sense it's intended for consumption by humans.
Jeff Terrell: And so I tend to prefer get as history and ordered telling their off.
Jeff Terrell: And the reason I prefer that is actually the same reason that I think it's worth refactoring your code, even if your code works and gets the job done and is correct, you refactor it because code is read a lot more than it's written like by humans.
Jeff Terrell: And so you want to spend a little bit extra time making the expression of the code more readable, so that any human that needs to read and understand it later can more easily.
Jeff Terrell: So, for the same reason, with get I tend to prefer rebasing yeah i'm going to spend a little bit of extra time doing the base.
Jeff Terrell: I did have to climb that initial learning curve to learn what every base was initially, but I think that's worth it, because the history that I produce is a lot easier to read than if I had done merge commits.
Jeff Terrell: linear history is also have other benefits for example if you're ever doing a by section which i'll talk about next time.
Jeff Terrell: Then.
Jeff Terrell: linear histories are nice for that now somebody who disagrees with me would say that merge is easier to do and less dangerous because you're not rewriting history.
Jeff Terrell: And that would be true they might also say that you don't really read the history that often are the logs so you're not really gaining a lot from it.
Jeff Terrell: So it depends.
Jeff Terrell: yeah if you do make a policy on that consider you know discuss or, if you want to then that might be a conversation with your team, maybe with your mentor to.
Jeff Terrell: Okay i'm going to skip this but I need to jump to take away questions, so let me start that up and after you finish ticket with questions you can go i'll see y'all on Wednesday.