Git推送错误'主 – >主(当前分支已经签出)'

昨天,我发布了一个关于如何将Git仓库从我的一台机器克隆到另一台机器的问题,我如何从另一台机器“克隆”?

我现在能够成功地从源(192.168.1.2)克隆到我的目的地(192.168.1.1)的Git仓库。

但是当我做了一个文件的编辑,一个git commit -a -m "test"和一个git push ,我的目的地(192.168.1.1)出现这个错误:

 git push hap@192.168.1.2's password: Counting objects: 21, done. Compressing objects: 100% (11/11), done. Writing objects: 100% (11/11), 1010 bytes, done. Total 11 (delta 9), reused 0 (delta 0) error: refusing to update checked out branch: refs/heads/master error: By default, updating the current branch in a non-bare repository error: is denied, because it will make the index and work tree inconsistent error: with what you pushed, and will require 'git reset --hard' to match error: the work tree to HEAD. error: error: You can set 'receive.denyCurrentBranch' configuration variable to error: 'ignore' or 'warn' in the remote repository to allow pushing into error: its current branch; however, this is not recommended unless you error: arranged to update its work tree to match what you pushed in some error: other way. error: error: To squelch this message and still keep the default behaviour, set error: 'receive.denyCurrentBranch' configuration variable to 'refuse'. To git+ssh://hap@192.168.1.2/media/LINUXDATA/working ! [remote rejected] master -> master (branch is currently checked out) error: failed to push some refs to 'git+ssh://hap@192.168.1.2/media/LINUXDATA/working' 

我正在使用两个不同版本的Git(远程版本为1.7,本地版本为1.5)。 这是一个可能的原因吗?

您可以简单地将远程存储库转换为裸存储库(裸存储库中没有工作副本 – 该文件夹仅包含实际存储库数据)。

在远程存储库文件夹中执行以下命令:

 git config --bool core.bare true 

然后删除除该文件夹中的.git以外的所有文件。 然后,你将能够执行git push送到远程存储没有任何错误。

我刚开始学习Git的时候也遇到同样的错误。 其他一些答案显然不适用于Git的新手!

(我将用非技术术语来说明这个想法。)无论如何,发生的事情是你有两个仓库,一个是你最初制作的原始仓库,另一个是你刚做的工作。

现在你在工作仓库中,正在使用“主”分支。 但是你也碰巧在你的原始仓库中“login”到同一个“主”分支。 现在,由于你已经login了,所以Git担心你可能会搞砸了,因为你可能正在处理原来的东西,搞砸了。 所以你需要返回到原来的仓库,做一个“git checkout someotherbranch”,现在你可以推动没有问题。

我希望这有帮助。

错误消息描述了发生了什么。 更新的Git版本拒绝通过推送更新分支,如果该分支签出。

在两个非裸存储库之间工作的最简单方法是或者

  1. 总是通过拉(或取和合并)来更新存储库,或者,如果必须的话,

  2. 通过推送到一个单独的分支(一个导入分支),然后合并该分支到远程机器上的主分支。

这个限制的原因是push操作只在远程Git仓库上运行,它没有权限访问索引和工作树。 所以,如果允许的话,在检出分支上的一个推动会把 HEAD 改变成 与远程仓库上的索引和工作树不一致。

这样会很容易意外地提交一个改变,解除了所有推送的更改,并且还很难区分未提交的任何本地更改,以及新HEAD ,索引和工作树之间的差异推动HEAD引起的。

概要

您不能推送到存储库的一个签出分支,因为它会以最可能以数据和历史丢失而结束的方式混淆该存储库的用户。 但是你可以推送到同一个仓库的其他分支。

裸仓库永远不会检出任何分支,您可以随时推送到裸仓库的任何分支。

有多种解决scheme,取决于您的需求。

解决scheme1:使用裸露的身份

