Git Remote post addition

posts/revision-control/git-remotes.rst

@@ -0,0 +1,193 @@
+.. title: Git! Remotes...
+.. date: 2019-08-07
+.. slug: git-remotes
+.. updated: 2019-08-07
+.. status: published
+.. tags: git, revision-control
+.. category: revision-control
+.. authors: Elijah 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.