If you are on Windows and you want to follow the steps below, all you need to do is to set-up Git on your local machine.
Before we go into Git commands bear in mind (and do not forget!) that Git has a working directory, a staging area and the local repository. See the overview below taken from http://progit.org.
The GIT workflow is as follows: You go to the directory where you want to have version controll. You use git init to put this directory under version control. This creates a new repository for that current location. You make changes to your files, then use git add to stage files into the staging area. You’ll use git status and git diff to see what you’ve changed, and then finally git commit to actually record the snapshot forever into your local repository. When you want to upload your changes to a remote repository you’ll use git push. When you want to download changes from a remote repository to your local repository you’ll use git fetch and git merge.
Lets go through this step-by-step.
To create a repository from an existing directory of files, you can simply run git init in that directory. Go to that directory you want to get under version control:
git init
All new and changed files need to be added to the staging area prior to commit to the repository. To add all files in the current directory to the staging area:
git add --all
To commit the files and changes to the repository:
git commit -am "Initial commit"
Note that I have use the -am option which does an add -all implicitly. This command is equivalent to the SVN- or CVS-style “commit”. Again: if you want to update your local Git repository there is always an add-operation followed by a commit-operation, with all new and modified files.
Then you go create a repository at Github.com. Let’s say you named it git_example.
Then you add the remote repository address to your local GIT configuration:
git remote add EXAMPLE https://nschlimm@github.com/nschlimm/git_example.git
Note that in the example thats my user name on Github.com. You’ll need to use yours obviously. I have named the remote repository “EXAMPLE”. You can refer to an alias name instead of using the remote URL all the time. You are ready to communicate with a remote repository now.
If you are behind a firewall you make the proxy configuration:
git config --global http.proxy http://username:passwork@someproxy.mycompany.com:80
Then you push your files to the remote repository:
git push EXAMPLE master
Then imagine somebody changed the remote files. You need to get them:
git fetch EXAMPLE
You need to merge those changes from the remote master into your local master branch (plain language: you copy the changes from your local repository to your working directory). Assume that your current context is the master branch and you want to merge EXAMPLE branch into master, you’ll write:
git merge EXAMPLE
To compare the staging area to your working directory:
git status -s
The example shows the status after I have modified the README.txt (but did not added or commited yet).
Without any extra arguments, a simple git diff will display what content you’ve changed in your project since the last commit that are not yet staged for the next commit snapshot.
git diff
The example shows the diff output after I have edited the README.txt file (but did not added or commited yet). When I add all changes to staging, git diff will not display changes ’cause there is nothing in your working directory that has not been staged.
It’s different with git status. It shows the differences between your last commit and the staging/working area:
In short: git status shows differences between your local repository and your working directory/staging area. Whereas git diff (as used above) shows differences between your staging area and your working directory.
That’s it. These are the most important Git commands a newbie must know to get started. See the gitref.org reference for more information on using Git.
Downloading a remote repository
If you like to copy a repository from Github.com (or any other remote address) to your local machine:
git clone https://nschlimm@github.com/nschlimm/spring-decorator.git
You can now work on the code and push the changes back to that remote repository if you like.
Working with branches – changing your current context
A branch in Git is nothing else but the “current context” you are working in. Typically you start working in the “master” branch. Let’s say you want to try some stuff and you’re not sure if what you’re doing is a good idea (which happens very often actually :-)). In that case you can create a new branch and experiment with your idea:
git branch [branch_name]
When you just enter git branch it will list your new branches.
If you’d like to work with your new branch, you can write:
git checkout [branch_name]
One important fact to notice: if you switch between branches it does not change the state of your modified files. Say you have a modified file foo.java. You switch from master branch to your new some_crazy_idea branch. After the switch foo.java will still be in modified state. You could commit it to some_crazy_idea branch now. If you switch to the master branch however this commit would not be visible, ’cause you did not commit within the master branch context. If the file was new, you would not even see the file in your working tree anymore.
If you want to let others know about your new idea you push the branch to the remote repository:
git push [remote_repository_name] [branch_name]
You’d use fetch instead of push to get the changes in a remote branch into your local repository again.
This is how you delete a branch again if you don’t need it anymore:
git branch -d [branch_name]
Removing files
If you accidentally committed something to a branch you can easily remove the file again. For example, to remove the readme.txt file in your current branch:
git rm --cached readme.txt
The --cached option only removes the file from the index. Your working directory remains unchanged.
You can also remove a folder. The .settings folder for an eclipse project – for instance – is nothing you should share with others:
git rm --cached -r some_eclipse_project/.settings
After you ran the rm command the file is still in the index (history of Git version control). You can permanently delete the complete history with this command:
Note: be very careful with commands like this and try them in a copy of your repository before you apply them to your productive repository. Always create a copy of the complete repository before you run such commands.
git filter-branch --index-filter 'git rm --cached --ignore-unmatch [your_file_name]' HEAD
Ignoring files: you do not want to version control a certain file or directory
To ignore files you just add the file name to the .gitignore file in the directory that owns the file. This way it will not be added to version control anymore. Here is my .gitignore for the root directory of an Eclipse project:
/target /.settings .project .classpath
It ignores the target and the .settings folder as well as the .project and the .classpath file.
Sometimes its helpful to configure global ignore rules that apply to the complete repository:
git config --global core.excludesfile ~/.gitignore_global
This added the following entry to my .gitconfig global parameters file which resides in the git root directory.
excludesfile = d:/dev_home/repositories/git/.gitignore_global
These are my current global exclude rules in my .gitignore_global file:
# Compiled source #
###################
*.com
*.class
*.dll
*.exe
*.o
*.so
# Logs and databases #
######################
*.log
Note: these rules are shared with other users. Local per-repo rules can be added to the .git/info/exclude file in your repo. These rules are not committed with the repo so they are not shared with others.
Restoring files – put the clocks back
Sometimes you make changes to your files and after some time you realize that what you’ve done was a bad idea. You want go back to your last commit state then. If you made changes to your working directory and you want to restore your last HEAD commit in your working directory enter:
git reset --hard HEAD
This command sets the current branch head to the last commit (HEAD) and overwrites your local working directory with that last commit state (the --hard option). So it will overwrite your modified files.
Instead of HEAD (which is your last commit) you could name a branch or a tag like ‘v0.6’. You can also reset to a previous commit: HEAD~2 is the commit before your last commit.
May be you want to restore a file you have deleted in your working directory. Here is what I’ve entered to restore a java file I have deleted accidentally:
git checkout HEAD sources/spring-decorator/src/test/java/com/schlimm/decorator/simple/SetupSession.java
Again: Instead of HEAD you could name a branch or a tag like ‘v0.6’. You can draw the file from a previous commit: HEAD~2 is the commit before your last commit.
Working with tags – making bookmarks to your source code
Sometimes you want to make a version of your source code. This way you can refer to it later on. To apply a version tag v1.0.0 to your files you’d write:
git tag -a v1.0.0 -m "Creating the first official version"
You can share your tags with others in a remote repository:
git push [remote_repository_name] --tags
Where remote_repository_name is the alias name for your remote repository. You write fetch instead of push to get tags that others committed to the remote repository down to your local repository.
If you just enter git tag it will give you the list of known tags. To get infos about the v1.0.0 tag, you’d write:
git show v1.0.0 -s
If you want to continue work on a tag, for instance on the production branch with version v5.0.1, you enter:
git checkout v5.0.1 -b [your_production_branch]
Note that this command also creates a new branch for the tag, this way you can make commits and anything else you wish to record back to the repository.
Reference: “Top 10 commands for the Git newbie” from our JCG partner Niklas.
Great but cmd.exe is crap. Why you are using it?