Question

I’m new to git for source control. I want to make sure I’m understanding everything as I go though, and very early I hit something that seems strange.

Here’s what I’m doing:

1. Create a new repository on GitHub. It offers to make a “standard” C# .gitignore file, which sounds great, so I say yes.
2. I see that there is both a Readme and .gitignore created with the repository.
3. I clone this repo to my machine using git clone [repo location] [local folder]
4. I edit the .gitignore file to add some additional ignored files and folders.
5. I enter git commit, which yields a message that says “Changes not staged for commit” but lists .gitignore as being modified.

So ultimately I add it, commit and push back to the origin, which shows my changes on GitHub. So all is well.

This is sort of confusing to me. If .gitignore wasn’t being tracked, how in the world did it get pulled down using git clone? Why did I have to add it manually before it allowed me to commit the changes?

Answer 1

This is how git views your repository:

repository  ---  staging area  ---  working directory

In the repository, you get all that is committed, in all local branches or fetched remote branches. In the working directory you have all your files, checked out from some commit, which are possibly modified. The staging area is a place where you add files to be committed, but they are not yet committed. This is because in git you can choose what to commit (unlike svn for example that you commit whatever is modified).

I strongly recommend reading this article that although is focused on git reset, it gives a very good overview of how git works.

Here is a small picture of it:

repository  ---  staging area  ---  working directory
    |                  |                    |
    |                  |                    |
    |              Check out                |
    |-------------------------------------->|
    |                  |                    |
    |                  |         add        |
    |                  |<-------------------|
    |                  |                    |
    |      commit      |                    |
    |<-----------------|                    |

The checkout is quite obvious. The second two mean you selectively add files to the staging area and then you commit them. For example:

$ touch file1 file2 file3 file4  # modify files
$ git add file1
$ git add file2
$ git commit

only commits file1 and file2 even though file3 and file4 are also modified.

Sometimes, all you want is commit whatever you have. There is a shortcut for it:

$ touch file1 file2 file3 file4  # modify files
$ git commit -a

git commit given -a option automatically adds all modified files to commit.

You could even stage parts of files, which is done by git add -p which basically shows you the pieces of the commit patch and lets you choose what changes get staged and what not. Later, with git commit you can commit whatever was staged.