multiple users and a single repository on github or springloops
Asked Answered
C

4

13

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.

Chanel answered 15/2, 2011 at 18:21 Comment(0)
I
18

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.

Insane answered 15/2, 2011 at 18:39 Comment(4)
Maybe github is designed to be a repo per developer, but Git itself is quite happy to let anyone with permissions push to a single repo. I don't see why you're saying that's an SVN workflow - it's quite common to have a canonical central repository that several trusted people can access.Downcome
the main issue when doing this is that we aren't sure of how this is set up. for example, I am sitting here with my laptop and desktop and want to develop on both and push pull from the central repo. does each machine need a different account and or set of keys?Chanel
A github account is ment to be used per person and not per machine so no you do not need a different account for your laptop and desktop. You can either use the same key on both or add multiple keys to your github account. If you attempt to use the same account for multiple people though it might get messy if you don't have a solid workflow. In particular if multiple people attempt to commit and push to the same branches around the same times, your history could be littered with needless merge commits.Valdis
One repository per developer is one of many valid workflows for which git is designed. A similar goal can be achieved using a single repo with an individual branch per story/ticket. (I realize the OP wanted to avoid multiple branches, but why?) Branching workflow makes things easier when multiple devs need to do work on a single ticket, since you can avoid intermediate pull requests from one dev's repo to another for WIP. Still repo per dev dominates for most OSS. Both are valid options, but for the love of god get your devs their own GitHub accounts.Rigsdaler
C
10

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.

Cordiality answered 23/10, 2013 at 20:28 Comment(0)
A
0

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.)

Artur answered 15/2, 2011 at 20:56 Comment(0)
A
-1

The answer is:

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

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

Annulet answered 18/7, 2013 at 9:20 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.