分支 vs 分叉 vs 项目的其他选项

9 浏览
0 Comments

分支 vs 分叉 vs 项目的其他选项

我想了解在GitHub上fork一个项目和创建一个项目分支的优缺点。Fork操作使得我对项目的修改与原始项目更加独立,因为我不需要在原始项目的协作者列表中。由于我们是在内部开发项目,所以添加人员作为协作者没有问题。但是,我们想了解fork一个项目是否会使合并变更回主项目更加困难。换句话说,我想知道当我创建分支时,是否更容易在我的项目版本和主项目之间合并和推送变更。

0
0 Comments

Fork vs Branch vs 其他项目选项的问题是由Git的一般工作流程引起的。你不太可能直接推送到主项目的存储库。我不确定GitHub项目的存储库是否支持基于分支的访问控制,因为你不希望授予任何人推送到主分支的权限。

一般的模式如下:

1. Fork原始项目的存储库,以便拥有自己的GitHub副本,然后允许您推送更改。

2. 将GitHub存储库克隆到本地计算机。

3. 可选地,在本地存储库中将原始存储库添加为额外的远程存储库。然后,您将能够直接获取该存储库中发布的更改。

4. 在本地进行修改并提交您自己的提交。

5. 将更改推送到您的GitHub存储库(通常您没有在项目存储库上直接的写权限)。

6. 联系项目的维护者,要求他们获取您的更改并进行审查/合并,并允许他们推送回项目的存储库(如果您和他们都想要的话)。

如果没有这样做,公共项目很少让任何人直接推送自己的提交。

好吧...我在我的回答中没有使用"pull"这个词(但是在Git术语中,"pull"实际上是"fetch" + "merge")。你认为哪种"push"的用法是错误的?

作为贡献者,您将推送到您的GitHub分支;项目的维护者从您的分支中拉取您的贡献。

我认为你很少有机会被分配为合作者这个假设在开源世界中比在许多使用git的开发团队的组织中更为真实。我认为这是一个重要的区别,但往往没有得到足够的关注,可能这就是为什么像gitlab这样的公司蓬勃发展的原因,因为它们理解企业的需求和对控制的需求。

0
0 Comments

在项目中,出现了Fork vs Branch vs other option for project的问题。这个问题的出现是因为团队在使用Git进行版本控制的过程中,需要选择合适的方式来管理分支和协作。下面是Forking和Branching这两种选项的主要区别以及它们的优缺点。

Forking(分叉)是将项目的主分支复制一份到个人仓库中的过程。以下是Forking的优点:

- 按用户将分支分开,便于管理

- 减少主要仓库的混乱

- 团队的流程与外部贡献者的流程保持一致

以下是Forking的缺点:

- 难以查看所有活跃(或非活跃)的分支

- 在分支上进行协作更加复杂(需要Fork的所有者将其他人添加为协作者)

- 需要理解Git中多个远程仓库的概念,增加了额外的思维负担

- 对于不太熟悉Git的人来说,这将使工作流程更加困难

Branching(分支)是将所有与项目相关的工作放在一个地方的过程。以下是Branching的优点:

- 将所有工作放在一个分支中,便于管理

- 所有协作者可以推送到同一个分支进行协作

- 只需要处理一个Git远程仓库

以下是Branching的缺点:

- 废弃的分支可能更容易堆积

- 团队的贡献流程与外部贡献者的流程不匹配

- 需要将团队成员添加为贡献者才能创建分支

对于那些有很多废弃分支的项目来说,建立一个废弃分支的流程是一个不错的选择。例如,在废弃分支上进行最后一次提交,并在提交注释中写上"BRANCH ABANDONED"。这有助于找到那些在合并意图或需求时被遗漏的分支。

,Forking和Branching都是管理Git分支和协作的有效方式。Forking适用于需要与外部贡献者进行协作的项目,而Branching适用于团队内部协作的项目。根据项目的特点和需求,选择适合的方式可以提高工作效率和代码管理。

0
0 Comments

Fork vs Branch vs other option for project

在开发项目时,有时候不能直接创建分支或者拉取现有的分支并推送更改,因为你没有在该项目中注册为协作者。因此,为了允许协作,我们可以选择使用Fork来解决这个问题。

Forking实际上就是在GitHub服务器端进行的克隆,但是不能直接推送更改,而是通过添加到Fork队列中来管理合并请求。为了保持Fork与原始项目的同步,我们可以将原始项目添加为远程仓库,定期从原始项目中拉取更新,并在拉取后将当前开发的内容重新基于新的分支上。这样可以确保你的更改是直接的,没有冲突,使得你的请求更容易被原始项目的维护者接受。

Forking意味着在GitHub上你有两个“中央”仓库(即可被多个协作者看到的仓库)。如果你可以直接将协作者添加到一个项目中,那么就不需要使用Fork来管理另一个仓库。这样做的合并体验基本相同,但会多出一层间接过程(先在Fork上推送,然后请求合并),并且原始仓库的变化可能导致你之前的快速合并不再是快速合并。因此,正确的工作流程是先进行git pull --rebase upstream(将你的工作基于上游最新提交进行变基),然后进行git push --force origin,以便以一种方式重写历史记录,使得你的提交始终在原始仓库的提交之上。

总之,Fork vs Branch vs其他选项 for project的问题的出现是因为你不能直接参与到特定项目中,因此需要使用Fork来解决这个问题。与其它选项相比,Fork在GitHub服务器上进行克隆,并通过添加远程仓库、定期拉取更新和重新基于新分支来保持与原始项目的同步。这样的设计目的是为了在无法直接参与的情况下仍然可以进行协作。

0