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