You know what I really hate about git? Calling working directories as repositories and real repositories as bare repositories. This is somehow confusing for people like me coming from older and outdated control version systems like CVS or SVN.
But if you keep in mind what I said above and give git a chance you’d realize is the most powerful control version system ever created.
There are tons of git tutorials out there but I’m pretty sure none of them cover how 90% of the people use git: clone an existing project, make their own changes and try to keep them updated with the original project. Eventually submit patches.
There are two kind of repositories in git:
- Normal Repository: This is your working directory. This is where you mess with files, edit them, make your patches, and you can even run ./configure and make and try it out and issue a
- Bare Repository: This kind of repository doesn’t have working directories. This is what you’d call a shared repository where several developers can collaborate.
There’s a special kind of bare repository called remote repository, we’ll cover those soon.
First Things First
Before you start using git you need to at least configure your user name and email address since they will be included in every commit you make.
git config --global user.name "John Doe" git config --global user.email email@example.com
Also you should take the opportunity to configure your default editor. I’m all about vi, so I can’t stand editors like nano, joe, emacs, etc.
git config --global core.editor emacs
Quick and Dirty Start
If you want to create an empty repository where you can start working on source code files you use:
git init myproject
And that will create a directory called myproject that is a git repository. But usually you will not create an empty repository, but you would clone a project instead and then start working on your changes:
git clone https://github.com/myproject/myproject.git
This will clone the whole repository in a working directory for you to change files in the same directory myproject. By the way that github.com repository is a bare repository as you might guessed.
Now you’re gonna start to make your changes but you shouldn’t edit the files in the master branch. Instead you should create a branch where you can work on your changes without messing with the master branch. To list all the branches in your repository:
To create a new branch:
git branch mybranch
And finally to start working on your branch (to switch to your new branch):
git checkout mybranch
Committing your Changes
You created your local repository and started making changes. If you didn’t create any new file but just edited existing files and you’re ready to commit your changes, you first have to add the content to the index for the next commit:
git add -u
That will update the index with the new content from all the files that were edited. If you created a new file, you have to add it:
git add src/newfile.cpp
Or, if you created a bunch of source files, you can add the whole directory:
git add .
This is a good time to tell you about the dry-run option in most git commands. It will show you what would be done, without doing anything, so you can verify it will do what you want:
git add -n .
And now you’re ready to commit.
git commit -m "Initial commit"
Again, you can use -n to see what would be done.
Your commit will have a SHA1 hash that you can use to reference it later. Check your commits like this:
In a next post we’ll see how to keep your source updated with the original repository; as you might have guessed while you are making changes other people can be also making changes to the code. Also we’ll take a look how to compare your code with the master or any other branch, and push your changes to the upstream repository.
Too basic for you? Check out the Part II of this tutorial.