On Wednesday, November 20, 2013 10:42:28 AM UTC-5, Greg Freeman wrote:
> Huu you are correct. I left out something that is quite important. I am
> using bitbucket/github depending on the project. This fork is through their
> site. As far as I understand it, the benefit, besides easy pull requests,
> is also so you can push your local changes to a server-side repo without
> them being integrated back into the main code base. Then, if your hard
> drive or something goes bad, your local changes that have been pushed to
> your "fork" in the cloud are backed up. Am I correct in this understanding
Yes, but the backup is also possible using any remote server to host that
To answer your question, yes I am using a hosting site, and I'm interested
> in the "other way" to avoid different repo names.
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.
Let's assume you have those accounts set up. As maintainer of a project,
your would have creator/admin privileges (based on bitbucket).
Each dev would do the following:
git clone g...@bitbucket.org:your_account/project_name.git project_name
git remote add main g...@bitbucket.org:company_account/project_name.git
Then, when you code in your changes, you create feature branches according
to your workflow (I'll assume "develop" branch).
git checkout -b your_initial/feature-name main/develop
This will create a tracking branch from the company develop branch.
you make your changes, commit them to your local repo... then you push to
your bitbucket repo:
git push origin your_initial/feature-name
Now, you go on the web interface, and you create a Pull Request to the
company account, with "creating a new branch"... by choosing compare and
choose your account and the "your_initial/feature-name" on the left side,
and then the company account and "your_initial/feature-name (new
branch...)" (not sure exactly, but i think it's the last one in the list).
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.
Let me know if anything is not clear, I'll try to formulate it better.
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
For more options, visit https://groups.google.com/groups/opt_out.