+++
title = "Git! Remotes…"
author = ["Elia el Lazkani"]
date = 2019-08-07
lastmod = 2019-08-07
tags = ["rebase", "remotes", "git"]
categories = ["revision-control"]
draft = false
+++

In the previous post, we talked about branching and merging. We will say a few last words on branches in this post and dive into remotes.

What are remotes ? What are they for ? How are they used ?

Coming right up.


## Requirements {#requirements}

In this post, we will need another requirement.

-   First, you obviously need _git_.
-   Second, you will need a git repository on a git server. Easier way is to create an account on [Gitlab](https://gitlab.com), [GitHub](https://github.com) or other similar services.


## Branches {#branches}

I have a few more things I need to say about branches...

If you came to the same conclusion that branches in _git_ are _cheap_, you are correct.
This is very important because this encourages you to create more branches.
A lot of short living branches is a great way to work. Small features added here and there.
Small projects to test new features, etc...

Second conclusion you can come up with from the previous post is that the _master_ branch is not a _special_ branch.
People use it as a _special_ branch, or the branch of **truth** by convention _only_.

I should also note that some services like **Gitlab** offer master branch protection on their own which would not allow master history overwriting.

The best next topic that comes after _branches_ is a topic extremely similar to it, **remotes**.


## Remotes {#remotes}

The description of `git-remote` from the [manual page](https://git-scm.com/docs/git-remote) is simply

> Manage the set of repositories ("remotes") whose branches you track.

That's exactly what it is.
A way to manage _remote_ repositories.
Now we will be talking about managing them in a bit but let's talk about how to use them.
I found the best way to think to work with them is that you can think of them as _branches_.
That's exactly why I thought this would be best fit after that blog post.


### Listing {#listing}

Let's list them on our project and see what's what.

```text
$ git remote -v
```

Okay! Nothing...

Alright, let's change that.

We don't have a _remote_ repository we can manage.
We need to create one.


### Adding a remote {#adding-a-remote}

So I went to **Gitlab** and I created a new repository.
After creating the repository, you will get a box with commands that look similar to the following.

```text
$ cd existing_repo
$ git remote rename origin old-origin
$ git remote add origin git@gitlab.com:elazkani/git-project.git
$ git push -u origin --all
$ git push -u origin --tags
```

The first command is useless to us.
The second is renaming a remote we do not have.
Now the third command is interesting.
This one is adding a remote called **origin**.
We need that.
The last two commands are there to push everything to the remote repository.

Let's copy that command and put it in our command line.

```text
$ git remote add origin git@gitlab.com:elazkani/git-project.git
$ git remote -v
origin  git@gitlab.com:elazkani/git-project.git (fetch)
origin  git@gitlab.com:elazkani/git-project.git (push)
```

If you look at that output carefully, you will notice that there is a _fetch_ link and a _push_ link.

Anyway, let's push.


### Push {#push}

```text
 $ git push -u origin --all
 Enumerating objects: 3, done.
 Counting objects: 100% (3/3), done.
 Delta compression using up to 4 threads
 Compressing objects: 100% (2/2), done.
 Writing objects: 100% (3/3), 317 bytes | 317.00 KiB/s, done.
 Total 3 (delta 0), reused 0 (delta 0)
 To gitlab.com:elazkani/git-project.git
 * [new branch]      master -> master
 Branch 'master' set up to track remote branch 'master' from 'origin'.
```

We have pushed all of our changes to the remote now.
If you refresh the web page, you should see the repository.

So what happens if someone else made a change and pushed to it, or maybe it was you from another computer.


### Pulling from a remote {#pulling-from-a-remote}

Most people using git usually do `git pull` and call it a day.
We will not, we will dissect what that command is doing.

You might not know that you can configure `git pull` to do a _rebase_ instead of a _merge_.
That's not important for you at this stage but what's important is the clue it gives us.
There is a _merge_ in it.

What `git pull` actually does is a `git fetch` followed by a `git merge`.
So just like `git push`, `git fetch` will download the changes from the remote.

If the _fetch_ is followed by a _merge_, then where are we fetching to and merging from ?

This is where thinking about remotes as branches comes in.
Think of `origin/master` as a branch, a local branch, because in some way it is.

So let's fetch.

```text
 $ git fetch origin master
 From gitlab.com:elazkani/git-project
  * branch            master     -> FETCH_HEAD
```

But we don't see any changes to our code !

Ahaaa ! But it did get the new stuff.
Let me show you.

```text
$ git diff master origin/master
diff --git a/README.md b/README.md
index b4734ad..a492bbb 100644
--- a/README.md
+++ b/README.md
@@ -2,3 +2,7 @@

This is an example repository.
This repository is trying to give you a hands on experience with git to complement the post.
+
+# Remote
+
+This is the section on git remotes.
```

See ! Told you.
Now let's get those changes into our master branch.
You guessed it, we only need to merge from `origin/master`

```text
$ git merge origin/master
Updating 0bd01aa..4f6bb31
Fast-forward
 README.md | 4 ++++
 1 file changed, 4 insertions(+)
```

That was easy wasn't it ?


## Let's have a little chat, you and me ! {#let-s-have-a-little-chat-you-and-me}

You can have multiple remotes.
Make a good use of them.
Go through all the different methodologies online to work with _git_ and try them out.

Find what works for you.
Make use of branches and remotes.
Make use of merging.


## Conclusion {#conclusion}

After talking about remotes in this post, you have some reading to do. I
hope I've made your journey much simpler moving forward with this topic.