6.1 KiB
.. 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.
Requirements
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.
$ 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.
$ 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.
$ 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
$ 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.
$ 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.
$ 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
$ 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.