This is the first part in a series
Git in easy steps – amend and stash
Why Git Extensions.
The war of version control systems was over. Git has won. And that is not an over-statement. CSV, SVN, TFS were the past. Mercurial was close, but GitHub put the end of it. The popular of open source platform makes Git an unambiguous choice for almost every developer in the field . Even BitBucket, the service which once known for Mercurial, supports Git for now. If you start a new project today, Git should be your first and foremost option – well, unless your boss says otherwise.
But the end of a war does not mean everything else is settled. The war of Git clients continues. How many Git clients do we have? I lost count, but at least: Git bash (with comes as the default), TortoiseGit, SourceTree, and of course, Git Extensions. It reminds me a lot of the JavaScript frameworks’ war recently: “There are too many frameworks out there, let’s create a new one to rule them all”. Of course, Git clients’ war is in much smaller scale (You won’t see new Git clients every week), but that does not make it less intense. Git clients are used in a daily basis, and it really affects your productivity, and in some way, your moral as well.
Then why Git Extensions? Everyone thinks their Git client is the best (Obviously, if it is not the best, they should have moved to another one). For me and another Git fellows, Git Extensions is the best. It’s powerful, yet flexible enough. Its UI is not a pain in the arse to use. The ones I know, who stick with other Git clients, haven’t really tried it enough to make the move. They rather stay in their comfort zone. I have never known one person who get familiar with Git Extensions move to other Git client.
The installation package of Git Extensions can be downloaded here At this time of writing, the latest version of Git Extensions is 2.48.05, and it comes with Git 1.9.
You can install it like normal Windows installation, however Git Extensions will install Git on your machine as well. To make it easy we can leave all the options to be default.
Clone and open repository.
Now you have Git Extensions available for use. The next step would be clone a repository so you can start working:
From Git Extensions window, choose Clone repository in left panel, a clone window will be open:
Clone a repository from Git Extensions
You can also right click in a folder on Windows Exlorer and choose GitExt Clone:
Clone a repository from Windows Explorer
These commands are equivalent with git clone <your-repository>
Clone a repository from Git Bash
To clone from Git bash, you can open Git bash by Menu ToolGit bash, then use cd command to navigate to the folder you want to put your repository. In this example, I selected D:\Documents\Dropbox folder.
Depends on the setting of the repository, you might have to input a pair of username/password. For open source projects on GitHub, there is usually no account required, but they are read-only (you can’t push anything).
If you already have a repository, you can open it by Git Extensions as well:
Open an existing repository
You can also right click on the repository in Windows Explorer and choose Git Browse. After you open a repository, the next time it will remember your repository in “Recent Repositories” in the left panel, and you can open it from here.
You first commit.
First thing first – you will have to configure the user account and email. From menu, choose Repository ⇒ Repository Settings ⇒ Git Config
Configure User Name and email
This is equivalent to these commands in Git bash:
You might notice the –global flag. This means this configuration will take effect in your entire machine. The next time you clone another repository, the same username and email will still be used. You can specify the username and password for the current repository by choose the “Local for current repository” in Git Extensions, or remove the –-global flag in Git Bash.
Now you can start adding some files to your repository. Git Extensions will show there are changes in your repository like this:
There are 6 files changed
Click on Commit (6) button to see the changes:
Pending changes
This is equivalent with git status
Status in git bash
However, in git bash, those files appear to be “untracked”. Now we can click on Stage button (one by one or all at once). Those are equivalent to git add <file-name>
(if we add each file), or git add -A
(if we add all files at once). Now run git status
will return expected result
Status after adding files
What is a commit in Git, actually? Unlike many other VSC systems such as SVN, where changesets
are actually differences – it contains the different between two versions of your reposity, a commit in Git is actually a snapshot
of your entire repository. Then Git calculates a hash of the folders and files, attach the author, committed time, message information to it.
Now add a simple commit message, and then click Commit. This is equivalent to git commit
. By default, a Text editor will open to allow us write commit message – this is from Git Extensions. If you use “pure” Git bash, you’ll have to input your message in same command line window.
Commit message editor if we run git commit
All done, now we have our first commit:
First Commit in our repository
To show the commit history in Git bash, we can also run git log
:
History in git bash
Pushing your commit
Now we are done with our first commit. We’ll push it to somewhere else, may be to be built by remote servers, may be to share with others, or may be, just like me, to be safe. Who knows what will gonna happen to your machine? Just click on the Push button and then click Push:
Now click Push and be done
In this case, we’re pushing from our “master” local branch to the “master” remote branch. This is more or less equivalent to git push origin
command in Git bash.
2 thoughts on “Git in easy steps – the basics”