This repository has been archived on 2023-06-11. You can view files and clone it, but cannot push or open issues or pull requests.
blog.lazkani.io-20200902-hi.../posts/revision-control/git_remotes.rst
Elia el Lazkani 99a5aedd74
Adding the borg tag to the borgbackup post
Minor change to the name everywhere for consistency
2020-02-17 23:24:01 +01:00

193 lines
6.2 KiB
ReStructuredText

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