I'd like to try git (hosted on github) for a new project, but I have a doubt on how it works. I am working with another guy, do we need to have two forks of the project and then merge them every time one of us makes a change to the code or is it possible to work in pair on a single origin?
views:
137answers:
4
+1
A:
With git you would both end up with local copies of the repository. When you push to (or pull from) the github repository you would be forced to merge if the other person made changes to a file that you had also made changes to since the last push / pull. There is no need for you both to have your own fork.
Donnie
2010-06-03 13:46:31
This is what happens generally with git, but the next answer says that github doesn't allow to have any collaborator for the project
mariosangiorgio
2010-06-03 13:55:03
I have never used github, so I can comment on their specific pricing structure. I host the repositories myself.
Donnie
2010-06-03 13:59:29
Public projects allow unlimited collaborators. (Sorry to double comment here but the misinformation is spread around a bit.)
Will Robertson
2010-06-14 17:57:24
+2
A:
It's possible to have as many additional committers (called collaborators in GitHub terms) on a single project as you want. However, the maximum number is dependent on the pricing plan. Note that public repositories can have an unlimited number of collaborators.
As for Git itself: anybody who has write access to a repository can push to it.
Jörg W Mittag
2010-06-03 13:49:09
thanks, I was really surprised I didn't find that option. I need to have collaborators, what free service do you suggest to use?
mariosangiorgio
2010-06-03 13:56:34
@mariosangiorgio: As far as I know, all code hosters require you to pay for more complex project management features, such as multiple committers to the same repository. After all, this feature is only needed for proprietary codebases, and charging developers of proprietary projects is how those companies stay in business. For open codebases, all this complication is completely unnecessary, because you can just pull and merge from the other developers.
Jörg W Mittag
2010-06-03 14:03:36
I recently searched the web for just that, a free git repository provider that does allow adding collaborators and allows non-open repositories. I ended up at assembla.com
Jasper
2010-06-03 14:13:13
is there a way to pull and merge from other developers from the command line or it is only possible on the web-site?
mariosangiorgio
2010-06-03 16:05:32
@mariosangiorgio: Of course, it is possible on the command line, that's just how Git works. In fact, that is how every single version control system ever created works: Git, Mercurial, Darcs, Bazaar, Codeville, Monotone, Subversion, CVS, you name it. I didn't even know that GitHub added the possibility to pull and merge, that must have been a pretty recent addition, since it definitely wasn't there last week.
Jörg W Mittag
2010-06-03 16:38:43
@mariosangiorgio yes it is. There is one universal condition, though: that you are able to access the repository you are pulling from (perhaps it's available on the web, on your network or perhaps they are just on the same computer). Note that you can push and pull to and from your computer through the command line to and from your computer. If you want to push or pull to or from the public repository, you will need access to the public repository's computer (or they have to provide the functionality through some GUI or you must have access to a command line on that computer)
Jasper
2010-06-03 17:29:00
@mariosangiorgio To add to that, it is rather uncommon to pull to the public repository, you usually pull from it to your own computer and push from your own computer to the public repository. If someone else did work and you really want to be the one to merge it, it would make sense to tell them to push their updates to you (if they happen to have access to your repository) or to the public repository, but do so _to a new branch_. (if they pushed it to the public repository, you then pull it to yours). Then you can merge it in your repository and push those changes to the public one.
Jasper
2010-06-03 17:32:51
Public repos in Github can have as many collaborators as you like under their free plan.
Will Robertson
2010-06-14 17:52:22
@mario: if you need to host a private repo and you only have one collaborator, github is very reasonably priced, only a few bucks a month.
kubi
2010-06-14 18:08:20
+2
A:
First off, let me state that I don't have much experience with git myself. That said, let me get to my answer.
The short answer would be: yes, in a way, that's how it'll be. But it doesn't have to be as much as a problem as you state it to be.
I assumed that you know SVN for some reason, but let me know if you don't, and I'll try to write things down from a different point of view.
The SVN way, the centralized way, is that there is one repository and everyone has a working copy. In the working copy one can make changes, and then the changes can be committed to the repository. If two people had been making changes to their working copies at the same time, you might need to merge the changes, but if this is not the case everything will be automatic.
Git is decentralized. This is accomplished by not just having a single repository, but each user having his or repository. Usually the repository is accompanied by a working copy (with the working copy simply being the normal files and the repository being housed in .git. You make changes to your working copy and then commit them to your repository. Then if you decide that the changes should be visible to the public you can push the changes to your repository to the public repository.
(Note that the public repository is public only because you treat it as such git knows no different. If you are working on a single feature with your coworker Bob, you can push to bob's repository instead and only when the two of you are done push it to the public repository, or not at all, if it's just your private modification.)
Basically, with typical usage, there will be more problematic merging with git than with SVN. Luckily git's merging is also better, so you'll have to do less yourself (or so I have been told). However, there shouldn't be too much conflicts if you do not wait months before pushing something to the public repository. Better yet, if you are afraid of merging (there is little reason to be, but if you are) you can push right after every commit - in which case you won't be doing more merging than with SVN. You are giving up some of the flexibility of git, but a large part of that can again be subverted by using branches well (which automatically means using explicit merging, but in git, it's really no thing to be afraid of).
Jasper
2010-06-03 14:09:05
+3
A:
The short answer is no, as long as you're using a public repository. Head to the admin section for the repository, select the "Collaborators" pane, and add as many users as you would like to be able to commit to the repository. All users would then use the same address to clone from and push to.
Just remember to pull their changes before you push your own.
Will Robertson
2010-06-14 17:56:42