Covered commands:
git rm
vsrm <filename>
+git add <filename>
git mv
vsmv <filename> <filename2>
+git add <filename> <filename2>
git diff
git reset HEAD <filename>
git checkout -- <filename>
In the last section we modified our .gitignore file to ignore hdf5 files. Let's add it to the staging area.
$ git add .gitignore
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: .gitignore
Actually, it might be more relevant for us to ignore all of our h5 files, rather than by a name specifically. We can unstage the file and modify it.
$ git reset HEAD .gitignore
Unstaged changes after reset:
M .gitignore
$ vi .gitignore
$ git status
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: .gitignore
no changes added to commit (use "git add" and/or "git commit -a")
If we concatenate the file, we can see that we've modified our file as expected.
$ cat .gitignore
*.h5
To unstage the file, we've used git reset HEAD <filename>
. Earlier in history, we talked about HEAD pointing to a specific commit. This specific usage of HEAD with git reset
unstages files. If we use a variant of git reset and use git reset HEAD~2 <filename>
, git will get the version of filename in two commits previously and put it in the staging area. git reset will always affect the staging area of your repository.
We can also completely remove changes we've made in the working directory with git checkout -- <file>
. This will return us to the version of the file at our last commit. However, this is slightly dangerous because you will completely lose the changes you've made. If you want to save your changes for later, you can see some of the extras at the end of the lesson using git stash
.
git diff
, like its sister command diff, will compare different files or
versions of a file. On its own git diff
will tell us the difference in our working directory that we haven't yet staged for commit. We can also compare arbitray versions of the file using commit hashes or branch names.
Now that we have unstaged .gitignore, we can use git diff
$ git diff .gitignore
diff --git a/.gitignore b/.gitignore
index 511561c..79df784 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-mydata.h5
+*h5
Sometimes we need to delete files out of our repository, rename them, or move them in and out of the staging area. git has commands to help us do this. We don't have to use these commands, but unstaging them if we decide we want to go back is much easier using them.
git rm <filename>
will remove the file completely from the working directory and show that it has been deleted
$ git rm AUTHORS.md
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
deleted: AUTHORS.md
this looks different than if we just remove the file. First let's go back to our old copy of AUTHORS.md
$ git checkout HEAD AUTHORS.md
and now try to delete it the normal way.
$ rm AUTHORS.md
$ git status
On branch master
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
deleted: AUTHORS.md
no changes added to commit (use "git add" and/or "git commit -a")
in order to commit this change, we'd also need to do git add AUTHORS.md
to put our deleted file into the staging area. git rm
makes this process more convenient.
Similarly, we can move files with git mv <oldname> <newname>
, which renames oldname to newname, and then adds oldname and newname to staging.
$ git mv AUTHORS.md contributors.md
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: AUTHORS.md -> contributors.md
tips:
- just like diff, git has a special
git grep
command that only greps files tracked in the git repository. This is especially nice to use if you have large data files in your directory but they aren't version controlled by git. - git helps save us from ourselves. Without using version control, rm would make us lose a file forever. Thanks to version control we can restore it.