Git clone and overwrite local repository

Question

I would like to have an up to date copy (periodically) of the bitbucket repo on my server, but not sure which git commands I have to issue to avoid potential merge conflicts that can happen with pulls.
The only clean way I can think of is to clone to a tmp dir then copy/overwrite local repo.
But there must be a better way to achieve this?

Solution 1

Merge conflicts occur when—and only when—you do merge-like operations, such as:

• rebasing your commits
• merging your commits with someone else's, or vice versa
• using git revert to revert commits, so as to make your own branches that differ from theirs

Note the common theme here: you must have your own commits, of your own work (or of reversions of specific parts of theirs, but again these are your commits that you are adding).

Thus, if you never make your own commits, you will never have any conflicts. Of course, this means you can never make any changes—or if you do make changes, you must keep them on your branches, always separate from their branches.

But that's exactly what Git does in the first place, as long as you avoid running git merge (and git rebase and so on).

The git pull command consists of a git fetch followed by a git merge. (Well, you can configure it, or tell it, to use git rebase instead of git merge. But you don't want either one.) So ... don't use git pull.

This is good advice for anyone new to Git: avoid git pull, because it does two things, and you want to do one thing, then ponder a bit about whether you want any second thing, much less git merge or git rebase as the second thing.

As in janos' answer, if you have made no commits of your own, but want your current branch to match origin/master exactly, you can simply git reset --hard. Note that when you run git fetch—I recommend git fetch origin, not git fetch origin master¹—your Git will pick up all of their branches, but rename them all: their master becomes your origin/master, their develop becomes your origin/develop, their feature/thing becomes your origin/feature/thing, and so on.

If you do want, and therefore make, commits of your own, on your own branches, just make sure you don't name them origin/whatever (which will be confusing²) and don't try to merge or rebase them in any way until you are sure that's a good idea.

---

¹In current/modern Git, adding master restricts your Git to picking up just their master, and your Git updates origin/master as usual. In older (pre-1.8.4) versions of Git, adding master restricts your Git the same way, but also makes it not update origin/master. So you get their work, which you immediately forget all about, which does you no good. Getting only master saves you a little network time, and then you waste hours trying to figure out why you didn't get anything, only to discover that your chosen Linux distribution ships with a 400-year-old³ version of Git, for some unfathomable reason. :-)

²Git won't get confused—it knows local and remote-tracking branches just fine—but it sure will be confusing for humans to have origin/bruce as a local branch and a different origin/bruce as a remote-tracking branch.

³Slight exaggeration for humor.

Solution 2

Instead of cloning to a tmp dir and then replacing your local repository with that new clone, you can fetch from the remote and hard-reset your local:

git fetch origin master
git reset --hard origin/master

There won't be merge conflicts, as you're simply taking whatever is in origin/mater.