正如所build议的,如果在一台机器上,你不需要工作目录,你可以移动到一个裸仓库。 为了避免与存储库混淆,您可以将其克隆:

 machine1$ cd .. machine1$ mv repo repo.old machine1$ git clone --bare repo.old repo 

现在您可以像以前一样将所有您想要的地址推送到相同的地址。

解决scheme2:推送到未检出分支

但是,如果您需要检查远程<remote>上的代码,则可以使用特殊的分支来推送。 假设在您的本地存储库中,您已经调用了远程origin并且您位于分支主机上。 那你可以做

 machine2$ git push origin master:master+machine2 

那么当你在origin远程仓库中时,你需要合并它:

 machine1$ git merge master+machine2 

对问题的解剖

当一个分支签出时,提交将添加一个新的提交与当前分支的头作为其父,并移动分支的头是新的提交。

所以

 A ← B ↑ [HEAD,branch1] 

 A ← B ← C ↑ [HEAD,branch1] 

但是如果有人可以推送到这个分支之间,用户会自己在什么git调用分离头模式:

 A ← B ← X ↑ ↑ [HEAD] [branch1] 

现在用户不再是分支1了,没有明确要求检出另一个分支。 更糟糕的是,用户现在在任何一个分支之外 ,任何新的提交只会是悬而未决的

  [HEAD] ↓ C ↙ A ← B ← X ↑ [branch1] 

假设,如果在这一点上,用户检出另一个分支,那么这个悬而未决的提交就变成了Git的垃圾收集器的公平游戏。

您可以通过编辑目标服务器上的.git/config来绕过这个“限制”。 添加以下内容以允许将git存储库推送到即使“检出”:

 [receive] denyCurrentBranch = warn 

要么

 [receive] denyCurrentBranch = false 

第一个将允许推动,同时警告可能会弄乱分支,而第二个会安静地允许它。

这可以用于将代码“部署”到不需要编辑的服务器。 这不是最好的方法,而是部署代码的快速方法。

我喜欢在远程盒子上仍然有一个可用的存储库的想法,但我不想使用虚拟分支,而是喜欢使用:

 git checkout --detach 

这似乎是Git的一个非常新的function – 我使用git版本1.7.7.4。

我遇到过同样的问题。 对我而言,我使用Git push将代码移动到我的服务器上。 我从不改变服务器端的代码,所以这是安全的。

在存储库中,您正在推送以键入:

 git config receive.denyCurrentBranch ignore 

这将允许您更改存储库,而它是一个工作副本。

运行Git推后,进入远程机器并input:

 git checkout -f 

这将使您所做的更改反映在远程计算机的工作副本中。

请注意,如果您在要推送的工作副本中进行更改,这并不总是安全的。

您可以重新创build服务器存储库并从本地分支主服务器推送到服务器主服务器。

在您的远程服务器上:

 mkdir myrepo.git cd myrepo.git git init --bare 

好的,从你当地的分行:

 git push origin master:master 

git config --local receive.denyCurrentBranch updateInstead

https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155

在服务器存储库上使用它,如果不发生未覆盖的覆盖,它也更新工作树。

VonC在评论中提到了 Git 2.3 。

我编译了Git 2.3并试了一下。 示例用法:

 git init server cd server touch a git add . git commit -m 0 git config --local receive.denyCurrentBranch updateInstead cd .. git clone server local cd local touch b git add . git commit -m 1 git push origin master:master cd ../server ls 

输出:

 a b 

耶, b被推了!

通过一些设置步骤,您可以使用类似的方式轻松地将更改部署到您的网站

 git push production 

这是好的,简单的,你不必login到远程服务器,并做一个拉或任何东西。 请注意,如果您不使用生产结帐作为工作分支,这将最好地工作! (OP的工作内容略有不同,我认为@Robert Gould的解决scheme能很好地解决这个问题,这个解决scheme更适合部署到远程服务器上。)

首先你需要在你的服务器上的某个地方build立一个裸仓库,在你的webroot之外。

 mkdir mywebsite.git cd mywebsite.git git init --bare 

