Yes, I went there.

This is one command that is super neat and it’s because of what it can do in conjunction with the git clone or git remote commands. Previously I went over the checkout, clone, and init commands which sort of led to this. A little bit. And the reason I say that is because if you read the clone post, you would know it does a fetch command internally.

This is one command that wasn’t really known to me until I started working with other developers and there were anywhere from five to 15 branches of development happening all at once. Yes, that is a lot to track. Features and bug fixes all over the place. And that was just from one repo. The company had several other repos which were similar in nature.

So, let’s take a look over what docs has to say about the command.

Fetch branches and/or tags (collectively, “refs”) from one or more other repositories, along with the objects necessary to complete their histories. Remote-tracking branches are updated (see the description of below for ways to control this behavior).

So it fetches branches and tags from one or more repositories. This is the part I really want to emphasize here. The or more, part of that. And it’s because you can pull in objects from other repositories which can be super nutty and potentially dangerous if you aren’t sure what you are doing. You know, like a lot of things in software development when you know just enough to be dangerous.

The best part of the command is that after it retrieves those it doesn’t commit changes like a pull command does. The even cooler part being that you can pass an additional repository. Or if you are just wanting to look at something super quick you can pass along a url of a public repo. I tried this out testing the WordPress repo.

There is a file inside of the .git folder that is then populated with some information that we can later use as seen on the following image:

Terminal results of the cat command.

That first long string is the commit hash that correlates to the latest commit of the pulled, or fetched, repo. The origin of that can be seen on the right. And the cool part is that you can then use a checkout command to cause a little more chaos.

A random example of checking out the login file from WordPress core can be seen in the following image.

Example code of running git checkout for a single file.

This command can really be used for quite a bit of damage if you don’t know how things work and the thing to remember is that there are also other commands that can help get you unstuck when working with git. Just like this little series I do want to get a few others posted here because I know it will help me focus and maybe help somebody when it comes to getting better are git.

On to the next command!


2 responses to “Making fetch happen”

  1. So in regards to the multiple branches aspect – what would you consider as too many branches – i have a habit of keeping branches for a bit longer because im trying to wrap my head around some of these “fixes” or rather baindaid fixes.

    As always great post Jose!

    1. Ideally you’d want to prune those once they get merged. You can find out which branches have been merged by running: git branch --merged

      The one command you may want to look at is the git diff and that’s because you can pass hashes and paths to that to see what changes were made.