193 lines
6.2 KiB
ReStructuredText
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.
|