Week 2Day 2 - "Making commitments"
Let's work on our repository
The most simple way of committing a file into the repository is to create it, or copy it to the working copy of our repository and use the commands below.
The working copy is the version of the repository we have currently checked out.
This terminology will be explained more later on.
john@satsuki:~/coderepo$ touch my_first_committed_file
john@satsuki:~/coderepo$ git add my_first_committed_file
john@satsuki:~/coderepo$ git commit -m 'My First Ever Commit'
[master (root-commit) cfe23cb] My First Ever Commit
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 my_first_committed_file
john@satsuki:~/coderepo$
What we have done here, is to create a new blank file, using the unix touch command and add it into the repository using the git add command.
Windows users note, you will not have the touch command in your default command set, but if you are using Git Bash from the msysgit package, you should have it available to you.
Then we have committed it into the repository using the git commit command.
Let's make a few changes to our working copy and see what the result is.
First we are going to add another two new files, then we are going to make changes to our original file and finally we are going to run git status to see what Git has to say about our changes.
john@satsuki:~/coderepo$ echo "Change1" > my_first_committed_file
john@satsuki:~/coderepo$ touch my_second_committed_file
john@satsuki:~/coderepo$ touch my_third_committed_file
john@satsuki:~/coderepo$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: my_first_committed_file
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# my_second_committed_file
# my_third_committed_file
no changes added to commit (use "git add" and/or "git commit -a")
john@satsuki:~/coderepo$
So we can see that git status is reporting that there are changes to our first committed file, and that our second and third files are untracked.
Untracked files are ones which Git detects as being present in the working directory, but which haven't yet been added and there for upon running a commit, these files will not be added to the repository.
Notice that if we tried to run a commit now, nothing would actually be committed to the repository.
Even though there are changes to to my_first_committed_file, we have not asked Git to include these.
So, let's go ahead and do that, and at the same time we'll make a few changes to my_second_committed_file, and add those too.
john@satsuki:~/coderepo$ git add my_first_committed_file
john@satsuki:~/coderepo$ echo "Change1" > my_second_committed_file
john@satsuki:~/coderepo$ git add my_second_committed_file
john@satsuki:~/coderepo$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: my_first_committed_file
# new file: my_second_committed_file
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# my_third_committed_file
john@satsuki:~/coderepo$
Now we can see that one of the sections has changed to "Changes to be committed".
So this means that Git has recognised and remembered that we are expecting these files to be committed when we next run a git commit.
Committing the Uncommitted
In the trenches...
"John, what is going on here?" shouted Klaus from across the hallway.
The entire office had heard Klaus banging his hands down on the desk for the last fifteen minutes.
"John!" the shout turned into a scream.
"Calm down Klaus, I'm just coming."
John walked over to Klaus and pulled up one of the folding plastic chairs.
After a few minutes of fumbling he finally managed to take up his position next to an infuriated Klaus.
"John, Git is driving me crazy. I have added files to the repository and I keep running a commit, but the changes aren't getting put into the blasted repo."
Klaus was clearly distressed and John resisted the urge make jokes.
John pointed at the screen.
"Run a git status Klaus and I'll show you what the problem is."
To understand what Klaus was getting in a spin about, let's make a change to my_second_committed_file now and see how this affects things.
Remember we have already added the file, but we haven't yet made a commit.
Note - A little Linux noteIt should be noted that there is a subtle difference between > and >>.
The former will redirect the result of a command to a file, overwriting its contents.
A double arrow appends the result of a command to the specified file.
We use both of them in the examples as a way to show how we can simulate changing a file completely and appending extra lines to a file.
john@satsuki:~/coderepo$ echo "Change2" >> my_second_committed_file
john@satsuki:~/coderepo$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: my_first_committed_file
# new file: my_second_committed_file
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: my_second_committed_file
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# my_third_committed_file
john@satsuki:~/coderepo$
How interesting! We now have three sections and one of our files appears twice under both Changes to be committed and Changed but not updated.
What does this mean? If you remember back, we spoke about a staging area.
This is one area in which Git differs to many version control systems.
When you add a file into the repository, Git will actually make a copy of that file and move it into the staging area.
If you then go ahead and change that file, you would need to run another git add in order for Git to copy your changed file into the staging area.
The most important thing to remember is that Git will only ever commit what is in the staging area.
So, if we go ahead and run our commit now, we will only have the changes marked in Changes to be committed appearing in our repository.
john@satsuki:~/coderepo$ git commit -m 'Made a few changes to first and second files'
[master 163f061] Made a few changes to first and second files
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 my_second_committed_file
john@satsuki:~/coderepo$
In our examples, we have used the syntax git commit -m 'Message'.
This is a slightly special way of committing, it allows us to specify our commit log message on the command line.
If we wanted to, we could run the command git commit and this would open a text editor that we could use to input our commands.
Let us finish off our round of committing by using the git commit -a option.
This commits all of the changes to files which are already tracked.
Consequently we do not have to specify the files with git add, like we have had to previously.
Any file which has been modified and has previously been added to the repository, will have it's changes committed upon running that command.
john@satsuki:~/coderepo$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: my_second_committed_file
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# my_third_committed_file
no changes added to commit (use "git add" and/or "git commit -a")
john@satsuki:~/coderepo$
john@satsuki:~/coderepo$ git commit -a -m 'Finished adding
initial files'
[master 9938a0c] Finished adding initial files
1 files changed, 1 insertions(+), 0 deletions(-)
john@satsuki:~/coderepo$
john@satsuki:~/coderepo$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# my_third_committed_file
nothing added to commit but untracked files present (use "git add" to track)
john@satsuki:~/coderepo$
|
