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.
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 email@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 firstname.lastname@example.org: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:
Well, that’s it. Do you think there’s a basic command not listed here? Please let me know.
Chacon, Scott. Pro Git. Apress, 2009.