git checkout master/branching question

Answer 1

git checkout master is to switch your working area to the master branch also known as trunk in other version control system.

Answer 2

Checking out a branch moves the local HEAD pointer so that it's pointing at the same commit that the branch references. For example:

When on branch mybranch (the Cs are commits):

                        HEAD
                        |
                        V
            master      mybranch
            |           |
            V           V
C1 -------> C2 -------> C3

After running git checkout master:

            HEAD
            |
            V
            master      mybranch
            |           |
            V           V
C1 -------> C2 -------> C3

This also moves files in your working directory as required so that it is a perfect snapshot of what the project looked like at that commit. It does not delete or alter commits, so you won't lose work in one branch by checking out another.

What has happened in the case of a "detached head" as described in that other question is that C3 is not associated with a branch. In order to fix this, you need to update the commit that the master branch points to so that it includes the new stuff (C3). Checking out master tells git that you are now working with the master branch, then doing a hard reset with the SHA1 of the commit that you want to be at the tip of your master branch updates the branch references to what you want.

Edit:

In this case, a detached head was not the issue. Just remember that committing and pushing are two different things in git. Committing does not communicate with a central repository like it does in Subversion. After you make changes to your working directory, you run git add filename once for each file you've changed, where filename is the name of the file. Once all the files have been added to the index, you commit them with git commit.

A shorthand for this is to use git commit -a which will automatically add modified files to the index before committing. This allows you to skip the git add steps. Note that git commit -a will only add modified files. If you're introducing a new file that has never been committed, you must manually add it with git add.

Once your commit has been made, you can run git push to send that commit to your remote repository and update the remote branches. This only does the remote communication stuff. Unlike Subversion, the commit itself is handled locally, without any interaction with the server.