分叉与GitHub中的分支
rep*_*mer 267 git branch github
我想更多地了解分支github项目与创建github项目分支的优缺点.
分叉使我的项目版本与原始版本更加孤立,因为我不必在原始项目的协作者列表中.由于我们正在内部开发项目,因此将人员添加为协作者是没有问题的.但是,我们想了解如果分配项目会使合并更改回主项目更难.也就是说,我想知道分支是否能让两个项目保持同步更容易.换句话说,当我分支时,在我的主项目版本和主项目之间合并和推送更改是否更容易？
Von*_*onC 274
您不能总是创建分支或拉出现有分支并推回到它,因为您没有注册为该特定项目的协作者.
分叉只不过是GitHub服务器端的克隆:
- 没有可能直接推回
- 添加了fork队列功能以管理合并请求
通过以下方式保持fork与原始项目同步:
- 将原始项目添加为远程项目
- 定期从原始项目中获取
- 在您从该获取更新的感兴趣的分支之上重新定义您当前的开发.
rebase允许您确保您的更改很简单(没有要处理的合并冲突),当您希望原始项目的维护者将修补程序包含在他的项目中时,使您的提取请求更加容易.
即使直接参与并非总是可行,但目标仍然是允许协作.
您在GitHub端克隆的事实意味着您现在有两个 "中央"存储库("中心"为"从几个协作者可见").
如果您可以直接将它们添加为一个项目的协作者,则无需管理另一个项目一个用叉子.
合并经验大致相同,但有一个额外的间接水平(先推上叉子,然后要求拉动,原始仓库的进化风险使你的快进合并不再快进) .
这意味着正确的工作流程是git pull --rebase upstream(在上游的新提交之上重新设置您的工作),然后git push --force origin,为了以这种方式重写历史记录,您自己的提交始终位于原始(上游)repo的提交之上.
也可以看看:
- 我们应该把叉子称为"树枝",因为它们被分支断开并用来开始一棵全新的树.只是我的两分钱 - 我喜欢树栖成语. (15认同)
- 老实说,即使你不需要,也总是一个好主意**拥有一个只有高级开发人员,团队领导或其他"可信赖的"人才可写的神圣回购**.所有其他团队成员应该在他们的forks(〜sandboxes)中工作,并以pull请求的形式贡献他们的更改.由于DVCS使其成为可能,我们将其作为"最佳实践"进行了调整,即使在最小的项目中也能成功使用它...... (12认同)
- @reprogrammer:如果你可以添加协作者,则不需要分叉.他们可以在本地重新绑定然后在目标分支上合并,然后直接推送到*one*central repo,而不是必须管理*two*central repo(原始的一个和fork).rebase将大致相同,但在涉及fork时会有额外的间接.再次:这里不需要.我已经更新了我的答案. (7认同)
- 我们正在内部开发一个项目,将人员添加为合作者没有问题.但是,我们想了解如果分配项目会使合并更改回主项目更难. (3认同)
- @intland所以你更喜欢http://stackoverflow.com/users/6309/vonc?tab=responses中描述的“Integration-manager工作流程”？由于在一家大公司中引入了 Git，我倾向于首先采用集中式工作流程（每个人都更熟悉），然后再转向“集成管理器”工作流程。 (2认同)
Aid*_*man 63
以下是高层差异:
分叉
优点
- 保持分支由用户分开
- 减少主存储库中的混乱
- 您的团队流程反映了外部贡献者流程
缺点
- 使得查看所有活动分支(或者非活动分支)变得更加困难
- 在分支上进行协作比较棘手(fork所有者需要将此人添加为协作者)
- 你需要在Git中理解多个遥控器的概念
- 需要额外的心理记账
- 对于那些对Git不太满意的人来说,这将使工作流程变得更加困难
分枝
优点
- 在一个地方保持项目周围的所有工作
- 所有协作者都可以推送到同一个分支机构进行协作
- 只有一个Git遥控器可以处理
缺点
- 被遗弃的树枝可以更容易堆积
- 您的团队贡献流程与外部贡献者流程不匹配
- 您需要先将团队成员添加为贡献者,然后才能进行分支
Bru*_*uno 44
它与Git的一般工作流程有关.您不太可能直接推送到主项目的存储库.我不确定GitHub项目的存储库是否支持基于分支的访问控制,因为您不希望授予任何人推送到主分支的权限.
一般模式如下:
- 将原始项目的存储库分叉以拥有您自己的GitHub副本,然后您可以向其推送更改.
- 将GitHub存储库克隆到本地计算机上
- (可选)将原始存储库添加为本地存储库中的其他远程存储库.然后,您就可以直接获取在该存储库中发布的更改.
- 在本地进行修改和自己的提交.
- 将更改推送到GitHub存储库(因为您通常不会直接对项目的存储库具有写入权限).
- 联系项目的维护者并要求他们获取您的更改并进行审核/合并,然后让他们回到项目的存储库(如果您和他们想要).
如果没有这个,公共项目让任何人直接推送他们自己的提交是很不寻常的.
- @RecoJohnson你作为贡献者推动你的GitHub分叉; 项目的维护者从你的分支中获取你的贡献. (2认同)
sri*_*asy 11
Forking 从现有存储库创建一个全新的存储库（只需在 gitHub/bitbucket 上执行 git clone）
最好使用分叉：当“拆分”的目的是创建一个逻辑上独立的项目时，该项目可能永远不会与其父项团聚。
分支策略在现有/工作存储库上创建一个新分支
最好使用分支：当它们被创建为临时位置以处理功能时，意图将分支与原点合并。
更具体：- 在开源项目中，由存储库的所有者决定谁可以推送到存储库。然而，开源的理念是每个人都可以为项目做出贡献。
这个问题是通过 fork 解决的：任何时候开发人员想要改变开源项目中的某些东西，他们都不会直接克隆官方存储库。相反，他们分叉它来创建一个副本。工作完成后，他们会发出拉取请求，以便存储库的所有者可以查看更改并决定是否将它们合并到他的项目中。
其核心分支类似于功能分支，但不是创建分支，而是创建存储库的分支，而不是执行合并请求，而是创建拉取请求。
以下链接以一种很好解释的方式提供了差异：
https://blog.gitprime.com/the-definitive-guide-to-forks-and-branches-in-git/
https://buddy.works/blog/5-types-of-git-workflows
http://www.continuousagile.com/unblock/branching.html