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 (ie 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", ie 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 .

Answer 3

I think the other answers are using a lot of technobabble to try to answer a very simple misunderstanding about the way repositories work, so I will try to answer more simply:

A repository is a controlled version of a directory, where each file that anyone adds or modifies is tracked. This may not look anything like a directory that you are used to. For example, you can't open it in Windows Explorer or type 'ls' on UNIX to see its contents.

A git repository sits within a '.git' directory within your normal filesystem. If you open it up, it looks somewhat unrecognizable. In your case there is one of these repositories on each development machine and on the MAIN CODEBASE machine (this is why git is called a distributed version control system). Remember, this repository is different from the actual files, which usually appear in the same directory as the .git directory. Therefore if you push to your main repository, the actual files sitting next to the repository don't get changed at all - only the repository does. If those files don't exist at all, you have a bare repository like others have mentioned.

For purposes of comparison, a svn repository sits only in one place, usually on a server in a totally separate location from the actual files themselves. Like in a git repository, opening up this directory shows some unrecognizable files. Most people never even care about this, since when they check out files, they get all the contents onto their local machine.

To make a long story short, if you want to have a main codebase machine, it doesn't need the files at all, just the repository. This is true for both SVN and git.

Answer 4

I think we need more information, perhaps post some git status output and so on?

From what you've got here I'd say your remote (origin) repositories aren't 'bare'. All 'central'-like repositories should be bare. Just because you push to a repository doesn't mean it should update it's working copy (what if it has changes!?).

In other questions you are asking what a bare repository is.

A bare repository is, quite simply, a repository without a working copy .