Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

15. Git GUI Tools

Mariot Tsitoara¹

(1)

Antananarivo, Madagascar

In the earlier chapters, we’ve seen a lot of the most important Git features and concepts. We’ve learned about commits, branches, pull requests, and merging. Using those concepts, you can already accomplish almost anything in Git. Only one small problem, though: we’ve only used the Terminal or Console window. In this chapter, you won’t learn any new concept or feature; you will just learn how to apply what you already know with style ☺

First, we’re going to investigate the default tools that come with Git, then learn more about IDEs that integrate Git, and lastly look at some specialized tools specially made for Git.

Default tools

If you’ve followed the installation steps from the Chapter 2, you already have those tools installed on your computer. If not, you can easily get them on our habitual software store. These default tools are shipped with Git to provide users very simple GUIs to browse their repositories and prepare their commits. They are available for almost any Operating Systems, so don’t worry, they are available to you. They are presented in this book for historical reasons and because they come built-in into Git.

Committing: git-gui

The first tool we are going to see is called git-gui and it’s a graphical committing interface for Git. You will use it to commit your project and review proposed changes. You can find more information about it on https://git-scm.com/docs/git-gui.

You can open it like you would open Git Bash: by the command line, context menu, or Start page. Choose whichever is the best option for you. On Windows and Debian-based OSs, you can open a Git GUI by navigating to the directory of the repository and right-clicking an empty space. Doing so will give you a result similar to Figure 15-1.

../images/484631_1_En_15_Chapter/484631_1_En_15_Fig1_HTML.jpg — Figure 15-1
Windows context menu

As you can see, you can open Git GUI and Git Bash there. Go ahead and choose Git GUI. You will get a little program window that details your current working directory status. The window is presented in Figure 15-2.

../images/484631_1_En_15_Chapter/484631_1_En_15_Fig2_HTML.jpg — Figure 15-2
Git GUI interface

And if you don’t want to use the context menu or can’t, you can open it by opening a Terminal on the location of your Git repository and executing the following command:

$ git gui

The Git GUI interface is very lightweight and intuitive; and it’s the same for each OS so everybody feels at home. It is divided in four parts:

Top left is a list of edited files that have not been staged yet.
Bottom left is a list of files that have been staged.
Top right is a diff view.
Bottom right is a commit message text area.

And since we haven’t changed anything in our project, everything is empty. So, let’s mess up our project with additional commits.

First, let’s make sure that we are in master branch and then create a new branch from it. Go to the “branch” menu and select “checkout…”; it will open the selection window shown in Figure 15-3.

../images/484631_1_En_15_Chapter/484631_1_En_15_Fig3_HTML.jpg — Figure 15-3
Choosing a branch to check out

You’ll notice that when your cursor hovers above a branch, information about its last commit will appear. It will help you find the right branch, but shouldn’t be necessary if you have good branch names. Check out master branch and then create a new one by selecting “create…” on the “branch” menu. You will get the branch creation window shown in Figure 15-4.

../images/484631_1_En_15_Chapter/484631_1_En_15_Fig4_HTML.jpg — Figure 15-4
Creating of a new branch

The first input area is the most important: the name of your new branch. Name the branch “separate-code-and-styles.”

The second input is a choice input where you have to select where you are going to create the branch from. In our situation, we are going to create a new branch from our local master branch; so choose “local branch” and select “master.”

The third part are the options, which I recommend keeping the default options. With the default options, Git will fetch the latest commits on the remote (tracking) branch and then check out the new branch.

Now, you can click “Create” to see the result. You will see that the little message box on the top left now lists “separate-code-and-styles” as the current branch. To give you perspective, here is the command equivalents of what we just did:

$ git checkout master

$ git branch -b separate-code-and-styles

Now that we are in the correct branch, we can work on our commit. Remember our golden rule when discussing Git workflow? Each commit must have the resolution of an issue as goal. I’ll let you create that issue.

EXERCISE: CREATE AN ISSUE

Go to GitHub issues.

Create an issue called “Separate code and styles.”

Take note of the issue number.

Now we’re ready to commit! Create a new file called “style.css” in your repository and paste in this code:

h1 {

text-align:center;

}

h3 {

text-transform: uppercase;

}

ul {

margin: 0;

padding: 0;

}

ul li {

cursor: pointer;

position: relative;

padding: 12px 8px 12px 40px;

background: #eee;

font-size: 18px;

transition: 0.2s;

-webkit-user-select: none;

-moz-user-select: none;

-ms-user-select: none;

user-select: none;

}

ul li:nth-child(odd) {

background: #f9f9f9;

}

ul li:hover {

background: #ddd;

}

Then, open “index.html” and change its content to

<!doctype html>

<html>

<head>

</head>

