Collaborating and using remotes with Git and gmaster

Wednesday, February 28, 2018 1 Comments

In the last post, we talked about the first steps for using Git with gmaster and covered the first steps with both. For example, how branching and source-control can aid how you control versions of your work. And, how you can go even further and go back in time if you want to. This is the kind of magic found in source-control systems :)

Git is a distributed source-control system and it can keep a copy of the entire repository in each device that you want or have permissions to. This way, it can help teams collaborating with the same source-code base. You can even use this feature if you just want to share your source-code between your personal and work computers or as a backup copy.

Here are some scenarios that we will explore with Git:

Scenarios

Everytime that we have more than one repository (or copies from this repo), the one we are currently working on is known as the local repository and the other ones are called remotes.

How to use remotes with Git and gmaster?

In this section, we will cover how to use remotes with gmaster. This is one of the most relevant tasks if we think about collaborating over source-code. Why? Because this feature allows us to send and receive commits from the remote repo.

Tip: In this section, we are going to cover how to use remotes with Github. But, you can use any other provider, such as Bitbucked, Gitlab, TeamServices and others. To follow along with this how to, it would be a good idea to have an account in Github (github.com if you don't have one) and we are good to go ;)

Usually, when we deal with remotes, we need to authenticate with these servers. Git supports two modes: HTTPS and SSL. In HTTPS mode, we use our username and password. In SSL, we use a pair of public/private keys. A really nice feature of gmaster is we don't need to worry about usernames/passwords or keys. We just need to authorize gmaster to use our Github account in our browser - it's way easier.

If the remote repository is public, (like all open-source repos in github), we just need to authenticate when we are sending or pushing changes to it.

Creating a new repository in Github

Let's create a new repository in Github. This way we can send our commits to a remote and even share the code with other developer friends.

Creating a new repository in Github is a simple task. After you're logged in, just click the + icon in the header. You can create a new repo gmaster-remotes like this one:

Creating a new repo in Github

Adding the remote repository in gmaster

gmaster lists our remote servers in left-lower part of the screen. To add a new remote, we just need to click on the green +:

Remotes in gmaster

Then select the Github tab and click Login with Github. This will open a new web browser window asking us to allow gmaster to access our account:

Allowing gmaster in Github

Just grant it by clicking "Authorize gmasterscm".

You will see a success message in the browser and the gmaster screen updates showing your github repos and the newly added remote server:

Remotes list

Select your repo, for example our recently created repo gmaster-remotes, and click Clone repository. (You can choose where you want to keep the local version of this repo too). After cloning, we can click Open.

Note that we are cloning the repo to our machine. So we are copying the entire repo from remote to our local machine. If we haven't created the repo first, we could do it now too inside gmaster, just heading to Create repository tab.

Now we have the same screen that we covered in the last post: Branch Explorer, but with one difference - we have another indicator that shows the location of the origin/master. Origin is commonly used as the name of our first remote server.

Branch Explorer

Committing some changes to local repo

To see some changes going to the remote, I will change the README.md file locally and commit its changes. (We did this in our last post). Analyzing our Branch Explorer again, we can see that the master (local) is now ahead of the origin/master.

Branch Explorer - Committing

Sending/receiving changes to/from remote (aka push/pull)

Now, our local repo has the most recent updates and we need to send these to our remote. This operation is called "push". In gmaster, this operation is super easy too. We just need to click Push in our Branch Explorer screen. Notice, that now the Branch Explorer shows that the master local and origin is at the same point in time.

Bringing changes to the local repo

To simulate changes made by another developer or in another device, we can directly edit the README.md file in Github. To do this, open your Github repo in your browser, click README.md and select edit. Make some changes in content and click "Commit changes". Now, we have a remote repo with a more recent version than our local one. It's time work on this :)

In Branch Explorer, click the Pull button. Now, we can see that we have one more commit on the screen. (The one we created directly in Github).

Note: We changed the README.md in Github using the same user, but the process is the same if another developer from our team made the change.

But what if I had a change in local and in remote?

If before we pull the changes from the remote, we changed something in our local repo too, we need to merge those commits. This is easier because both repos (local and remote) have some commits in common.

To test this, let's create a new commit in remote. (Using the same process we did before using the Github web interface). And, let's change and commit something locally too. Now, we have two commits that share the same parent commit but that are completely different. Let's pull the remote changes again.

Branch Explorer - Local and remote changes

Here is where the magic really happens :) When we pulled the changes from the remote, git noticed that they share the same parent commit and considered it a new branch and already merged the changes back to the local commit. Wow! To finish the process, we just need to push to the remote again and both repos will share the same contents.

But what if I had a conflict?

This would be a breeze too. The only difference is that git/gmaster would not be able to auto merge it. We would need to fix the conflicts first and then commit our new merge.

Wrapping up

Now it's your time to try! Experiment using these processes on your own. You will notice that it is easy, and it will make you more confident in sharing code. And, gmaster will make you feel even more confident by visually showing you how Git dealt with the changes.

See you in our next post :)

We develop gmaster, a Git GUI with semantic superpowers. It parses the code to really understand how it was refactored and then diff it and merge it as a human would do, matching methods instead of lines.

If you want to try it, download it from here.

We are also the developers of SemanticMerge and Plastic SCM, a full-featured version control.

1 comment:

  1. There seems to be no mechanism to access a private remote GIT repository?
    Not everyone uses public or commercial repositories!

    ReplyDelete