GIT: How to see pulled/pushed changes in origin

Question

I've just started using Git (previously Subversion). I'm having real problems getting my head round being unable to see pushed or pulled changes in the original repository. My 'architecture' is this:

MAIN CODEBASE

  -->Development repository 1
  -->Development repository 2

When I push changes from one of the dev repos back up to the MAIN CODEBASE, I can't see the changes there.

When I subsequently pull from the MAIN CODEBASE, all the previous changes in that dev repo are overwritten.

I'm clearly missing one or more points here, and I'm getting very confused by documentation that seems to assume I know the 'obvious'. As it stands, Git seems useless to me and I'm wondering whether to go back to Subversion - it was certainly easier to learn and understand.

Answer 1

It looks like the question Why won't I see changes in the remote repo after "git push"?

The push operation is always about propagating the repository history and updating the refs, and never touches the working tree files.
In particular, if you push to update the branch that is checked out in a remote repository the files in the work tree will not be updated.

This is a precautionary design decision.
The remote repository's work tree may have local changes, and there is no way for you, who are pushing into the remote repository, to resolve conflicts between the changes you are pushing and the ones in the work tree

As said, a bare remote repo is better here.
You can setup a non-bare repo in the same place than MAIN CODEBASE, in order to see the changes in that "non-bare main codebase repo".

Note: with the upcoming Git 1.7, git push into a branch that is currently checked out (i.e. pointed by HEAD in a repository that is not bare) will be refused by default.

git pull should not overwrite anything, at least not without big warnings. Do you see any of those warning messages?

---

As kibitzer aptly describes in the comment:

bare means a repository which does not contain the actual files, just the metadata (commits). Pushes to such repository are safe because no discrepancy is generated between the state of files on disk and commits in .git

The fact that this remote repo is "empty" (it only has the .git folder, but no file checked-out) does not mean a git clone will result in an empty local repo.
It will create and check-out an initial branch that is forked from the cloned repository's currently active branch.

---

So, the "publication architecture" would be:

/---
| MAIN SERVER   :   [     BARE-MAIN-REPO    ] == (pull only) ==> [ MAIN-REPO ]
\---                    ^^    ||   ^^   ||
                        ||    ||   ||   ||
                       push  pull push pull
                        ||    ||   ||   ||
/---                    ||    vv   ||   ||
|DEV1 PC        :    [ DEV1 REPO ] ||   ||
\---                               ||   ||
                                   ||   ||
/---                               ||   vv
|DEV2 PC        :               [ DEV2 REPO ]
\---

Note: if you refer to the Git Glossary, what "origin" means is the default upstream repository.
Bare-main-Repo is the "origin", i.e. the default upstream repo for dev1 and dev2, meaning both those repos wll have been created by cloning Bare-main-Repo.
(Nothing prevents you to add other upstream repos: dev1 could add dev2 as another upstream repo, allowing to pull directly from dev2 for instance)

Answer 2

When you push changes to the main codebase, the git archive is update, but the checked-out working directory of the main codebase is not.

I strongly suggest you make the main codebase a --bare repository, which will prevent this confusion.

I don't know what the problem is the overwriting previous changes, that doesn't seem right to me - can you give an example?

The manpages are not there for beginners, as a tutorial, but to remind someone who already understands git how to use some feature that they are hazy about. There's plenty of documentation and howtos on the web, including the user manual.