<body>

<ul>

<li>Clear the fogs for the frogs</li>

<li>Bring a box to the fox</li>

</ul>

<ul>

<li>Put the mittens on the kittens</li>

</ul>

</body>

</html>

Save the two files and let’s hop to Git GUI to see the result. You will see… nothing new! Because Git GUI isn’t aware of our changes yet. Click “Rescan” near the commit message box to see the changes; you will get the result shown in Figure 15-5.

Now we have our changes! You can see the list of modified files on the top left part of Git GUI, where the unstaged files are. You will notice that the files have different icons:

An empty file icon for a new file (never been committed)
A file icon for a modified file (has been part of a commit before)
A “?” icon for a deleted file (has been part of a commit before)

Doesn’t that view remind you of something? Well, it’s the status view, of course! Clicking “Rescan” is the same as executing this command on the terminal:

$ git status

Here, we modified “index.html” and created “style.css.” If you click the file names (not icons; don’t click the icons yet), you will see the diff view change. Check Figure 15-6 for an example of the result that you would get after clicking style.css.

../images/484631_1_En_15_Chapter/484631_1_En_15_Fig6_HTML.jpg — Figure 15-6
Diff on the newly created style.css file

It’s certainly quicker than executing “git diff”! Also, it’s easier on the eye if you have a lot of changed files. So clicking the file name is equivalent to executing these commands:

$ git diff index.html

$ git diff style.css

Now is then time to stage our files in preparation for the commit. Staging and unstaging a file is really easy: you just have to click its icon. Or you can also select the files you want to stage (by clicking their names) and choose “Stage to Commit” in the “commit” menu. Clicking the file icons is the same as executing these commands:

$ git add index.html style.css

$ git reset HEAD index.html

$ git reset HEAD style.css

See? Way quicker than typing commands!

We can finally commit our project! But first, make sure that all the files you created or modified are staged, meaning that they are on the bottom left section. Then, you can write your commit message on the bottom-right section of Git GUI, just like in Figure 15-7.

../images/484631_1_En_15_Chapter/484631_1_En_15_Fig7_HTML.jpg — Figure 15-7
Writing of a commit message

Now with our files staged and our commit message written, we are ready to commit. Just click the “Commit” button near the commit message box. After you do so, Git GUI comes back to its normal, empty state. We’ve committed from the graphical tool!

Clicking the “Commit” button thus has the same result as this command:

$ git commit -m "Move style code to external file"

Since you are my best student (don’t tell the others), I’ll let you make another commit in our branch.

EXERCISE: MAKE ANOTHER COMMIT

Open README.md.

Add this line at the end of the file: “License: MIT.”

Create a new file called LICENSE.

Copy the license text from https://choosealicense.com/licenses/mit/ into the LICENSE file.

Stage both files.

Commit with the message “Add MIT license.”

Oof! Now you have two commits on your new branch and it’s time to push them to the remote repository. You have certainly guessed which button to click; it’s “Push.” Clicking it will give you the result in Figure 15-8.

../images/484631_1_En_15_Chapter/484631_1_En_15_Fig8_HTML.jpg — Figure 15-8
Pushing a branch

It’s a straightforward interface; you just have to select the branch you want to push and the location where you want to push it.

The current branch is selected by default, so we don’t have to change anything. The second section is the destination selection dropdown; and again, we don’t have to change anything because we only have one remote repository. Ignore the options for now; we will see them in a later chapter.

Click push to push! If you are using an HTTPS authentication to connect with GitHub, you will be asked for your GitHub username and password and then get the result shown in Figure 15-9.

../images/484631_1_En_15_Chapter/484631_1_En_15_Fig9_HTML.jpg — Figure 15-9
Push result

Tip

If you don’t want to write your password each time you push, you can cache it or use an SSL authentication; all of this is explained in later chapters.

Nothing new here, we got the same result as this command:

$ git push origin separate-code-and-styles

EXERCISE: CREATE A PULL REQUEST

Follow the link you got after pushing.

Create a pull request with this description: “Fix #10” (replace the number with the issue number you created earlier).

Merge the PR.

Rejoice.

And that’s how you commit with Git GUI! Simple, right? And very quick too. It’s a great tool that can save you a lot of time when reviewing commits. Talking about commits, let’s see the other default tool!

Browsing: gitk

In the previous section, we talked a lot about creating and pushing commits. Now, we are going to visualize those commits in their natural habitat: the repository. gitk is a simple tool to have a simple visual of your project history. You can think of it as an overpowered “git log” command. More documentation about gitk can be found on https://git-scm.com/docs/gitk.

Since you already have git-gui open, let’s use it to open gitk. Simply choose “Visualize all branch history” from the “Repository” menu. Doing so will open gitk, and you will see the window shown in Figure 15-10.