然后创build文件hooks/post-receive

 #!/bin/sh GIT_WORK_TREE=/path/to/webroot/of/mywebsite git checkout -f 

并使文件可执行:

 chmod +x hooks/post-receive 

在本地机器上,

 git remote add production git@myserver.com:mywebsite.git git push production +master:refs/heads/master 

可以了,好了! 现在,将来你可以使用git push production来部署你的改变!

此解决scheme的信用转到http://sebduggan.com/blog/deploy-your-website-changes-using-git/ 。 看看那里发生了什么更详细的解释。

你可能做了什么来造成这种情况:

这种事情发生在你敲出一个小程序的时候。 你即将改变已经工作的东西,所以你施放了你的3级永久可撤销的法术:

 machine1:~/proj1> git init 

并开始添加/提交。 但是,这个项目开始变得越来越复杂,你想从另一台电脑(比如家用电脑或者笔记本电脑)开始工作,所以你需要做一些类似的事情

 machine2:~> git clone ssh://machine1/~/proj1 

它克隆和一切看起来不错,所以你从你的代码machine2工作。

然后 …你尝试从machine2推送你的提交,并在标题中得到警告信息。

这个消息的原因是因为你从这个git仓库中回收的东西只是用于machine1上的那个文件夹而已。 你可以克隆它,但推动可能会导致问题。 在两个不同的位置pipe理代码的“正确”方式是“裸”回购,就像已经提出的那样。 裸回购并不是要其中完成任何工作,而是要协调来自多个来源的提交。 这就是为什么最高评分的答案build议删除 git config --bool core.bare true之后.git文件夹以外的所有文件/文件夹。

澄清评分最高的答案:对这个答案的许多评论说:“我没有从machine1删除非.git文件,我仍然能够从machine2提交”。 那就对了。 但是,现在,这些其他文件与git repo完全“脱离”了。 去那里尝试git status ,你应该看到类似“致命的:这个操作必须在工作树上运行”。 所以,删除这些文件的build议并不是为了使machine2的提交工作 。 这样你就不会感到困惑,并认为git仍在跟踪这些文件。 但是,如果你仍然想在machine1上的文件上工作,删除文件是一个问题,不是吗?

那么,你应该怎么做?

取决于你打算在machine1和machine2上工作多less…

如果你已经完成了machine1的开发,并将所有的开发工作都转移到了machine2上,那么只需要做一下最高评价的答案: git config --bool core.bare true ,然后select删除其他所有文件/文件夹而不是从该文件夹中.git,因为他们没有跟踪,可能会导致混淆。

如果你在machine2上的工作只是一次性的,而且你不需要在那里继续开发,那么不要费心去做一个裸机。 只是ftp / rsync / scp / etc。 您的文件从机器* 2 *在机器上的文件* 1 *上,从机器* 1 *提交/推送,然后从机器* 2 *删除文件。 其他人build议创build一个分支,但是如果你只是想从另一台机器上一次性合并一些开发,我认为有点混乱。

如果您需要在machine1和machine2上继续开发…那么您需要正确设置。 你需要把你的repo转换成裸机, 然后你需要在machine1上做一个clone的工作 。可能最快的方法就是做

 machine1:~/proj1> git config --bool core.bare true machine1:~/proj1> mv .git/ ../proj1.git machine1:~/proj1> cd .. machine1:~> rm -rf proj1 machine1:~> git clone proj1.git machine1:~> cd proj1 

非常重要:因为您已将proj1的位置从proj1移动到proj1.git,所以您需要在machine2的.git / config文件中更新此位置 。 之后,您可以提交从machine2您的更改。 最后,我尝试将我的裸仓保留在中心位置,远离我的工作树(即不要将'proj1.git'放在与'proj1'相同的父文件夹中)。 我build议你也这样做,但是我想尽可能保持上述步骤的简单。

