2013/3/28 Daniel Narvaez <dwnarv...@gmail.com>: > Hi, > > I started experimenting a bit with github code reviews, with Walter as > ginuea pig :) We wasn't too sure about stuff like rebasing, using > separate branches etc, so tonight I played a bit myself with creating > pull requests. > > Something like the following might be a decent start for a workflow > > 1 Create one branch per topic > > git checkout -b topic1 > > 2 Make one or more commits > 3 Push the branch > > git push origin topic1
Yeah, and testing will be encouraged in this branch. > 4 Submit a pull request for the branch (web UI) > > 5a The reviewer merges the patch. > 5b The reviewer rejects the patch (and closes the request). > 5c The reviewer requires changes (and closes the request). > > If 5c: > > 6 Make changes using interactive rebase > (http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) > > git rebase -i master > > 7 Push the changes to another remote branch Is there a need for a new branch for each pull request? Pushing again to the topic1 will automatically update the pull request in github. I think we should have shortcuts too, to not block too much. For a simple patch for example, the maintainer could be able to add minor tweaks to the pull request and do a manual merge, instead of asking another reviewing loop. > git push origin topic1:topic1-try2 > > 8 Submit the new pull request (web UI) > > > If someone has experience with github suggestions would be welcome. > Otherwise I hope Walter will keep being the ginuea pig in this > experiment :) -- .. manuq .. _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