../images/484631_1_En_15_Chapter/484631_1_En_15_Fig10_HTML.jpg — Figure 15-10
gitk interface

At the top of the window, you will find a list of all your project’s commits, from all branches. It is presented in a nice graph view that you can reproduce on console with the command:

$ git log --oneline --graph

You can click the commits to get more information about them. Selecting a commit will update the views on the bottom of the window. The bottom left part is a diff view again, but with a twist: you can also choose to view the old or the new version of the files. The bottom right part is a list of all the files changed in the commit. You can click them to see the changes on the diff view. Clicking a commit is the equivalent of executing the following code:

$ git show <commit_name>

And that’s it for gitk, the default browsing tool of Git! Since you can commit and browse with the default graphical tools now, it’s time to present you to other tools.

IDE tools

As we saw in the previous section, committing with a graphical tool is very fast compared to typing in the console. But there still is a problem: you must leave your Integrated Development Environment to use them. Wouldn’t it be nice if you could use the graphical tools directly from your editor?

It’s possible with a lot of modern editors. I will present you to two popular IDEs that have Git integrated so you can use them for your future development. And if you don’t want to use them or you are already in love with your current editor, chances are that your IDE also have integrated Git tools or plugins if it’s modern enough. Each IDE has its own interface and user experience, so I won’t go into detail in this section. I just want to show to what features are available.

Visual Studio Code

A very popular editor, Visual Studio Code, is a lightweight IDE supported by Microsoft; you can find it on https://code.visualstudio.com/. It’s new so it has all the shiny new toys integrated in it; and Git is at the center of those. You can see the look and feel of VS Code in Figure 15-11.

../images/484631_1_En_15_Chapter/484631_1_En_15_Fig11_HTML.jpg — Figure 15-11
Visual Studio Code

It has the same interface as any other IDE but with a little bonus: you can see traces of Git here and there. First, if you change a tracked file (README.md here), the edited part is highlighted; no need to execute git diff anymore!

And at the bottom left of the window, you have the current branch name; if you click it, you can select the branch you want to navigate to or create a new branch. If you have unstaged files, there will be a little “∗” sign near your branch name and an “M” icon near the concerned file names. If you have staged push uncommitted files, you have a “+” sign.

Click the Source Control icon to access the Git Tab, shown in Figure 15-12.

../images/484631_1_En_15_Chapter/484631_1_En_15_Fig12_HTML.jpg — Figure 15-12
Source Control view

This view looks and works very much like git-gui, so I’ll let you discover it yourself!

Atom

Atom is an IDE pushed by GitHub and it’s also a very popular choice among developers. You can check it out on https://atom.io/. You can see its interface in Figure 15-13.

../images/484631_1_En_15_Chapter/484631_1_En_15_Fig13_HTML.jpg — Figure 15-13
Atom interface

It has the same Git features as Visual Studio Code but with a little twist: you can link your GitHub account to it and create PR directly from the editor! Again, I’ll let you discover.

Specialized tools

We saw the default Git tools and some IDEs that have Git integrated. Now, let’s see some tools specially developed for Git.

GitHub Desktop

GitHub Desktop is the perfect tool for you if you like the default gitk and git-gui tools but hate their interface. Let’s face it, the default tools are great, but their look feels odd in those modern times. GitHub Desktop (found on https://desktop.github.com/) has been created to replace those tools; it has all their features combined in one software. You can check Figure 15-14 for the interface of GitHub Desktop.

../images/484631_1_En_15_Chapter/484631_1_En_15_Fig14_HTML.jpg — Figure 15-14
GitHub Desktop

GitKraken

GitKraken is a Git client created by Axolosoft that is becoming more and more popular. You can get it on its web site at www.gitkraken.com/. It’s more advanced than all the other tools as its goal is the augmentation of developer productivity. It even has an integrated code editor! You can see its interface in Figure 15-15.

../images/484631_1_En_15_Chapter/484631_1_En_15_Fig15_HTML.jpg — Figure 15-15
GitKraken overview

Again, the interface is the same as the others, but what distinguish GitKraken is its beauty: it’s insanely gorgeous!

Summary

This chapter was fun, wasn’t it? We learn a lot about how to use a graphical tool to make commits and browse them. We also discovered a ton of new tools that are available to us, be it integrated into an IDE or a specialized tool. And how can we forget about our good old default tool?!

You may ask yourself why not use the graphical tool from the very beginning? It’s because using a tool without knowing the concepts behind them is counterproductive and a waste of time. Trust me, learning to use the Terminal was worth it! Talking about terminals, let’s get back to it for some more advanced Git commands!

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for 15. Git GUI Tools

Create new playlist

Sign In

Sign Up