你应该只是推到一个裸仓库。 裸存储库是没有签出分支的存储库。 如果您要cd到裸仓库目录,则只能看到.git目录的内容。

实际上,将远程设置为非检出分支就足够了。 当你在另一个分支签出你的遥控器后,你可以推。

你有3个选项

  1. 再次拉动:

     git pull; git push 
  2. 推入不同的分支:

     git push origin master:foo 

    并将其合并到远程(通过git或pull-request )

     git merge foo 
  3. 强制它(不推荐,除非你故意通过rebase更改提交):

     git push origin master -f 

    如果仍然拒绝,请禁用远程存储库上的 denyCurrentBranch

     git config receive.denyCurrentBranch ignore 

我有同样的问题,使用Git来同步我的Android手机和笔记本电脑上的存储库。 对于我来说,解决scheme就是做一个拉动而不是推动,正如@CharlesBailey所build议的那样。

在Android存储库上的git push origin master对我来说是失败的,因为有一个相同的错误信息@about497因为推送到一个版本库+工作副本的非结帐而得到了。

git pull droid master在笔记本电脑库和工作复制为我工作的git pull droid master 。 当然,你需要先运行一些像git remote add droid /media/KINGSTON4GB/notes_repo/

老版本的Git用来允许推送到非裸仓库的当前签出的分支。

事实certificate,这是一个非常令人困惑的事情,允许。 所以他们加了你看到的警告信息,这也是非常混乱的。

如果第一个存储库只是作为一个服务器,然后将其转换为裸存储库,其他答案build议并完成它。

但是,如果您需要在两个正在使用的仓库之间共享分支,则可以使用以下设置来实现它

Repo1 – 将作为服务器,也可用于开发

回购2 – 将仅用于开发

安装Repo1如下

创build一个分支来共享工作。

 git branch shared_branch 

为了安全起见,您还应该创build一个$(REPO).git / hooks / update,以拒绝除了shared_branch以外的任何更改,因为您不希望人们使用您的私人分支。

 repo1/.git/hooks (GIT_DIR!)$ cat update #!/bin/sh refname="$1" oldrev="$2" newrev="$3" if [ "${refname}" != "refs/heads/shared_branch" ] then echo "You can only push changes to shared_branch, you cannot push to ${refname}" exit 1 fi 

现在在repo1中创build一个本地分支,在那里你将做你的实际工作。

 git checkout -b my_work --track shared_branch Branch my_work set up to track local branch shared_branch. Switched to a new branch 'my_work' 

(可能需要git config --global push.default upstream为了使git push工作)

现在你可以创buildrepo2了

 git clone path/to/repo1 repo2 git checkout shared_branch 

在这一点上,你有repo1和repo2安装程序工作在本地分支机构推,从repo1从shared_branch拉,无需担心该错误消息或工作目录在repo1不同步。 无论你使用什么正常的工作stream程,

以下是您可以执行的一项testing,以了解bare服务器的工作原理:

想象一下,你有一个工作站和一台服务器,上面托pipe着实时站点,并且你想不时地更新这个站点(这也适用于两个开发人员通过一个裸露的中间人来回发送他们的工作的情况)。

初始化

在本地计算机上创build一个目录,然后执行以下命令:

 # initialization git init --bare server/.git git clone server content git clone server local 
  1. 首先创build一个裸露的server目录(最后注意.git)。 这个目录只能作为你的版本库文件的容器。
  2. 然后克隆你的服务器库到一个新创build的content目录。 这是您的服务器软件提供的live / production目录。
  3. 前两个目录驻留在您的服务器上,第三个目录是您的工作站上的本地目录。

工作stream程

现在这里是基本的工作stream程:

  1. 进入local目录,创build一些文件并提交它们。 最后推送他们到服务器:

     # create crazy stuff git commit -av git push origin master 
  2. 现在进入content目录并更新服务器的内容:

     git pull 
  3. 重复1-2。 这里的content可能是另一个可以推送到服务器的开发者,也可能是local就像你从他那里得到的那样。

