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 
> also?

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
cd 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 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to