Git basics
Git basic commands
Git init or clone
To initialize your current project with Git, you first go to your root project folder. For example, below is your project:
MyProject
|_ sources (directory)
| |_ main.c
| |_ foo.c
| |_ foo.h
|
|_ readme.txt (file)
Your root project folder is MyProject, in this folder you execute the following command:
# git init .
This means, initialize Git in this folder to result in a Git repository.
Next, is to add all folder and files to the newly created git repository:
# git add .
Finally, check in all the files as an official commit, which means the changes are really saved:
# git commit -m "The files are offically commited in the Git repo."
The argument -m means message, because for each commit, Git wants (or even forces) you to add a comment, so afterwards you can easily read why the changes are added to this commit.
Another way is to clone a git project from a remote machine (like projects from github), use this command:
# git clone http://url.of.the.server/project.git
Once you've done that, you get a complete project with all its history, without adding or committing. From now on, you can can create new branches, add modifications and issue new commits.
Git stages
In git you have several stages. In the beginning, if you add a file in your project, the file is considered as untracked by Git. This means, that although you perform a Git commit, the untracked file is not included to the final commit! To make the newly created file trackable by Git, you issue the command "git add filename". This brings the file into the tracked stage. If we modify this same file, it is than to be considered as modified by Git. So to include the modification in Git (meaning bring the modification in the Git index), we AGAIN issue "git add filename". Now the changes are in the 'Index' stage and is ready to commit (ready to make a new snapshot for this particular version). Finally, if we (git) added all the changes, we than issue the commit command "git commit -m 'message'". Now we've walked through all the workflow processes, these are the steps you often will perform.
So the workflow is like this:
step status
1 new file abc.txt : untracked
2 git add abc.txt : tracking
3 edit abc.txt : modified
4 git add abc.txt : indexed (meaning ready to be committed)
5 git commit : commit the new changes (create new snapshot)
The place where you do changes and edits on files is called the "Working tree". When you (git) add those modifications, they're put on the index stage. When committing, those modifications in the index stage are than committed for a new snapshot.
Display the commits
If you want to see all the commits of a project, you can do as follows:
# git log
This will result in a list of all commits, the picture below gives you a portion of the output of this command:
 | |
| git-log output |
We see in the above picture 4 items:
- Commit: This is the hash value of the changes that has been added, also called a revision. The hash value is a checksum for validity of the changed data. If somehow the data got corrupted, we would get an error from Git that something wrong is going on.
In the .git folder special objects are saved for each commit which contains the changes, of course protected by sha-1. - Author: The one who made the changes
- Date: date of commit
- message: additonal note/information about this commit
# git log --pretty=oneline
A nicer one is:
# git log --graph --pretty=oneline --abbrev-commit
Concerning the hash value, it's not so important to us, it's more important for Git. You don't need to look at it all the time, except when you want to go back to some previous revision and create a release out of it, or you want to perform a git diff, to see the difference in a certain file.
git-status
If you made some changes, you can check the current status. This way you can see what files are modified before committing.
# git status
git reset
With git reset you can revert back to its original state, meaning before you made some changes to files. It may happen you made a mess and you get panic. Be relax and do the following command:
#git reset --hard
This will remove all the changes (not the changes from previous commits) and go back to its latest commit (which is also called HEAD).
(More explanation needed here...)
git tag
git tag command is very useful too if you want to give a revision a tag name for a release. We can give a tag like this:
# git tag v1.0.2 -m "bug fix"
To tag a certain commit, you can do this:
# git tag v1.0.1 -m "update" 56ae0a9
This way you give a tag name for a commit, the first 7 character of the hash are enough.
Another very cool command is to get the sources from a certain tag. It's also much easier to remember if you want to go back to the last release of your software:
# git checkout v1.0.1
git branch
A very cool feature of git is you can make a copy of your complete source for editing, while you're still in the same repository. This is called branching. Without making a copy of all your sources in your repository to another directory, you can do the some editing in another copy which is called a branch. Normally you're already in a branch, called master, which is by default. By branching, you can make a complete copy of your project but under a different name. To make a new branch, you have to specify a name, for example:
# git branch -b mynewbranch
Now you're on a copy of your complete project and do some edits. To switch back to your original branch, you do:
# git checkout master
To get a list of branches:
# git branch
The one that is marked with an asterisk (*) is the current branch you're on.
Now we go back to the newly created branch:
# git checkout mynewbranch
If we added some changes and did some commits, we would like to add the changes to our master branch. To do that, we first go back to our master branch:
# git checkout master
And than merge the changes from mynewbranch to master:
# git merge mynewbranch
To delete 'mynewbranch' as we don't use it anymore:
# git branch -d mynewbranch
No comments:
Post a Comment