好的,如果你想要一个正常的远程仓库,那么创build一个额外的分支并检查出来。 将其推入一个分支(未检出),并在从本地推入之后将其合并到当前处于活动状态的分支中。

例如,在远程服务器上:

 git branch dev git checkout dev 

在本地设置:

 git push 

在远程服务器上:

 git merge dev 

我不得不在现有的裸仓库中重新运行git --init ,并且在裸仓库树中创build了一个.git目录 – 我意识到在那里inputgit status之后。 我删除了,一切都很好:)

(所有这些答案都很棒,但就我而言,这是完全不同的(据我所知),如上所述)。

我相信大多数人看到这个问题将停止在前两个巨大的答案,但我仍然想提供我的解决scheme。

遇到所述错误时,我有一个Eclipse + EGit Web项目安装程序。 什么帮助我只是使用GitHub应用程序,似乎神奇地解决了这个问题。 虽然EGit会一直拒绝推送,但GitHub桌面应用只是耸耸肩,推动我的改变。 也许它更适合处理多login的情况。

我发现的一篇文章可能对别人有用, Git在5分钟内

我有一个在Git版本控制下的Xcode项目,我想推到虚拟分布式以太网 (VDE),我有一个DC。 VDE运行Centos 5。

我读过的关于Git的文章都没有提到裸仓库。 这听起来很简单,直到我尝试了我认为应该从SVN背景来的简单的东西。

这里的build议,使远程存储库裸机工作。 更好的是我的要求是克隆的Xcode项目projectname.git ,将其复制到远程服务器; 然后推动神奇的工作。 接下来的步骤是让Xcode推送没有错误的提交,但现在我可以从terminal做它。

所以:

 cd /tmp (or another other directory on your system)<br/> git clone --bare /xcode-project-directory projectname.git<br/> scp -r projectname.git sshusername@remotehost.com:repos/<br/> 

在Xcode中提交后,要从Xcode项目中推送更改:

 cd /xcode-project-directory<br/> git push sshusername@remotehost.com:repos/projectname.git<br/> 

我肯定有一个更顺利的更复杂的方式来做到这一点,但至less这个作品。 所以一切都很清楚,下面是一些说明: /xcode-project-directory是xcode项目存储的目录。可能是/Users/Your_Name/Documents/Project_Name 。 projectname实际上就是项目的名称,但它可以是任何你喜欢称之为的东西。 Git不在乎,你会的。

要使用scp,您需要在允许SSH访问的远程服务器上拥有一个用户帐户。 任何运行自己的服务器的人都会有这个。 如果你使用共享主机或类似的东西,你可能会运气不好。

remotehost.com是远程主机的名称。 您可以轻松使用其IP地址。 为了进一步清晰起见,我使用SSH密钥在远程主机上使用Gitosis ,所以在推送时我不会提示input密码。 文章托pipeGit仓库,简单(和安全)的方式告诉你如何设置所有的。

最好的办法是:

 mkdir ..../remote cd ..../remote git clone --bare .../currentrepo/ 

这将克隆存储库,但不会在.../remote创build任何工作副本。 如果你看远程,你会看到一个名为currentrepo.git目录,这可能是你想要的。

然后从您的本地Git存储库:

 git remote add remoterepo ..../remote/currentrepo.git 

进行更改后,您可以:

 git push remoterepo master 

我只是遇到了这个问题与Heroku的部署git仓库。

我不知道Heroku为什么有一个非裸存储库,但作为解决方法,我能够重置远程存储库,并重新上传。

You shouldn't use Heroku's copy of your repository as your only git repository for collaboration, but just in case, I'll say clearly: Do not do this unless you are sure you have a full copy of your repository stored securely somewhere other than Heroku. Doing a reset will delete the repository contents.

