One of the most crucial commands in Git is git status. It tells you even more than its Subversion counterpart. In particular, besides the list of changed, deleted or untracked things in the filesystem, it will even tell you commands to use to get them committed or tracked. It will ignore any files or subdirectories (and the files and directories under them) that are listed in .gitignore.
Before beginning to perform fresh work in a project, you'll probably want the latest from origin master or, more frequently, from the master branch. In the subdirectory where you're planning to work, type:
$ git pull <branch>
Note that if the updates depend themselves on files in other subdirectories, you may wish to pick the subdirectory from which you do this carefully in order to get all necessary updates. Team members must be careful not to commit code that breaks the build or crashes on execution, you'd normally be safe to refresh your entire project.
You'll likely be doing the following to commit changes you've made whether by adding new files, modifying or deleting old ones. Using dot ('.') just ensures you cover the bases of all changes, but it's a dangerous shotgun. After you've reached a point you'd like to commit, do this:
| git add . | Adds everything new including scheduling modified files for commit* |
| git add <filename> | Adds just <filename> to the change list |
| git status | Will neatly list everything that's changed since the last commit |
| git commit | Commits what's been added to the status. |
| git commit <filename> | Commits just <filename> |
| git push <branch> | You might not wish to push just anywhere let alone all the way back to master |
* Beware: don't blindly shove everything into the repository! In Eclipse projects, for example, you do not want to put some files and subdirectories into the repository. It's very useful to try out git status before you perform a git commit in order to make certain what you're committing is what you intended. (This isn't different at all from Subversion.) And, if you keep tripping over files you never want tracked, add them to .gitignore.
The git push operation should require a branch name. For example, you might see:
$ git push No refs in common and none specified; doing nothing. Perhaps you should specify a branch such as 'master'. fatal: The remote end hung up unexpectedly error: failed to push some refs to 'git@swan-of-tuonela:project' $ git push origin master Counting objects: 30, done. Delta compression using up to 4 threads. Compressing objects: 100% (21/21), done. Writing objects: 100% (30/30), 4.04 MiB, done. Total 30 (delta 0), reused 0 (delta 0) To git@swan-of-tuonela:project * [new branch] master -> master
Once you've done this, Git remembers thereafter where to push to, but it's better form (because safer) to be explicit. The above will push your changes all the way to the master branch. See Git Scheme. This should not be a common operation.
Because of the way Git commands list commit comments, you should get into the habit of providing a short description on the commit in the first line, then elaborate on subsequent lines.
Unstaging means you've added a file, new or existing, to be committed, but then discover you didn't want it in the first place. Maybe it's an intermediate file you add by accident.
If you staged a commit, but haven't committed it yet, you can back the file(s) out this way:
$ git reset -- filename [ filenames ]
Sometimes, you screw the pooch. Here's how to fix it. The main thing to know is that git revert is NOT the same thing as svn revert, p4 revert, etc. So don't try it. Conceptually, we're "checking out" the latest version of what's committed to the repository.
| git checkout . | Everything from here down--dangerous of course |
| git checkout <filename> | Revert the named file |
If you make extensive changes, commit and push to a remote, then discover that what you've done was not the best thing, here's how to fix it: