Blog

Git Basic Commands Explained

by -

tags:git

The last article about Git (Git Workflow) was too much theoretical, but that was intentional. I believe it’s necessary to understand some Git’s core concepts to make proper use of it, in an easy and intuitive way. If you haven’t read it yet, I recommend it before proceeding.

Now we’ll play with Git’s basic commands, and hopefully it’ll simplify those concepts a lot, and you’ll finally have a nice understanding about it.

Global Settings

The first thing you should do when you install Git is set your name and e-mail address. This is important because every Git commit uses this information.

$ git config --global user.name "Your Name"
$ git config --global user.email youremail@example.com

Using —global option makes it globally available for Git (any repo you work). If you want to override that information for a specific repo, just go to that repo’s root directory and run the command without the —global option.

Creating a new repository

There are two ways to create a new Git repo: using init or clone commands. Let’s start by init.

Go to the directory that will be the repository and run:

$ git init

That started a new repository and created a local master branch. Don’t worry about it right now, branching wil be the subject of another article.

Cloning an existing repository

To clone an existing remote repository go to the directory that you want to create the new repository’s directory and run a command like $ git clone [url]:

$ git clone git://github.com/flsilva/as3coreaddendum.git

That will create an as3coreaddendum directory in your file system.

Checking the status of your files

After making changes, creating and deleting files, you’ll frequently use the status command to check the status of your local repository:

$ git status

When you see a message like nothing to commit, working directory clean, it means that your working directory is fully synchronized with your local repository, i.e., there are no changes to be committed.

When you see a message like Changes not staged for commit, it means that you’ve made changes to tracked files (files already in your local repo) but have not added them to the staging area, which means they will not be committed when you run commit command. Usually you’ll also see a message like Untracked files, which means there are new files not added to the staging area.

Adding changes to the staging area

After checking, you’ll want to add your changes to the staging area. There are two main ways to do that, running the add command for individual files or directories:

$ git add file-name

Or running add command for all files and directories:

$ git add -A

After that you can check the status of your files again:

$ git status

Now you should see a message like Changes to be committed. That means that you’ve staged your changes, and they are ready to be committed.

Committing changes to the local repository

Everytime you run commit command Git sends to the local repo the content (files, changes, etc) of the staging area, not your local file system. So if you run add, and before you run commit you make more changes and then run commit (without running add again for those later changes), Git will not commit your later changes. This is a gotcha and shows how Git uses its staging area concept.

To send your changes to your local repository you run:

$ git commit -m "your commit message here"

The commit message is mandatory and you should do it anyway, it’s a best practice. Since you should commit often, your messages should be simple but descriptive.

You can commit how may times you want before sending it to a remote repository.

Pushing changes to a remote repository

The time will come when you want to send your precious changes to a safe and warm remote repository, right? I hope you’ve said yes.

To send changes to a remote repository you should have one (of course) but you need to have a reference to it in your local repository too. Assuming you already have a remote repository configured somewhere (you can always setup one for free on GitHub), there are two ways to create a reference to it on your local repo. The first and easier is when you clone some existing repository. In this case Git automatically creates a reference to your cloned repo, naming it origin. But if you created your local repo from scratch using init you have to set it up manually running a command like:

$ git remote add [remote-name] [remote-url]

remote-name is the name you want to give to that repository, an alias.
remote-url is the path to the remote repository, and it depends on the protocol you’ll be using (SSH, HTTPS, git://, etc)

Usually you’ll create an origin alias pointing to your canonical remote repository, like this:
$ git remote add origin git@github.com:flsilva/as3coreaddendum.git

That creates a new remote repository reference with the origin alias.

You can always check all your remote references running $ git remote -v

Now, to send your local changes to a remote repository you run a command like $ git push [remote] [branch]:

$ git push origin master

master is the name of the default main branch in Git. Don’t worry about it right now, branching wil be the subject of another article.

Note: You’ll need write permission to a remote repository to run push command.

Pulling changes from a remote repository

You should always run pull command before running push, because if someone else pushed to the remote repository, you’ll have to pull it before pushing. Git will enforce it. Also, before pulling you need to commit your changes.

To pull from a remote repository you run a command like $ git pull [remote]:

$ git pull origin

The pull command will fetch all changes and start a merging command. You’ll only need to confirm the default merge message (or change it) and you’ll be up-to-date to your remote repository, ready to push to it. So the general workflow to push changes is commit, pull, push.

Deleting files and directories

One of the things that I love on Git over SVN is that you don’t need to do anything special to delete files and directories. Just delete it the way you want, on your OS’s GUI tool or command line. Git will find that out and remove them from repository (you just need to run $ git add -A as usual, to prepare changes to go on next commmit).

Renaming and moving files and directories

The same is true for renaming and moving files and directories. Just do that the way you want, you don’t have to worry about anything. Lovely, isn’t it?

Viewing the commit history

Sometimes you’ll wish to see the commit history. The simplest way is running:

$ git log

But that prints all commits, so it’s very bad. You can limit it:

$ git log -3

That prints only the last 3 commits. And if you want to see a bit more info about each commit:

$ git log -3 --stat

You can filter commits by time, for example in the last two weeks:

$ git log --since=2.weeks

Another useful option is filter commits that has changed a specific directory or file:

$ git log -- directory/

$ git log -- file

Or filtering commits by commiter or author:

$ git log --committer=Flavio

$ git log --author=Flavio

A simple and nice GUI tool is distributed with Git and can also show the commit history. To launches it you just run:

$ gitk

Well, that’s it. Do you think there’s a basic command not listed here? Please let me know.

Git Branching and Merging
Git Tagging
Git Workflow
Introduction to Git

Git
Pro Git Book

Bibliography

Chacon, Scott. Pro Git. Apress, 2009.

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

comments powered by Disqus