diff --git a/posts/revision-control/git-remotes.rst b/posts/revision-control/git-remotes.rst new file mode 100644 index 0000000..4d0a5c8 --- /dev/null +++ b/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 `_, `GitHub `_ 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 `_ 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.