Check out a free preview of the full Everything You'll Need to Know About Git course

The "Remote Git & fetch" Lesson is part of the full, Everything You'll Need to Know About Git course featured in this preview video. Here's what you'd learn in this lesson:

ThePrimeagen explains the concept of remote Git and how to add a remote repository to your local repository. He demonstrates how to initialize a new repository, add a remote repository using the "git remote add" command, and fetch the changes from the remote repository using "git fetch". How to merge the changes from the remote repository into the local repository using "git merge" or "git pull" is also demonstrated in this lesson.


Transcript from the "Remote Git & fetch" Lesson

>> Do you feel more powerful now? Is your Git knowledge growing, hopefully? Well, now we're gonna talk about remote Git, right? Often we need changes that have been created by our fellow frenemies. Frenemies, of course, is because they make code and it hurts your feelings or hurts production's feelings.

But how do we get their changes into our repo? How do we push our changes to their repo? Here's one thing that kind of, I guess, will surprise most people, is that it doesn't have to be remote. It doesn't have to be on GitHub. I know that might be strange, because often when people think of Git, they think of GitHub.

They don't actually think of Git as its own thing, and then GitHub as a means to store Git. They think of Github as Git. So you may have never really used Git as a remote. You just really probably have never done this. Why would you have the same thing twice?

A remote is just simply a copy of the repo somewhere else, that's it. So I want you to create a new folder wherever you create folders, and let's call it remote-git. And I want you to initialize it with git init. So I'll jump in here and go over to my personal directory.

I'll make the remote-git and then I'll go into remote-git, there we go. And I'll go git init, there we go, it's its own repo right now. Remember, this is distributed version control, okay? The files can be on other people's computers, too. And so, let's add a remote to hello-git, so, adding a remote goes git remote add, the name of the remote, and then some sort of URI of some sort.

It can be an SSH item, it can be just a path on your computer. So let's add hello-git as the remote. By the way, you should name it origin. Typically, good practice is, the authority repo is typically named origin. So I'll do it right now, I'll go git remote add origin, and I'll just literally go ../hello-git.

I can check it out with git remote -v, there we go. You can see that the other repo is just simply a relative file. So, hopefully, everyone did that. git remote dash -v will just verbosely list out all of your remotes. You can also just do git remote, but I don't find that very useful, right?

I didn't do anything there. And so if you do the -v, it'll also give you the path. So if you have GitHub, you'll see the GitHub address when you do a -v. Gitisms, typically this is how I set up the naming for my repos. Is if I have only a singular authoritative repo, meaning that there is mine plus the one I'm pushing up to, say, on GitHub, then I'll call that one origin.

If I have a fork of the authoritative repos, so this is typical when you're at like a job, you have your main one, and then you have your fork. I typically call my fork origin, and the authoritative one, the true one, the one true repo, I call that one upstream.

And you'll see that a lot, people will call it upstream. Sometimes instead of using origin, I use me, cuz it's just, I don't know, it's kinda fun. git push me, I just think it's stupid and fun. So there's me, so that's kind of like my general naming convention is to use origin for the authoritative one, unless if it's a personal fork, and then do upstream for the authoritative one.

All right, you'll notice our default branch remained, it's trunk again, right? We didn't set the option again, we didn't do anything, it just keeps on remaining. So now trunk was yet again, even though this is a very different trunk, this trunk right here is from the default naming.

Now we need to merge the changes from hello-git into our new repo, remote-Git. So we're gonna do that, but first we need to fetch. We need to fetch because we want to be able to get all that object information from hello-git. So if we go here and I go find .git, you'll notice that it's just, again, this pristine empty one.

Whereas if I do that in hello-git, find .git, well, it has a lot of stuff in there, right? So I want all of that in remote-git. So to do that, you need to be able to execute git fetch. git fetch will fetch your remote's changes, and it'll put it inside the git state management.

I bet you could even find where it stores things. So I'll go like this, git fetch. And you'll see, look at that, I got bar, I got foo, I got foo-rebase-trunk, trunk, trunk-merge-foo. We got all of those branches when I did that fetch. Okay, cool, so now I'm up to date, right?

>> No.
>> No, great job, all right.
>> [LAUGH]
>> I love this, this is fantastic. All right, so let's use git log and verify that the remote trunk has been correctly merged into our git state. So I'll go like this, git log, our branch doesn't even have any commits yet.

So our trunk is still diverging from hello-git. And the reason why is we've only fetched the changes, we haven't merged the changes into ours, we haven't updated anything. That's why often when you pull, you'll see update with fast forward if you have your main line. Cuz you don't make changes to your main line cuz you're all great engineers, I can tell right away.

No one's doing that, right? No one's doing merge, right? Okay, so anyways, right now we haven't updated anything. Okay, so that means we need to do something, but by the way, remember, you can always do a git log. So I can go git log, remote name, which is origin, and then do any branch name, right?

Because we fetched everything in, so we can actually see the log of other remotes. So I can go origin trunk, and there we go. Definitely my best work at the end of this. It's fantastic, X, Y, E, D, A, awesome. If you did one line, I actually pasted one line in there.

I pasted the wrong thing in there, I actually executed --oneline, that's what it should look like. All right, awesome. You can validate this is true by, when you look right here, you'll notice that trunk is 9b6e43. I can go to hello-git and do git log -1, 9b6e, same commit SHA, right?

It now exists on two computers, or in two repos. So there we go, okay, we are now kind of in line. If you wish to see what branches came down with git fetch you can do git branch -a. So if I go back to remote-git and I go git branch -a, you'll see all branches.

And so the ones that start with remotes, those are all the remote branches, then you'll have any of your local ones. Right now we have nothing, we just have the default empty one that has no commits to it. So we have no branches, effectively, and just a bunch from the remote.

All right, so let's update trunk with origin/trunk. And then let's use git log to see those commits have been merged. So what do we do here?
>> origin/trunk?
>> We can git pull origin/trunk, true. We also have all those changes. So we can just git merge origin, the remote, trunk.

Now that I've merged those changes from my internals which I just got done fetching from another repo, I can use git log --oneline. And look at that, my trunk now points to the same spot that this trunk does

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now