blog.lazkani.io-20200902-historical/posts/revision-control/git_remotes.rst

.. title: Git! Remotes...
.. date: 2019-08-07
.. slug: git-remotes
.. updated: 2019-08-07
.. status: published
.. tags: git, revision-control
.. category: revision-control
.. authors: Elia El Lazkani
.. description: Let's have a deeper look at remotes
.. type: text

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.

.. TEASER_END

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
========

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
=======

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
-------

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

.. code:: 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
---------------

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.

.. code:: 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.

.. code:: 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
----

.. code:: 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
---------------------

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.

.. code:: 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.

.. code:: 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``

.. code:: 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 !
======================================

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
==========

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.