> In that case, this is what we are doing. We have a corporate account which > is the "main" repo (this is where the project should be created) and each > developer then "fork" into their personal account. This could also have > been possible to achieve without such service, but I'll not explain since > it does not apply in your case. > > ... > > Then, you put on the maintainer hat, and select the company account's > repo, approve/merge the pull request. This create a new branch. We use this > approach so developers can continue working on the feature if not > completed, but as maintainer, we get a sense of changes. Next pull request > will not be a new branch. When everything is good and tested, you can > merge it back to the develop branch by simply choosing "compare", select > "your_initial/feature-name" and "develop", then click merge. >
Perfect, this is exactly what I discussed with my coworkers yesterday. We also have a corporate account (which I wasn't aware of ...shame on me for taking things into my own hands :-D ). We are going to move the repo there, then I will fork that repo for myself and follow the steps you mentioned. This is in line with what I was envisioning, which is a good thing because it lets me know we are at least on the right track. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
