GIT：如何看到拉/推动原点的变化 [英] GIT: How to see pulled/pushed changes in origin

问题描述

我刚开始使用Git（以前是Subversion）。我遇到了真正的问题，导致我的头部无法看到原始存储库中的推送或更改。我的'架构'是这样的：

 主代码库
 
  - >开发库1 
  - >开发存储库2 
  

当我从一个dev repos备份到主代码库，我看不到那里的变化。

当我从 MAIN CODEBASE 后来拉出时，dev dev中所有以前的更改都会被覆盖。

我在这里显然缺少一个或多个要点，而且我似乎认为我知道'显而易见'的文档让我感到非常困惑。就目前而言，Git对我来说似乎毫无用处，我想知道是否要回到Subversion--这当然更容易学习和理解。

解决方案 div>

它看起来像为什么我不会请参阅git push之后的远程回购变化？
$ b

push 操作总是关于传播版本库历史记录和更新引用，永远不会触及正在运行的树文件。

特别是，如果您推送更新在远程仓库中检出工作树中的文件不会被更新。

这是一个预防性设计决定。

远程仓库的工作树可能会有本地更改，并且您无法推送到远程存储库中来解决冲突en所推动的变化和工作树中的变化

如上所述， bare remote repo 在这里比较好。

您可以设置一个在 MAIN CODEBASE 的同一位置显示非裸回购，以便查看中的变化非裸主代码库回购。

注意：即将推出的Git 1.7 ， git push 到当前检出的分支中HEAD在不是裸露的存储库中指出）将被默认拒绝。

git pull 不应覆盖任何内容，至少不能没有大的警告。您是否看到过这些警告信息？ $ b

裸露表示不包含实际文件的存储库，仅包含元数据（提交）。推送到这样的存储库是安全的，因为在磁盘上的文件状态和提交 .git

$ b之间没有差异
$ b

事实上，这个远程仓库是空的（它只有 .git 文件夹，但没有签出文件）没有意味着 git clone 将会导致一个空的本地回购。

它将创建并签出一个从克隆存储库当前活动分支分出的初始分支。

---

因此，发布架构将是：
$ b $ pre $ $ $ $ $ $ $
|主服务器：[BARE-MAIN-REPO] ==（仅限拉动）==> [MAIN-REPO]
\\ --- ^^ || ^^ ||
|| || || ||
推拉推拉
|| || || ||
/ --- || vv || ||
| DEV1 PC：[DEV1 REPO] || ||
\ --- || ||
|| ||
/ --- || vv
| DEV2 PC：[DEV2 REPO]
\ ---

注意：如果你参考 Git词汇表，origin意思是默认的上游存储库。

Bare-main-Repo 是起源，即 dev1 和 dev2 的默认上游回购，这意味着这两个回购将一直通过克隆 Bare-main-Repo 。创建
（没有什么能阻止您添加其他上游回购：dev1可以将dev2添加为另一个上游回购，允许例如直接从dev2拉出）

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.

解决方案

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)

这篇关于GIT：如何看到拉/推动原点的变化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！