当你是git的原始回购站时,你如何做本地拉? [英] When you're the origin repo in git, how do you do a local pull?

查看:654
本文介绍了当你是git的原始回购站时,你如何做本地拉?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一台服务器,在这里我建立了一个Git仓库。从我的客户,我可以执行


git pull origin




git push origin

和我的更改正确推送/拉到远程Git服务器。我也需要能够在服务器本身检出项目。我在设置时没有使用 init --bare ,因为我明确希望在服务器上也有工作副本。



然而,当我运行 git pull 时,我收到一条消息 fatal:您想从现在获取哪些内容?。如何查看服务器上本地工作副本的最新变化?

解决方案

修复工作副本以匹配最新更改推送

  git checkout HEAD 

可能是您要查找的内容。



客户端的推送改变了索引而不是工作文件,因此您已经开始工作了当事物的git记录已经移动时,这些文件保持不变。为了简化工作文件以支持最新的版本,您可以检出推送到服务器的最新版本。



... 编辑:



使用两个非裸仓



我刚刚意识到我给了你用于理解问题的信息(索引更改隐含,但工作文件仅显式更改),但不一定是解决问题的最佳方法。以下是我过去所做的事情,以及如果您不想要涉及中央裸仓库的建议:



在服务器上:

  git分支分段
git结帐分段

在客户端机器上:

 服务器。 

在服务器上:
git rebase master (明确地更新您的staging分支以匹配更新后的索引。)

最后,如果您想从服务器上进行更改(错误修正,您有什么),您需要将这些变更同步到master,您可以通过以下方式进行同步:



在服务器上:

 提交在暂存分支上进行的更改。 
git rebase master
git checkout master
git rebase staging $ b $ git checkout staging

现在你去了,master中的每个提交都将处于暂存状态,并且每个在暂存分支中进行的提交都将成为master中的最新提交。



即使使用非中央资源库,也应该为您制定这种工作流程。基本上,你要离开服务器的主分支,并使分段分支成为服务器的工作副本。



使用中央裸回购更清洁



一般而言,尽管网络中的2点看起来最简单,但拥有一个集中式裸仓库通常更简单,它允许您始终推拉到该位置,而无需真正思考关于它。我也推荐你可以从 github.com 得到的网页代码可视化的好处,因为这个原因(免费的开放源代码的东西,我将它用于我今天所做的一切)。


I have a server where I set up a Git repository. From my clients, I can execute

git pull origin

and

git push origin

and my changes are correctly pushed/pulled to the remote Git server. I also need the ability to checkout the project on the server itself. I did not use init --bare when I set it up, because I explicitly wanted to have a working copy on the server as well.

When I run git pull, however, I get a message fatal: Where do you want to fetch from today?. How can I check out the latest changes into my local working copy on the server?

解决方案

Fixing a working copy to match the latest changes pushed

git checkout HEAD

Might be what you're looking for.

The pushes from the client change the index and not the working files, so you have working files that are unchanged while the git recording of things has moved ahead. In order to just wipe the working files in favor of the latest incarnation, you have the checkout the latest version that got pushed up to the server.

...Edit:

Using two non-bare repositories

I just realized that I gave you the information to understand the problem (index changes implicitly but working files only change explicitly), but not necessarily the best way to fix it. Here is what I have done in the past, and what I suggest if you don't want to get a central bare repository involved:

On the server:

git branch staging
git checkout staging

On the client machine:

Hack away at some changes in master, then push to the server.

On the server: git rebase master (explicitly updating your staging branch to match the updated index.)

Finally if you want to make changes from on the server (bugfixes, what have you), you will want to sync those changes up to master as well, which you can do by:

On the server:

Commit changes made on the staging branch.
git rebase master
git checkout master
git rebase staging
git checkout staging

And there you go, every commit in master will be in staging, and every commit that was made in the staging branch will be the latest commits in master.

That kind of workflow should work out for you even with a non-bare central repository. Essentially you're leaving the server's master branch bare, and making the staging branch the working copy for the server.

Using a central bare repo is cleaner

Generally, despite that 2 points in the network seem simplest, having a "centralized" bare repository is often simpler, it allows you to always both push and pull to that location without having to really think about it. I also recommend the benefits of the web code visualization you can get from github.com for this reason (free for open source stuff, I use it for everything that I do these days).

这篇关于当你是git的原始回购站时,你如何做本地拉?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