Question

My understanding of git add is that you’re basically saying to your local git repo “Yes, I’m sure I want to make these changes.”

My understanding of git commit is to actually save the changes to your local HEAD branch. At this point they are actually in version control, but are only local to your instance of git.

My understanding of git push is to propagate your saved (committed) changes to the master repo, so other developers (or perhaps a CI build) can pull them down for themselves.

If anything that I have said so far is wrong or is misleading, please begin by correcting me. Assuming I’m correct in my understandings, I originally had a package in my Java project that looked like this:

com.myapp.server.servlets
    FizzServlet
    BuzzServlet

But then I decided to refactor the names and of a few things, as well as both adding & deleting some new files/packages:

com.myapp.server.servlet
    FizzesServlet
    WidgetServlet
    com.myapp.server.servlet.impl
        FizzesServletImpl
        WidgetServletImpl

Overall, I account for 5 changes to this directory:

1. Changed the name from “com.myapp.server.servlets” to “com.myapp.server.servlet“
2. Changed the name from “FizzServlet” to “FizzesServlet“
3. Deleted the BuzzServlet altogether
4. Added a new WidgetServlet
5. Added a new com.myapp.server.servlet.impl package with two child files

Do I have to do any sort of special command magic here, because I did so much refactoring, or can I just run something like git push * to push everything to GitHub? In the SVN Eclipse plugin, if I renamed a package or source file, and then tried committing that change, I would often lose the file altogether (locally) and have to restore from local history. Even then, I got burned far too many times to count and lost a lot of work. I’m hoping not to get the same experience with Git.

Answer 1

From the way you’re very careful about pushing, your understanding of git push is not quite complete. push will literally only push your commits to your remote — that means, it will copy the exact state that you saved in the commit(s) you have made since last pushing. In Git, every commit is a snapshot of all the files in a repository (it does in fact record all files, and not just the changes). So what you see locally after committing will be exactly what’s copied onto the remote when pushing.

When you push, one of two things can happen:

1. The push succeeds, in which case all is well and the state of the remote mirrors the state of your local repo (to emphasize this, remember that git commits are identified by their SHA hash — if the commit were different, so would the hash be)
2. The push gets rejected, because it is not fast forward. This happens when someone else has pushed commits onto your remote since your last pull/fetch, and it is the equivalent of the nasty and oft-feared conflict when trying to commit in SVN. However, your local state is not affected by this. You will have to resolve the conflict (a) dropping your commits and accepting the state of the remote (git reset is used for this) or by fetching from the remote and (b) merging your local changes, thereby creating a merge commit which will indicate the diverging and re-converging of your history, or alternatively (c) rebasing onto the remote, to produce linear history.

The conflict resolution case will take a bit more looking into, but the actions required are well-described in the Pro Git book (chapters Branching, Merging, Rebasing).

A conflict can only happen if someone else can push to your remote, or if you push to your remote from another computer. If you are working in a single-user single-computer scenario (at least for now), there will be no conflict when pushing.