我是git和分布式版本控制的新手,但我已经管理了init
我自己的本地源代码,在我自己的网络主机上通过ssh设置了一个私有远程存储库(origin),然后执行从主人到原籍的基本pull
和push
。 (我甚至测试了一个克隆!)
我认为我的单向,git工作流程受到控制。然而,现在,我开始考虑如何处理开发,测试和生产之间的事情。我发现的大多数教程都谈到了不同的用户合并和克隆以及拉动和推动,但在我的情况下,只是我,处理来自不同来源的东西。
希望有经验的git用户可以提供一些关于我的工作流程的见解,并提供一些关于他们如何处理合并,分支等的建议(我不太熟悉/不熟悉的事情)。
以下是我将拥有的不同机器/位置:
你会怎么处理这个?提前谢谢。
答案 0 :(得分:5)
我认为在这里创建一个过于复杂的工作流程没有意义,“中央”设置会很好地恕我直言。
所以你有一个主遥控器应该是你的中心点,它包含所有的开发,远程名称“origin”。 你在你的开发盒上工作,做你的提交,并不时地把你的东西推到“原点”。一旦你认为是时候发布你标记你的东西(可能是测试版),把它推到原点,转到你的beta服务器并从那里拉出那个标签进行公开测试。重复,直到你有一个可以拉到生产机器的版本......
关于你的A / B问题(可能是你的开发机器和笔记本电脑):当然可以做到但不能简单地将你的变化从A或B推送到原点。 让我们假设您只是将机器A上的工作推到“原点”,让我们调用该状态为“17”。现在你的工作进一步,创造当地的州“18”到“20”。如果“origin”仍为“17”,您可以将更改18-20推送到原点而不会出现问题,因为每个步骤都是前一个状态的直接后代。多数民众赞成在git中称为“快进”。
然而,如果来自B的推进介于两者之间,则“直接后代”的行被打破,而来自A的推动将失败。解决方案很简单:A必须从原点拉出,将B引入的所有更改合并到A中,然后才能推送...
希望澄清事情..
答案 1 :(得分:2)
如果您自己工作,那么如果您不愿意,您根本不需要分支或合并。 Git只是比其他版本控制系统更容易做到这一点,所以可以使用分支,就像你在其他地方使用标签一样。我强烈推荐O'Reilly关于这个主题的书 - 它的写得非常好。
答案 2 :(得分:1)
是的,它可以处理来自A的变化,另一个来自B,同时推动。但是,两者中的一个必须在它可以推动之前从原点拉出。因为其中一个与原点“过时”,因为另一个已推到原点。