2012-11-29 55 views
5

我是git的新手。我所做的是分发了我感兴趣的几个存储库,然后将它们克隆到我的计算机上与它们一起工作。从远程git存储库中更改

某些原始项目可能会因为我曾经与本地副本混淆而显着更新,或者我可能会做出一些微不足道的更改。

从我所了解的情况来看,我可以“改变”我的克隆,从原来的变化中“拉”出来。

这对我的更改有什么影响?例如,假设有一个来自原文件的文件DoSomething.cpp。我修改它,也许修正一个小错误或添加一个功能。现在! 1年后,原来的项目经历了许多修改,并且好得多。我想将这些变化“拉”到我的克隆中,但保持我的变化! (所以这是一种推动的反面)

这很容易吗?如果是这样,那么基本思路是什么?

我想从原始克隆(我改变的东西)克隆的任何变化都不会被覆盖,但我实际上可以合并我的变化和原始(在我的叉子上),并赋予能力实际检查并接受更改。 (例如,如果DoSomething.cpp已改变原来那么我需要比较的变化,以确保它们兼容。

我想这不是难事,因为我是叉的所有者我可以rebase或硬重置它然后把我的本地更改我的叉子?(不知道是否会工作虽然因为是版本问题,一个潜力巨大的),找出哪个分支你在,这是用git status

+0

'混帐拉--rebase'将尝试试探性地合并更改;如果它不能,它会告诉你它失败了,你必须进行合并。 –

+0

@larsmans:所以,我想我需要一些工具,可以变基,警告我,告诉我的问题,可能是我自己修复,然后尝试再次重订,直到有没有错误?也就是说,是重新设定一个全部还是没有过程? – jsmdnq

+1

所有这一切正是Git已经做的。你为什么不尝试从头开始回购? –

回答

0
  1. ,它会告诉你第一行或第二行的分支名称。

  2. 用于测试,我建议先岔开更改到一个单独的分支:

    git checkout -b my-patches 
    
  3. 现在确保所有的修改被提交。为此,您再次调用git status。理想情况下,应该显示工作目录干净,但如果那不是的情况下,使用git add将更改添加到索引和git commit最终提交它们。如果您想将您的更改分成几个不同的补丁集(发生冲突时可以很方便),我建议您阅读如何使用git commit -p。你这样做,直到所有的更改不再在git status中列出。在git status中会列出一些你没有碰到的文件,可能是编译结果。如果没有任何变化,你有兴趣保持在那里,你没事。

    如果有任何的makefile或这样的支持清理目录(make clean为例),现在运行它们。

  4. 然后切换回原来的分支,使用(替代master与任何分支的名称在步骤1中发现):

    git checkout master 
    

    如果你想确保一切正常,运行:

    git diff my-patches 
    

    它应该列出你在叉改线。如果不是,出了点问题。

  5. 现在来了可怕的部分。您现在将丢弃对此分支所做的任何更改。请注意,如果您按照步骤3中所述将所有更改提交到单独的分支,则它们将会正常。如果您不确定,可以通过复制整个存储库文件夹来进行备份。然后运行(再次,替代master,不管你有前):

    git fetch 
    git reset --hard origin/master 
    
  6. 理想情况下,你的部门要现在有origin/master分支的确切状态。确保一切都看起来没问题。然后你使用合并回您的更改:

    git merge my-patches 
    

    Git会做到最好,使其尽可能轻松的,但会有可能会有冲突。 Git将使用>>>>`<<<<标记将相应文件中的标记标记出来。为了解决冲突,我建议你做一些互联网调查或阅读the section about Basic Merge Conflicts in the open Git Book。确保事后提交合并。

  7. 困难的部分已经结束。现在,您可以删除临时分支:

    git branch -d my-patches 
    

    我用了临时党支部的原因是为了能够方便地恢复存储库的状态,以合并前的尝试之一。当然,也可以在单独的分支中检查远程状态,但我更喜欢这样。

1

你是对的,重新定义是一种方法,你可以保持你的代码是最新的,并且非常常用。

根据我的经验,重新定义在管理你的git历史方面更有用。它使你的历史保持良好和线性,这使得它看起来像工作顺序发生而不是并行发生。另一方面,经常合并将涉及大量的分离/聚合提交。您可以使用git log --graph来直观地看到这种差异。

简而言之,rebase将您的提交,将它们转换为补丁,然后将它们应用到您重新绑定到的分支。如果存在冲突,git将停止并要求您解决它们,然后您可以继续。所以你仍然在合并和解决冲突,但只是让历史成为线性的。

0

您是否将上游遥控器添加到了您的分叉回购?这是让叉子与主人同步的最简单方法。这是第3步here

0

首先,你应该知道,你是否“合并”或“重订” 你不会失去你的变化和git会给您提交更改&解决冲突(如果有的话)的机会,然后把你的修改回到你从中拉开的远程回购。

当你git pull你告诉混帐做到这一点:(拉默认使用“合并”)

拉从远程文件的最新副本,与我的本地更改&如果将它们合并有一个冲突,你不能自动解决然后通知我,以便我手动解决它;它很简单。

当你git pull --rebase你告诉混帐做到这一点:

临时删除*从我的本地副本的变化(我修改过的文件),拉从遥控器上的最新副本,在合并我的变化顶部&如果有冲突,您无法自动解决然后通知我,以便我手动解决它。 (技术上没有被移除,它只是使这个本来模糊逻辑更清晰

的区别很微妙,在第二种情况下,你的变化似乎是因为如果你只是在做这些改变您从远程获取的最新副本的顶部......但正如您所看到的,在这两种情况下,您的更改都会一直保留(否则使用git!)。

你应该合并或重订?这是很长的讨论&有一个地方比另一个更好,并有最佳做法;一些有用的意见在本页面和更多信息,你可以在网上搜索已经提到的,只需键入“混帐合并VS底垫”,你会看到吨关于它的网页:)

希望这会有所帮助。