Pull

[00:00:00]
>> All right, so you can also use Git pull, fetching is always a good idea, keeps everything up to date. I always try to fetch often, see when changes happen, and then pull in any changes I want. Git pull is just a convenient form of what we just got done doing, fetches the changes, and then merges those changes into your branch.

[00:00:16]
And so you can do git pull, the remote, and then the branch name. You can also for convenience, just use git pull and it will use the current one. Back in the day like 15 years ago or whenever I started using git when you'd use git push it push all of your branches off, it was fantastic.

[00:00:32]
It would just send everything, so when you were just on your own branch and you get pushed in your changes to the mainline. You actually just got done updating the Company's main repo with no testing or anything, man, those were just the days absolutely a lot of fun.

[00:00:46]
And so prom, let's add one line at the end of the README and hello-git and with a commit message, a remote change. But before you do that, I've noticed something and I want to make sure we don't have any accidents. If you merged or cherry picked changes into your trunk, you will have this extra commit.

[00:01:03]
And I just want to make sure everything goes swimmingly from here on out, so if you've done this, has everyone done this, right? Because it will diverge slightly from what's on the screen, because I didn't include that when I was printing everything out, so if you've done that, it's okay.

[00:01:18]
I just want to make sure you know that it's Is there, and so if it's slightly diverging, there's no problems. All right, so let's add the one line at the end of hello git on your remote trunk. So I'll navigate over to hello git, I will echo in a what is it, a remote change at the last line of READ ME.

[00:01:36]
At this point, it becomes important to make sure you're doing the same changes because we're going to get into some trouble here soon. So I'm going to go vin READ ME and go all the way down here, add this in, add it, commit it, a remote change, there we go, hopefully everyone can do the same thing to hello-git.

[00:02:02]
I did not use status, remember again, it is good practice to use status. Since these are so trivial, I probably won't use status all the time, but typically I never git add without doing a git status. And for those that don't know, git add dot adds every file starting at my directory, that git can find that has changes.

[00:02:22]
So usually you do like git add a path to a specific file, but for convenience you can do git add dot long as you have a good git ignore set up and everything's really nice. All right, now we're gonna execute a git pull on the remote git, so I want you to open up remote git and just go git pull, right?

[00:02:43]
Because we have trunk in remote, we have trunk in hello, hello has been updated, we just want to pull in the change, it's going to error, I want you to tell me why it errors. So I'm gonna switch over to remote, git pull, the air is pretty simple.

[00:03:04]
It's just because you have a branch named trunk doesn't mean that git's going to just magically assume that the trunk on another branch is the same one. You have to set tracking information, you have to tell git which remote are you linking. This branch too, because you could technically have a bunch of remotes, which remote should it choose?

[00:03:25]
And so you have to have some sort of way to set the exact thing that you're tracking. And so the easiest thing for us to do is to take this line right here with git branch execute it, and we have origin, right? We only have one remote, and it's literally saying git branch, set-upstream-to origin/trunk and I'm going to do it for branch named trunk.

[00:03:46]
And so now that I've done that, I can now pull in those changes because now it knows when I execute git pull. It now knows where to pull stuff in from And back in the old days, git pull would just pull all the things, right? I'm glad those days are gone man, did I mess up some serious repos back then.

[00:04:08]
All right, so hopefully you can think about Github now, and you realize what Github is, it's just your repo on someone else's computer. That's all really is, we're doing the exact same things you'd be doing with Github, except we're just doing it locally, and so again, hopefully the magic is now even less.

[00:04:27]
Now, there's specific ways in which you can communicate to Github that we're obviously not doing here, but it's less magical. All right, so what about rebase? Well, typically whenever I pull changes in from my authority repo, I prefer to rebase the changes in, the reason why? Is that again, I like a nice clean history any changes I'm making I prefer my changes at the tip.

[00:04:49]
Because if I want to do testing again, I don't want my changes somewhere deep within the history, I wanted exactly at the end where I could edit those. I could squash those, I can change them, they're still my changes until I commit them to the public repo. And so that's how I like to live I think rebase is the best, we'll go over sort of why it's the best, I know it's my opinion, but I believe it's the correct opinion.

[00:05:12]
Also, it doesn't really matter whether you use merge or rebase if you have a long-lived feature branch life sucks, so there's just no way around that. Whether you're using rebase or merge, it's just going to be a pain, so there's not like a super special strategy to get around that.

[00:05:28]
By the way, so the reason why I personally like the rebasing approach is that every now and then I need to revert something. If I am under really strict practice of always moving my changes to the front, with rebate, I'm always squashing them down to a singular commit.

[00:05:44]
If that one day does happen to come by where you actually messed up production a little bit, a singular commit with no merge commits with none of that is very easy to revert. But if you have six commits with several merge commits in between, reverting is just more challenging.

[00:05:59]
Because now you're going to have to figure out how to pull out all that information and make sure that it is now updating just a lot more. It's a huge pain, so this is why I choose this way, it's very intentional. I'm planning for failure as opposed to planning for success, which is why I use rebase.

[00:06:15]
By the way, if you like rebase and you prefer to use it, you can actually just add it to a config. I actually don't have it set as a config, I always like to manually, I don't know. But you can just simply do git config add global pull rebase true, and it will always do that.

[00:06:30]
Don't do that now because, well we're going to do some merge and then some rebase and as well, so I just want you to know that that's a thing. For now, you can just do git pull --rebase, and it will pull it and do a rebase as opposed to a merge.

[00:06:46]
I even worn myself because I knew I'd goof it up, it's just so easy to do that.