189 lines
6.1 KiB
Org Mode
189 lines
6.1 KiB
Org Mode
#+BEGIN_COMMENT
|
|
.. 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
|
|
#+END_COMMENT
|
|
|
|
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.
|
|
|
|
* 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 [[https://gitlab.com][Gitlab]], [[https://github.com][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 [[https://git-scm.com/docs/git-remote][manual page]] is simply
|
|
|
|
#+BEGIN_QUOTE
|
|
Manage the set of repositories ("remotes") whose branches you track.
|
|
#+END_QUOTE
|
|
|
|
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.
|
|
|
|
#+BEGIN_EXAMPLE
|
|
$ git remote -v
|
|
#+END_EXAMPLE
|
|
|
|
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.
|
|
|
|
#+BEGIN_EXAMPLE
|
|
$ 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
|
|
#+END_EXAMPLE
|
|
|
|
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.
|
|
|
|
#+BEGIN_EXAMPLE
|
|
$ 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)
|
|
#+END_EXAMPLE
|
|
|
|
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
|
|
#+BEGIN_EXAMPLE
|
|
$ 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'.
|
|
#+END_EXAMPLE
|
|
|
|
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.
|
|
|
|
#+BEGIN_EXAMPLE
|
|
$ git fetch origin master
|
|
From gitlab.com:elazkani/git-project
|
|
* branch master -> FETCH_HEAD
|
|
#+END_EXAMPLE
|
|
|
|
But we don't see any changes to our code !
|
|
|
|
Ahaaa ! But it did get the new stuff.
|
|
Let me show you.
|
|
|
|
#+BEGIN_EXAMPLE
|
|
$ 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.
|
|
#+END_EXAMPLE
|
|
|
|
See ! Told you.
|
|
Now let's get those changes into our master branch.
|
|
You guessed it, we only need to merge from =origin/master=
|
|
|
|
#+BEGIN_EXAMPLE
|
|
$ git merge origin/master
|
|
Updating 0bd01aa..4f6bb31
|
|
Fast-forward
|
|
README.md | 4 ++++
|
|
1 file changed, 4 insertions(+)
|
|
#+END_EXAMPLE
|
|
|
|
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.
|