Top 10 commands for the Git newbie
Join the DZone community and get the full member experience.
Join For FreeIf you're new to Git you will recognize that some things work different
compared to SVN or CVS based repositories. This blog explains the 10
most important commands in a Git workflow that you need to know about.
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.
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:
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:
To commit the files and changes to the repository:
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:
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:
Then you push your files to the remote repository:
Then imagine somebody changed the remote files. You need to get them:
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):
Note that you are in the master branch and the EXAMPLE/master in the merge command refers to the remote master.
To compare the staging area to your working directory:
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.
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:
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:
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:
To commit the files and changes to the repository:
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:
Then you push your files to the remote repository:
Then imagine somebody changed the remote files. You need to get them:
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):
Note that you are in the master branch and the EXAMPLE/master in the merge command refers to the remote master.
To compare the staging area to your working directory:
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.
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.
From http://niklasschlimm.blogspot.com/2011/07/top-10-git-commands-for-newbie.html
Git
Command (computing)
Repository (version control)
workplace
Directory
Opinions expressed by DZone contributors are their own.
Comments