Hi Matthieu, One objection I have is that instead of rebasing commits on top of the > master branch, we should actually have a merge commit. > > I don't think this "dirties" the history. On the contrary I think the > flow is clearer if you actually have a merge commit. Indeed, it groups > possibly multiple commits from a patch into a single unit that can > clearly be demarcated. To ensure this we merge using "git merge > --no-ff" (no fast-forward) > My recommendation is that the branch that is merged is named after the > jira. This makes it very easy to match the code change with the > discussion on the issue/feature. >
Yes, I totally agree on this. I was referring to merge commits when you update the local master by doing git pull from the github mirror master (i.e., Merge branch 'master' of /foo/bar/). Those commits are just artifacts of the 'git pull' and don't have any semantic. The merge of a local feature branch instead should have a merge commit, I agree, as it has a clear semantic. > In image, I'd like to use the "github workflow" as described here: > http://blog.endpoint.com/2014/05/git-workflows-that-work.html > > What do you think? > Looks good to me. +1 Thanks for the reference. > Other minor comments: > - In my case I find it more natural to have "origin" pointing to the > apache repo (= source of truth), but anyone can set this as they wish. > Sure, names are fully customizable. > - "Once I get a +1 on the branch, I can simply merge it on the apache > branch and push it to the apache git repo. [not entirely sure about > this part, butI think it should work]" --> that's also my > understanding, we'll check that soon :) > > > Matthieu > > -- Gianmarco > On Tue, Jan 27, 2015 at 10:54 AM, Gianmarco De Francisci Morales > <[email protected]> wrote: > > Hi, > > > > I want to share the git setup I am using to develop for SAMOA. > > I think this is a good setup but maybe you guys have better ideas. > > > > I have 2 remotes, one of the my fork on github (origin) and one of the > > apache git repo (apache). > > This is similar to the upstream/origin setup in typical github forks. > > However, afaik there will be no automatic merging of pull requests so we > > need to push them manually. > > > > ~/workspace/samoa-incubator ±[master✓] → git remote -v > > origin [email protected]:gdfm/incubator-samoa.git (fetch) > > origin [email protected]:gdfm/incubator-samoa.git (push) > > apache https://git-wip-us.apache.org/repos/asf/incubator-samoa.git > (fetch) > > apache https://git-wip-us.apache.org/repos/asf/incubator-samoa.git > (push) > > > > > > Then I have 2 branches (3 if you consider the website), one for each > remote. > > > > ~/workspace/samoa-incubator ±[master✓] → git br -v > > apache 787864b Initial import. Migrating code from > > https://github.com/yahoo/samoa/ > > gh-pages 061dd9e Initial import of the website > > * master 787864b Initial import. Migrating code from > > https://github.com/yahoo/samoa/ > > > > The master will simply track changes in the mirror. > > On the master branch I executed > > 'git config branch.master.rebase true' > > so that when I do 'git pull' it will rebase rather than merge (and avoid > > dirtying the history with merge commits). > > > > For each Jira I want to work on, I will fork a branch off master, and > then > > issue a pull request on github when done. > > Once I get a +1 on the branch, I can simply merge it on the apache branch > > and push it to the apache git repo. [not entirely sure about this part, > but > > I think it should work] > > I guess the same can be done for pull requests made by other > contributors: > > just create a branch, fetch the pull request, and merge it on the apache > > branch before pushing. > > > > Please let me know if you have any comment. > > > > Cheers, > > -- > > Gianmarco >
