Git Remote post addition
This commit is contained in:
parent
0ae7afce26
commit
97e2714495
1 changed files with 193 additions and 0 deletions
193
posts/revision-control/git-remotes.rst
Normal file
193
posts/revision-control/git-remotes.rst
Normal file
|
|
@ -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.
|
||||
Reference in a new issue