多个用户和 github 或 springloops 上的单个存储库

发布于 2024-10-17 16:07:29 字数 225 浏览 2 评论 0原文

有谁知道如何允许多个用户从 github 或 springloops 上的完全相同的存储库工作?我们尝试的方法是与所有正在使用的 4 台机器共享相同的密钥/对,但它不起作用。一个帐户工作正常,但我们不确定如何真正协调整个推/拉/合并方面。我们想要避免的是有多个分支正在进行。

springloops 的吸引力在于,每次有人进行更改时,该更改都会自动通过 FTP 上传到开发服务器。然后只有一个人负责将开发转移到生产中。

Does anyone know of a way to allow multiple users work from the exact same repository on github or springloops?? The way that we've tried this is sharing the same key/pair with all 4 machines being used, but it's not working. one account works fine, but then we are unsure how to really coordinate the entire push/pull/merge aspect. what we wanted to avoid is having multiple branches going on.

the appeal of springloops was that everytime someone make a change, that change would be FTP'd up to the dev server automatically. Then just one person is in charge of moving dev to production.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

滥情空心 2024-10-24 16:07:29

Git 被设计为与每个开发人员的存储库一起使用。为每个人创建一个帐户,然后指定一个人作为主分支的维护者。其他人都会分叉master,他们可以自己做任何他们想做的事情。一旦他们完成某件事,他们就会向您发送拉取请求,您可以将他们的更改拉取到主分支中。然后其他人可以根据自己的喜好多次从 master 获取(每天一次、每天两次等)。
管理多个分支机构可能听起来很困难,但只要您有效沟通,这就不成问题。一旦开发人员完成了一项功能,重要的是他们向您发送拉取请求,并且他们不会只是坐在提交上而没有人知道它们。

开发人员在发送合并请求之前遵循的一个可能的好策略是让他们从 master 中拉取并确保不存在冲突。

如果您确实想使用一个帐户,则不必共享同一密钥。 Github 允许您上传任意数量的密钥。但是,如果您想要像 SVN 一样工作的东西,您应该使用 SVN,因为 Git 的设计并不遵循与 SVN 相同的工作流程。

Git was designed to be used with a repository for each developer. Make an account for each person, then designate one as the maintainer of the master branch. Everyone else will fork the master, and they can work on whatever they want on their own. Once they finish something they will send you a pull request and you can pull their changes into the master branch. Then everyone else can pull from the master as often as they like (once per day, twice per day, etc).
Managing multiple branches may sound difficult, but as long as you communicate effectively it shouldn't be an issue. Once a developer finishes a feature it's important that they send you a pull request and they don't just sit on the commits and nobody knows about them.

A possible good policy for developers to follow before sending a merge request is to have them pull from master and ensure that there are no conflicts.

If you really want to use one account, you don't have to share the same key. Github allows you to upload as many keys as you want. However, if you want something that works like SVN you should use SVN because Git isn't designed to follow the same workflow as SVN.

蓝海 2024-10-24 16:07:29

有两个主要工作流程。两者都假设每个开发人员都建立了一个免费且合理的 github 帐户:

  1. 将其他开发人员作为协作者添加到您的主存储库中,以便他们可以将更改推送到其中。
  2. 让其他开发人员分叉您的存储库并发出拉取请求以进行集成

如果一群人正在制作或维护软件产品,那么合作者是更好的选择 该项目在 github 上有一个存储库,每个开发人员都将拥有一个用于其开发工作的本地存储库。

如果有其他团队或开发人员使用他们自己的产品版本,则分叉很有用。它为他们提供了一种方式(拉取请求)来提供他们的更改以增强您的产品。每个分叉通常被认为是项目的一个独特的可行变体。

当您“信任”潜在合作者时,分叉在开源环境中也很有用。如果您发现自己经常接受他们的拉取请求,您可以“晋升”他们成为合作者。

分支很重要而且非常有用。如果多个开发人员需要共同开发一项实验性功能或对项目进行重大扩展,那么远程存储库上没有它们就很难做到。

There are two main workflows. Both assume each developer has set up a github account which is free and sensible:

  1. Add other developers as collaborators to your main repository so they can push their changes to it.
  2. Let other developers fork your repository and issue pull requests to integrate
    changes

Collaborators are preferable if a group of you are making or maintaining a software product. There is one repository for the project on github and each developer will have a local repository for their development work.

The forking is useful if there are other teams or developers using their own version of your product. It gives them a way (pull requests) to offer their changes back to enhance your product. Each fork is generally considered as a distinct viable variant of your project.

Forking is also be useful in an open source environment while you are 'coming to trust' a potential collaborator. If you find yourself routinely accepting their pull requests, you may 'promote' them to being a collaborator.

Branches are important and very useful. Its hard to do without them on the remote repo if more than one developer needs to work together on an experimental feature or significant extension to your project.

三生路 2024-10-24 16:07:29

Git 非常灵活,您可以通过多种不同的方式进行设置。然而,人们对使用 git 时应遵守的良好约定有非常强烈的看法。然而,它的设置需要一些协调,但某些方式可能需要或多或少的协调。要搜索的通用术语是“git 工作流程”,以查找有关此问题的讨论。

请注意,每个 git checkout 都是一个存储库,因此从某种意义上来说,每个开发人员确实必须拥有自己的存储库。 github 上很可能只有一个“共享”存储库,要么有多个密钥,要么只有一个密钥。这需要预先进行更多的协调——你们必须就开发的方向达成一致。通过多个“公共”存储库,您可以延迟此过程。人们可以查看彼此的工作并讨论是否应该将其合并到一个受祝福的存储库中。

(您还可以在一个存储库上使用多个分支来执行此操作,您还可以通过发送补丁集进行讨论,这只是哪个更容易的问题。)

Git is extremely flexible, and you can set it up in many different ways. However people have very strong opinions on what are good conventions to adhere to in using git. However it is setup requires some coördination, but certain ways can require more or less. The general term to search for is "git workflow" to find discussions about this.

Note that every git checkout is a repository, so in some trivial sense every developer must indeed have their own repository. It is quite possible to only have one "shared" repository on github, either with multiple keys, or one key. This requires more coördination up front -- you have to agree on where the development is headed. With multiple "public" repositories, you can delay this. People can look at each other's work and discuss whether it should get merged into a blessed repository.

(You can also do this with multiple branches on one repository, and you can also do discussions via sending around patch sets, it's just matter of what's easier.)

冰魂雪魄 2024-10-24 16:07:29

答案是:(

chgrp -R <whatever group> gitrepo
chmod -R g+swX gitrepo

找到:https://serverfault.com/a/27040/138239

The answer is:

chgrp -R <whatever group> gitrepo
chmod -R g+swX gitrepo

(Found: https://serverfault.com/a/27040/138239)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文