03. Adding and Commiting Files

Let's now talk about adding and committing files. Since this can get wildly abstract and confusing, refer to the figure below!

Three stages of Git. — It'd be very helpful to memorize this figure!

Adding files to be tracked

As any other well-mannered developer would, let's start by creating a README file. This will be to keep track of any notes that you make along the way that we want any users to know.

$ touch README
$ git status
On branch master
 
Initial commit
 
Untracked files:
  (use "git add <file>..." to include in what will be committed)
 
README
 
nothing added to commit but untracked files present (use "git add" to track)

Upon checking the status, you'll see that your README file is untracked. This means that any modifications made to this file won't be noticed by Git. Additionally, untracked files are not in the staging area, so are not ready to be snapshotted by Git. To move the file to the staging area, simply use the add subcommand.

$ git add README
$ git status
On branch master
 
Initial commit
 
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
  
    new file:   README

The README file has now gone from its untracked state to the staging area, ready to be snapshotted. Remember that the fancy word for Git taking a snapshot is committed. We'll use this term henceforth.

Editing tracked files

Note that if we edit our files in the staging area, its edited version will move out of the staging area; the original version that was placed when running add will still be in the staging area, but the newly updated copy will not. To place the most updated copy, we have to run the add subcommand again. For example, let's try adding some text in our README.

$ echo 'Hello world! This is my fun project!' > README
$ git status
On branch master
 
Initial commit
 
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
 
  new file:   README
 
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:   README

Notice that the new edits made to the README file are not staged for the commit. We see that we must re-add the README file to place the most recent copy into the staging area. So if you have run add on your files, but decided to make some more edits, make sure to run add (if you'd like to stage the most recent copy)!

$ git add README
$ git status
On branch master
 
Initial commit
 
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
 
    new file:   README

Committing files

The next step is to commit our file to our Git repository. By committing, Git will take a snapshot of the files in our staging area.

When committing, it's mandatory to add the -m option, followed by a comment. This comment serves as a brief summary the updates you made to the code. Although you may see it as an inconvenience, a good commit message will pay off when you're trying to rollback changes in the future.

$ git commit -m 'First commit. Including a README file.'
[master (root-commit) df292d0] First commit. Including a README file.
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README

Great! Now you've committed for the first time. You may now access this specific point in time with the checksum df292d0.

Shortcut to add and commit

One more thing - we can use the -a option with the commit subcommand to automatically stage all the files that were modified and deleted. However, new files that are added that you have not told Git about with not be affected.

$ git commit -a -m "Commit message here."

Practice Makes Perfect

Try making your own edits, and use the status subcommand to continually check up on your files. Ask yourself where they are in the diagram above and try modifying the states for practice.

02. Initializing, Cloning and Checking Status

Learn how teams work in Agile

Learning Agile

Agile has revolutionized the way teams approach software development, but with dozens of agile methodologies to choose from, the decision to "go agile" can be tricky. This practical book helps you sort it out, first by grounding you in agile's underlying principles, then by describing four specific and well-used agile methods: Scrum, extreme programming (XP).

$ Check price
Amazon 4.5 logo

(25+ reviews)

More Productivity Tools resources

Ace your Technical Interview

Elements of Programming Interviews

Learn all the different scenarios of . This book is jam packed with code snippets written in C++ and Java to give you the edge you need to ace your technical interviews. Problems come with detailed solutions as well as a hint in case you get stuck, and organized by difficulty level with several variants to help you apply your knowledge more widely.

$ Check price
Amazon 4 logo

(240+ reviews)

More Algorithms resources