Git - pulling changes from clone back onto the master

Question

I cloned a Git master and made a lot of changes on the clone. I have since committed these changes on the clone and now want the master to be a carbon copy of what is on the clone.

I've tried Git push on the clone to push the changes to the master - but nothing I do updates the master.

How can I make the master an exact copy of what is on the clone? What is the command workflow of updating the clone and having the master sync with the clone?

Answer 1

There are 2 kinds of git repository, bare and non-bare. A non bare repository is any repository which has a 'working copy' i.e. some part of the repository currently checked out.

You can push into a non-bare repository, but it won't update the checked out working copy even if the checked out branch is the same as the branch you pushed. This is because the checked out copy might have changes that aren't committed, and git won't ever destroy changes without you explicitly asking (usually such commands have a --hard argument)

Read Why won't I see changes in the remote repo after "git push"? and How would I use "git push" to sync out of a firewalled host? for a full description of the problem and a potential solution. Word of warning, if you've pushed into a remote repo, any non-committed changes in that remote-repo will have to be discarded.

Generally it sounds like the approach you want isn't really adopted by gitters, because it doesn't really match the distributed repository mentality. It's your own responsibility to make sure your copy of the repo is up to date.

Answer 2

If you have created your own clone that is easily accessible from the master, then you can easily pull the changes from the clone into the master. Just:

git pull /path/to/clone

This will pull the changes from the HEAD of clone into the HEAD of master.

Another common case is where the clone is on another network or something not easily accessible directly from the master. In this case, you could use one of:

• a common repository that the clone pushes to and the master pulls from (eg. github or just a bare repository somewhere)
• git-bundle to move a bundle of changes as a file
• git-format-patch and git-am to send changes via email

Answer 3

I like Gareth's and Greg's answers. I'd simply add that I find it really handy to use a bare repository to synchronize work with others. That lets anyone push/pull their changes (including branches) to the bare repository and then others can fetch/pull/merge as they see fit. It's not the same as having a single, central repository since each clone is a full-fledged repository.