What will git checkout master + git reset --hard do?

Question

I 'm relatively new to git and and having some problems early on. I've made several commits, but when I try to push them I get a response that says everything is up-to-date. I feel like my problem is the same on listed in this question, but it recommends the following:

$ git log -1
# note the SHA-1 of latest commit
$ git checkout master
# reset your branch head to your previously detached commit
$ git reset --hard <commit-id>

What exactly will "checking out the master" do? I just don't want to lose the changes I've made...

screenshot of gitk:

Solution

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.

Comments

[danwoods]

So, forgive me if I'm being slow, when I checkout the master all my files will revert to the way they were before the changes and commits, but when I push it will update everything correctly; is that correct?

[Jimmy]

Assuming you run the commands you mentioned in your question between checking out the master and pushing it. When you push, git sends over all the commits that your local master branch has that don't yet exist in the remote master branch. Then it updates the remote branch pointer origin/master to point at the same commit as your local master.

[danwoods]

I ran the three commands from the other post and it's still saying everything is up-to-date

[Jimmy]

Maybe the push was already successful in one of your previous attempts and so it's reporting that it's up to date accurately. You can post a screenshot of your history in gitk so we can see what's going on. Perhaps your scenario is not the same as the one in the other question.

[danwoods]

Made more commits (when I checked out the master I lost all my changes) and it still says everything is up-to-date when I try to push.

[Jimmy]

Is this your first attempt at a push? Is your remote repository set up correctly? git push with no arguments will only push to remote branches it knows how to track.

[Jimmy]

According to the screenshot, git is correct in reporting that origin/master is up to date when you try to push. As you can see from gitk, master and origin/master are pointing to the same commit. The red dot at the top of the history shows that you have made changes but not committed them. In order to push those changes to a remote, they must be committed locally first.

[Jimmy]

git ci -a -m "made some changes" to commit. That will change the red dot in gitk to a green one and the master branch will move up to point at your new commit. Then git push will communicate with the remote repository, sending over the new commit and updating the remote branch origin/master to point at it. Committing and pushing are two distinctly different operations in git - pushing is not analogous to committing in other VCS like Subversion.

[Jimmy]

Ah, sorry. git commit by default. A lot of people set up ci as an alias to commit so you'll sometimes see them used interchangeably.

[danwoods]

Perfect. Thank you very much. It looks like the -a modifier was the thing I was missing... Thanks again

[Jimmy]

Sweet. I'll update my answer to summarize the real solution. :)

[electblake]

A little broad, I think it's worth mentioning what reset does to answer question.