On Wednesday, November 20, 2013 11:36:30 AM UTC-5, Huu Da Tran wrote:

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

I forgot to mention the following steps... Then you announce the merge or 
on a daily basis, each developer need to merge back those changes.

on the local machine:

git pull main develop

I like to pull straight from the remote so the merge commit message 
indicates the remote repo and not a local one. But they could also do

git fetch main
git merge main/develop

You will see changes from the develop branch... and also other new branches 
or updated branches following pull requests.

To go further, I usually delete branches from the fork to not confuse when 
doing pull requests. Since developer should not commit to master or 
develop, just delete them from the fork.


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