Hey guys, > On Jan 27, 2015, at 2:48 AM, Gianmarco De Francisci Morales <[email protected]> > wrote: > > 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.
Just for me to be clear: GM, we’re talking rebasing locally but merge committing in the repo right? Like we have been doing before? At least, that’s how I read this right now. correct me if I’m wrong? > >> In image, I'd like to use the "github workflow" as described here: >> http://blog.endpoint.com/2014/05/git-workflows-that-work.html Having a look at that right now, thanks for the link! Cheers, Ollie
