Getting started with gmaster and Git

Wednesday, February 14, 2018 0 Comments

Git is a powerful way to share and control source-code. It can keep track of source-code, its changes and collaborate with other developer's safely. But, unfortunately, most of the client tools that can communicate with Git are all based on command line (aka shell or prompt).

Remembering all the Git commands and their parameters are difficult and very hard on your brain. A branch-based approach becomes pretty hard to see and you can miss the whole overview of dependencies and relation between branches.

This is why a graphical interface client for Git can transform and improve your development process. And gmaster can take this to the next level. In this post, we are going to cover the first steps with gmaster and you will be able to see how much detail you miss by not using gmaster.

Installation

First of all, you need to install gmaster. Just click here and you are good to go. Right now, we only support Windows but we are adding new platforms very soon.

Welcome gmaster :)

The first screen in gmaster allows you to select which repository you want to work on. You can search for local repositories, create new or just clone an existing one. And gmaster starts an auto scan in your local filesystem looking for possible local repositories. Wow :)

gmaster welcome screen

Creating a new local repository

As you might already know, Git is a decentralized version control system. That means you can, besides the more flexible ways to work, create a new repository directly in your filesystem too. To do this, you need to enter Create repository, set a repository name and assign a valid directory to it. Then, click Create repository. In my case in the following image, I selected testing-repo as a repository name and selected the directory: d:\wkspaces\testing-repo. (Just remember this needs to be a valid path, so create a new folder if needed.)

Creating a new local repository

Welcome new repo

After creating a new repo, you are going to see this screen. Wow, this screen is awesome :)

Empty local repository

This screen shows clearly a preview of how Branch Explorer looks with a full-branched repository. (There is still an empty repository but it's so nice to see what is coming next). This screen is what every developer should see first when start working with Git. Why? Because it visually summarizes a very powerful feature of Git – branching. (We are going to talk about this soon).

Adding your first file and committing it

Open your favorite editor, create a new file and save it to your repository base directory. Let's define the file name as README.md. It is very useful start your project with some initial instructions ;)

Here I'm going to create this file using VSCode. My file looks like this:

Creating a new file

Switch back to gmaster and click Commit in the left menu. You can see that gmaster already saw that you added a new file:

First commit
Tip: If you don't see any changes, click the reload button and gmaster will look for changes.

In the Commit screen, you can see every change you did to the repository folder. Next, you need to check which files you want to add in this commit. (A commit is like a photo. You need to organize your subjects, in this case our file changes, before taking it.)

Enter a new comment for these changes too. It is a good practice to describe in some detail every commit, this way you don't need to check every file change to understand what was changed. After this, click Commit.

Branch Explorer with our recently created commit. Wow :)

Adding more versions

Now, change the README.md file again. Add a second line with a random sentence. Repeat the steps to commit this change. After that, repeat the same process for a third sentence in the same file. Switch back to Branch Explorer.

Branch Explorer with more commits

Branch Explorer is really a nice feature in gmaster that allows you to visually check what your versions history looks like. If you mouse over each commit, you can see a summary of changes. If you double click on it, you can see the details of that commit.

Commit details in Branch Explorer

Another thing to note here in the lower part of this screen is that there is a diff between two versions. This diff tool that allows you to compare versions and commits relies on Semantic - a technology that checks and follows every moving method and code refactoring even when it happens in different files. Wow :)

Branching

Branching is a really nice feature in source-control systems. It allows you to start a new line in the history of your repo. It's like a fresh new beginning but you can choose from where to begin - in this case, you can start this line from any commit.

Imagine that you want to bug fix some things in your project. During the fixing process you can have unstable (or untested) code that is not quite nice to have in your main line. (Most teams use the main line or master branch as the most reliable and stable version of the project). So, this is where branching is so powerful.

To create a new branch, right-click on the last commit (the one with a little house) and choose Create branch from this commit.

Creating a new Branch

Keep the Checkout this branch checked. (This will make your working files appear in this new branch). Your Branch Explorer will look like the following image.

New branch in Branch Explorer

Now you can add some changes to the README.md file and you can commit them. Just add another line, commit, add another line and commit ;). A really nice thing is going to happen ;). Switch back to Branch Explorer to see how amazing your commit version looks now.

Tip: You can change modes in Branch Explorer. Switch them using these buttons:
Branch Explorer with a new Branch and commits

You can see that you created a new path in the process - and this is amazing. Usually you need to imagine this. (Remember most Git clients are based on command-line).

Revisiting the past (aka checkout to a specific commit)

Anytime during your development process, you may need to revisit the past such as checking how a deleted feature looked in the past and later keep working on the latest version. In the Git world, this is called checkout and it changes which version of your repository that you see in your file system.

Let's try this out. In Branch Explorer, right-click on a green commit. (The one with master over it). Select Checkout this commit. You will note that the "house" icon moved to there and this is how you know which commit is reflecting in the filesystem. (This is also called the working version).

Checkout to a commit

Now, if you open the README.md file in your favorite editor, you can see the file before the changes were applied in branch bugfix-01 :). Nice huh?

From here, you can even start adding changes again and committing them. For example, let's add a new line at the end of README.md and commit it.

Your branches will look like this:

Branch Explorer with more changes in master

Now, you have a very interesting scenario; you moved both history lines in parallel. The master latest version is no longer the same from the moment you branched bugfix-01 from it. Here you may be testing some small changes but in real world you can have a bunch of changes in several different files. You can imagine in this same scenario that there could be several developers branching from master to create new features; there will be a lot parallel working happening.

Applying bugfix-01 changes into master (aka merging things)

Imagine that you've been working hard at fixing things inside bugfix-01 and now it is stable enough to bring these changes back to master. But, master has evolved too, because this bugfix could have taken several days to be made. In fact, this is not a problem :)

So, you want to apply everything you changed in bugfix-01 over to master. This is the opposite of branching and it's called merging.

In Branch Explorer, right-click on the latest commit from bugfix-01 and select Merge from this commit. gmaster will open the merge tool where you can review the changes and how you should keep changes from each commit. In some cases, this merge can be done automatically, but in this next example we generated a conflict changing the same line in the same file. We need to fix this.

Conflicts

Let's click on Process all merges. This will open the Merge Tool. This tool allows you to see three versions of the conflict; how it looks in the parent version and, in each side, how it looks in each branch/commit. In the bottom half of the screen, you can see and edit the resulting file.

Merge tool - Conflicts

Note that Mergetool is trying to merge them automatically (you can check a resulting file with some changes) but we are missing some changes in resulting file.

gmaster can handle it better. Click both deselect (blue/green) buttons. Click on the resulting file where you want to add the first batch of changes. (You can add a new line if needed.) Click select on the first file (let's say the left one - the source). We just applied the changes from the source on the selected line. Later, select the last line in the resulting file and click select on the file located on the right side. You can see now that the resulting file has both changes applied and you are not losing anything. Wow :)

Merge tool - Fixing conflicts

Now, just click Save and exit and the merge screen will tell you that everything is ok to proceed. Switch back to the Commit screen and you can see how you fixed the conflicts (all the changes applied). Let's add a comment saying that you are merging bugfix to master and click Commit.

Creating a commit with the merge

Switch to Branch Explorer and now you can fully understand what happened. It looks amazing, huh?

Branch Explorer illustrating branching and merging processes

Wrapping up

This post showed you the kind of awareness and clarity in a branching process that demands a lot imagination when you only use command-line tools. gmaster allows you to really become a master at Git, understanding how each branch/commit relates to each other.

In our next post, we are going to cover how to use remotes and how to organize branches by feature or using a Gitflow model. Stay tuned :)

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.

0 comments: