Question

I am the sole developer on a project.
As an example, say I have the following scenario:

Office A – make changes to code, commit then push

Office B – try to pull changes, but if any changes made it complains. I want to forget any changes made and get the latest version.

Basically I am switching between offices A & B, and each time I want to commit changes to the remote repository, and then get those changes again from the next office. Git will complain as there might be some minor changes in the working copy. I’ve been using git reset –hard followed by a pull, but this doesn’t feel right somehow. I’ve looked at stash too but that seems to save changes somewhere for use at a later time.

The number of commands for git seems bewildering!

Answer 1

You (and git) are doing it exactly as you should. You’re not using git incorrectly; it’s intended to be able to push and pull from different places just like this.

The reason git complains to you, is because it’s required by the changeset model: Suppose on machine A, you made a commit with hash “abcdef”. In order to be able to share changesets between the repositories, like you want to do, commit “abcdef” must be exactly the same, everywhere. On machine B, when you pull that commit into your local changes, it might put that commit into the history in some particular place, but it cannot mix that commit with your local changes. Doing so would produce commit “3dea12”, which is entirely different.

Git could try to mix your changes on the fly, like subversion does. Consider, though, if you had committed six times: now you have to merge six times, once for each (indivisible) commit applied on the other machine. Subversion gets around this by summarizing the changes in an all-in-all blob of a diff, which it then tries to put on top of your local changes. It works sometimes, but some of the merging gets kinda screwy and it doesn’t let you keep the neat, changesets-never-change history that git offers.

To solve your problem, here’s your pull strategy on machine B:

$ git stash       # Set your uncommitted changes aside for a moment
$ git pull        # Pull in the new changes
                  # <resolve conflicts, if they happen>
$ git stash pop   # Bring back your uncommitted changes, fixing ambiguous
                  #     merge pieces as necessary.

Basically, this is the, “don’t worry, git stash isn’t scary,” strategy. 🙂

I think it’s important to notice that you will have to merge. Good development practices, keeping changes small and so on might make merges happen less often, but you will still have to merge sometimes.

By the way, you want git to complain. If your working copy is clean (no stashes needed), you’re mixing one history with another. Git will find the spots where you need to merge and ask you what to do. It’s a pretty clear process. If it has to conflate those spots with local changes as well, the history would get very confusing. That would essentially be merging things from the past with things from “the future”, which in this case is your uncommitted work (that will probably change!).

In light of that, here’s your other option:

$ git commit -m "..."    # Commit your local changes, making them part of history.
$ git pull               # Clean working copy! (maybe merging required)