Committing changes

We will now commit the untracked files. A commit is essentially a set of changes to a set of files. Preferably, the changes making out a commit should be related to something, e.g. a specific bug fix or a new feature.

• Our first commit will be to add the copied files to the repository. Run the following (as suggested by git status):

git add Dockerfile Snakefile

• Run git status again! See that we have added Dockerfile and Snakefile to our upcoming commit (listed under "Changes to be committed"). This is called the staging area, and the files there are staged to be committed.

• We might as well commit all files in one go! Use git add on the remaining files as well:

git add config.yml environment.yml

• Run git status and see that all files are in the staging area, and that no files are listed as untracked.

• We are now ready to commit! Run the following:

git commit -m "Add initial files"

The -m option adds a commit message. This should be a short description of what the commit contains.

• Run git status again. It should tell you "nothing to commit, working directory clean".

What have we done, so far? We had some files in our working directory that we added to the Git staging area, which we subsequently committed to our Git repository. A schematic overview of this process can be seen in the following figure:

Let's repeat this process by editing a file!

• Open up environment.yml in your favorite editor, and change the version of bowtie2 to a different value, e.g. bowtie2=2.2.4.

• Run git status. It will tell you that there are modifications in one file (environment.yml) compared to the previous commit. This is nice! We don't have to keep track of which files we have edited, Git will do that for us.

• Run git diff environment.yml. This will show you the changes made to the file. A - means a deleted line, a + means an added line. There are also shown a few lines before and after the changes, to put them in context.

• Let's edit another file! Open config.yml and change the line genome_id: NCTC8325 to genome_id: ST398. Run git status. Run git diff. If we don't specify a file, it will show all changes made in any file, compared to the previous commit. Do you see your changes?

• Ok, we made our changes. Let's commit them! Run:

git add config.yml environment.yml

This will add both our files to the staging area at the same time. Run git status and see that the changes in both config.yml and environment.yml are ready to be committed.

But wait a minute! Shouldn't each commit optimally be a conceptual unit of change? Here we have one change to the genome ID used for an analysis and one change where another software version is specified: these should probably be separate. We thus want to make two commits, one for each change.

• Let's remove environment.yml from the staging area. git status tells us how to do this: "(use "git reset HEAD ..." to unstage)". So run:

git reset HEAD environment.yml

• Run git status again. See that now only config.yml is staged for being committed, whereas the changes in environment.yml are tracked by Git, but not ready to be committed.

• Commit the changes in config.yml:

git commit -m "Change to ST398 for alignment"

• Add and commit the changes in environment.yml:

git status
git add environment.yml
git status
git commit -m "Change bowtie2 version"
git status

You don't have to run git status between each command, but it can be useful in the beginning while learning what each command does.

As you can see, each commit is a point in history. The more often you commit, and the more specific you keep your commits, the better (more fine-grained) history and version tracking you will have of your files.

• We can also try to delete a file:

rm Dockerfile

• Run git status. As you can see, Git tells us that the file is deleted, but that the deletion is not committed. In the same way as we commit edits to files, we need to commit a deletion of a file:

git add Dockerfile
git status
git commit -m "Remove Dockerfile"
git status

Here we used rm Dockerfile to delete the file and git add Dockerfile to stage the deletion. You can also use git rm Dockerfile to do both these operations in one step.

• To see a history of our changes so far, run:

git log
git log --oneline

What difference do you see between the two commands?