为什么我必须推出我刚刚从Git中的起源中获得的更改？ [英] Why do I have to push the changes I just pulled from origin in Git?

问题描述

我从我的远程服务器上克隆了本地机器上的Git存储库。我从克隆的Git仓库是一个裸仓库。

有一件事让我感到困惑的是，当原点发生变化时，我做了 git pull origin master 来更新我的本地存储库， git status 然后告诉我，我是X在原点之前提交，其中X是即使提交日志已经完全相同，也是如此。

>所以我以后总是做一个 git push origin master ，但我只是想知道是否有人能解释为什么这是必要的，以及我是否可能不会这样做。

在我看来，如果我只是从原点拉出变更，那么两个回购应该是相同的。那么，为什么我告诉我，我在原产地之前呢？这与这是一个裸仓库的事实有关吗？

为了清楚起见，以下是更详细的情况：

我在远程服务器上有一个纯粹的git repo（集线器）。这个回购有两个克隆：我的本地机器上的dev和staging，位于同一台服务器上。

当我在dev上进行更改时， code> git push origin master 它们到裸集线器回购。然后我登录到远程服务器 cd 到stagingrepo，并执行 git pull origin master 来更新在我做完这些之后，如果我使用 git log来比较集线器和分段提交日志， pretty = oneline 我可以看到它们是相同的。

但是，如果我做 git status


  $ git status 
＃在分支主机上
＃您的分支在1次提交之前超过'origin / master'。 
 $ 
没有提交（工作目录干净）
  

从那里做 git push origin master ，我被告知：



  $ git push origin master 
所有最新的
  

一切正常，但我只是在脑海中有这个唠叨的问题，我是否在设置回购协议时没有犯错误，或者这是否正常...

解决方案

根据 man git-pull ：

合并到当前分支中远程分支<$ c


$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ c>

暂时在中留下下一个 FETCH_HEAD ，但不更新任何远程追踪分支。使用远程追踪分支，可以通过调用fetch和merge来完成相同的操作：

  $ git fetch origin 
 $ git merge origin / next 
  

强调是我的。

基本上，Git告诉你，你的更新的主文件在 origin / master 之前，这是一个 远程追踪分支为主人。由于这个跟踪分支没有被 git pull origin master 更新（如手册页所示），所以 在技术上超过它。调用 git fetch origin 更新您的远程跟踪分支，然后您可以手动合并该跟踪分支（如第二个手册页示例所示）。

AFAIK，如果你没有用 git pull 指定一个分支名称（例如 git pull origin .git / config ，并且远程追踪分支将被更新。

I have a Git repository on my local machine that I cloned from my remote server. The Git repository that I cloned from is a bare repository.

One thing that still puzzles me is that, when changes have been made on origin and I do git pull origin master to update my local repository, git status then tells me that I'm X commits ahead of origin, where X is the number of commits I just pulled.

This is despite the fact that the commit logs are already identical.

So I always do a git push origin master afterwards, but I was just wondering if anybody could explain why this is necessary and whether I might not be doing this incorrectly.

It seems to me that if I just pulled the changes from origin, the two repos should be identical. So why am I told that I'm ahead of origin then? Is this related to the fact that it's a bare repository?

Here's the situation in a bit more detail, for clarity's sake:

I have a bare git repo (hub) on a remote server. That repo has two clones: "dev" on my local machine and "staging", on the same server as origin.

When I make changes on dev, I then git push origin master them to the bare "hub" repo. Then I log on to the remote server, cd to the "staging" repo and do git pull origin master to update "staging" from "hub".

After I've done this, if I compare the hub and staging commit logs using git log --pretty=oneline I can see that they're identical.

However, if I do git status in the "staging" directory I get the following:

$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

So then I usually do git push origin master from there, and I'm told:

$ git push origin master
Everything up-to-date

Everything works properly, but I just have this nagging question in my mind whether I didn't make a mistake when setting the repos up, or whether this is normal...

解决方案

According to man git-pull:

Merge into the current branch the remote branch next:

$ git pull origin next

This leaves a copy of next temporarily in FETCH_HEAD, but does not update any remote-tracking branches. Using remote-tracking branches, the same can be done by invoking fetch and merge:

$ git fetch origin
$ git merge origin/next

Emphasis is mine.

Basically, Git is telling you that your updated master is ahead of origin/master, which is a remote tracking branch for master. Since this tracking branch is not being updated by git pull origin master (as indicated in the man page), you are technically ahead of it. Calling git fetch origin updates your remote tracking branches and then you can merge that tracking branch in by hand (as indicated in the second manpage example).

AFAIK, if you do not specify a branch name with git pull (e.g. git pull origin), it will read .git/config for what it should fetch and the remote tracking branches will be updated.

这篇关于为什么我必须推出我刚刚从Git中的起源中获得的更改？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！