重置:

  1. Install the Heroku toolbelt (which contains the command line client) if you haven't already.
  2. Install the heroku-repo plugin if you haven't already.

     heroku plugins:install https://github.com/heroku/heroku-repo.git 
  3. Do the reset, which deletes the repository and creates a new, empty one

     heroku repo:reset 
  4. Push to your Heroku remote as you normally would; it will reupload everything.

You will need to change the config file on the remote server once you have created empty(bare) repository, say

 root@development:/home/git/repository/my-project# cat config 

there you will see

 [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true 

You will make this bare to false to true and I removed logallrefupdates = true (not sure of its use!)

 [core] repositoryformatversion = 0 filemode = true bare = true 

You may test following

 $ git remote show origin * remote origin Fetch URL: my-portal@development:/home/XYZ/repository/XYZ Push URL: my-portal@development:/home/XYZ/repository/XYZ HEAD branch: (unknown) 

This HEAD branch: (unknown) will be shown if you are unable to PUSH. So if the HEAD branch is unknow, you should change bare to true and after push successful you can reuse the

 git remote show origin 

and you will see

  HEAD branch: master 

For me working solution is:

ON REMOTE:

 git checkout -b some_tmp_name 

ON LOCAL:

 git push 

ON REMOTE:

 git checkout master git branch -d some_tmp_name 

But this is not the real solution it's just workaround.

With Git, two regular (non-bare) repositories can't push/pull files back and forth directly. There must be an intermediary bare repository. Apparently, it's sort of like a married couple who have a kid, and the couple is getting divorced. The parents won't talk to each other, but they will communicate through the kid.

So, you have one repository, you clone this repository to a bare repository, and then you clone that to a third. The first and the third can exchange information via the second repository, the bare one. I guess this makes sense, as you wouldn't want someone able to check stuff into your repository without your consent, as that could cause merge conflicts & the like.

So, here's an example:

On PC, in ~/workspace

 git init echo "line 1" > afile.txt git add . git commit -m 'initial import' git clone --bare . ../remote-repository.git git remote add origin ../remote-repository.git git push --set-upstream origin master 

On laptop, in ~/workspace (do not do git init, etc.)

 git clone //LJZ-DELLPC/remote-repository.git/ . 

// Then make various commits, and push them:

 echo "line 2" > afile.txt git add afile.txt git commit -m 'added line 2' git push 

Then back on PC, in ~/workspace

 git pull 

// Then make various commits, and push them:

 git push 

On laptop git pull

and so forth..

Here's an absolute concrete example all on one machine, copied straight from the command window, so that we'll know that no steps were left out, that it really did work, etc:

 lylez@LJZ-DELLPC ~ $ cd gitdir /home/lylez/gitdir lylez@LJZ-DELLPC ~/gitdir $ ls lylez@LJZ-DELLPC ~/gitdir $ mkdir repo1 lylez@LJZ-DELLPC ~/gitdir $ cd repo1 /home/lylez/gitdir/repo1 lylez@LJZ-DELLPC ~/gitdir/repo1 $ git init Initialized empty Git repository in /home/lylez/gitdir/repo1/.git/ lylez@LJZ-DELLPC ~/gitdir/repo1 $ echo "line 1" > afile.txt lylez@LJZ-DELLPC ~/gitdir/repo1 $ git add afile.txt lylez@LJZ-DELLPC ~/gitdir/repo1 $ git commit -m 'initial import' [master (root-commit) f407e12] initial import 1 file changed, 1 insertion(+) create mode 100644 afile.txt lylez@LJZ-DELLPC ~/gitdir/repo1 $ git clone --bar . ../repo1-bare-clone Cloning into bare repository '../repo1-bare-clone'... done. lylez@LJZ-DELLPC ~/gitdir/repo1 $ git remote add origin ../repo1-bare-clone lylez@LJZ-DELLPC ~/gitdir/repo1 $ git push --set-upstream origin master Branch master set up to track remote branch master from origin. Everything up-to-date lylez@LJZ-DELLPC ~/gitdir/repo1 $ cd .. lylez@LJZ-DELLPC ~/gitdir $ ls repo1 repo1-bare-clone lylez@LJZ-DELLPC ~/gitdir $ mkdir repo1-remote lylez@LJZ-DELLPC ~/gitdir $ cd repo1-remote /home/lylez/gitdir/repo1-remote lylez@LJZ-DELLPC ~/gitdir/repo1-remote $ git clone ../repo1-bare-clone . Cloning into '.'... done. lylez@LJZ-DELLPC ~/gitdir/repo1-remote $ ls afile.txt lylez@LJZ-DELLPC ~/gitdir/repo1-remote $ cat afile.txt line 1 lylez@LJZ-DELLPC ~/gitdir/repo1-remote $ echo "line 2" >> afile.txt lylez@LJZ-DELLPC ~/gitdir/repo1-remote $ git add afile.txt lylez@LJZ-DELLPC ~/gitdir/repo1-remote $ git commit -m 'added line 2' [master 5ad31e0] added line 2 1 file changed, 1 insertion(+) lylez@LJZ-DELLPC ~/gitdir/repo1-remote $ git push Counting objects: 3, done. Writing objects: 100% (3/3), 260 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To /home/lylez/gitdir/repo1-remote/../repo1-bare-clone f407e12..5ad31e0 master -> master lylez@LJZ-DELLPC ~/gitdir/repo1-remote $ cd ../repo1 lylez@LJZ-DELLPC ~/gitdir/repo1 $ ls afile.txt lylez@LJZ-DELLPC ~/gitdir/repo1 $ cat afile.txt line 1 lylez@LJZ-DELLPC ~/gitdir/repo1 $ git pull remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From ../repo1-bare-clone f407e12..5ad31e0 master -> origin/master Updating f407e12..5ad31e0 Fast-forward afile.txt | 1 + 1 file changed, 1 insertion(+) lylez@LJZ-DELLPC ~/gitdir/repo1 $ cat afile.txt line 1 line 2 lylez@LJZ-DELLPC ~/gitdir/repo1 $ echo "line 3" >> afile.txt lylez@LJZ-DELLPC ~/gitdir/repo1 $ git add afile.txt lylez@LJZ-DELLPC ~/gitdir/repo1 $ git commit -m 'added line 3' [master 3fa569e] added line 3 1 file changed, 1 insertion(+) lylez@LJZ-DELLPC ~/gitdir/repo1 $ git push Counting objects: 3, done. Writing objects: 100% (3/3), 265 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To ../repo1-bare-clone 5ad31e0..3fa569e master -> master lylez@LJZ-DELLPC ~/gitdir/repo1 $ cd ../repo1-remote/ lylez@LJZ-DELLPC ~/gitdir/repo1-remote $ ls afile.txt lylez@LJZ-DELLPC ~/gitdir/repo1-remote $ cat afile.txt line 1 line 2 lylez@LJZ-DELLPC ~/gitdir/repo1-remote $ git pull remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From /home/lylez/gitdir/repo1-remote/../repo1-bare-clone 5ad31e0..3fa569e master -> origin/master Updating 5ad31e0..3fa569e Fast-forward afile.txt | 1 + 1 file changed, 1 insertion(+) lylez@LJZ-DELLPC ~/gitdir/repo1-remote $ cat afile.txt line 1 line 2 line 3 lylez@LJZ-DELLPC ~/gitdir/repo1-remote $ git --version git version 2.1.1 lylez@LJZ-DELLPC ~/gitdir/repo1-remote 

Just in case someone finds it useful. For me it was a git server permissions issue. I checked out the project from the beggining and push a simple file and then I got the "Push rejected: Push to origin/master was rejected"

My solution (in use)

  1. Checkout "master" on remote server
  2. Work locally on "dev" branch
  3. Push changes to remote dev
  4. Merge dev into master on remote

答对了