remi icon indicating copy to clipboard operation
remi copied to clipboard

Better branch model

Open cyberpro4 opened this issue 10 years ago • 6 comments

Actually every changes / fixes / features, are pushed on master branch, but, the master branch should contain only stable / tested release. Can I suggest this model?

cyberpro4 avatar Nov 06 '15 08:11 cyberpro4

I would rather do FF rebases onto master than merges anyway.

But I think this is all a bit too early as IMO REMI is quite far from a stable API where any branch model has to be considered.

nzjrs avatar Nov 06 '15 08:11 nzjrs

Yeah, we should use that git model to ensure stable versions on master and make the repository more readable and well organized.

dddomodossola avatar Nov 06 '15 08:11 dddomodossola

John, what is the purpose of an FF rebase? I have't deep knowledge of git usage.

dddomodossola avatar Nov 06 '15 08:11 dddomodossola

For single commits - tiny bugfixes or other small things that are not large enough to be called a 'feature', it keeps the history more readable as you don't have a merge commit for every commit. For example, if a user submits a pull request with one commit then this generates a merge commit also (if merged using the git web interface). That makes the history seem messy.

That extends for local master merges, where git creates a merge commit because you git pull. Buy most definitions this is not a feature branch, it is just that your HEAD didn't agree with master and git created merge to make them agree.

Just look at the git history for all the recent small fixes by contributors

  • do all the merge commits make things readable? not really I think.

On 6 November 2015 at 09:49, Davide [email protected] wrote:

John, what is the purpose of an FF rebase? I have't deep knowledge of git usage.

— Reply to this email directly or view it on GitHub https://github.com/dddomodossola/remi/issues/53#issuecomment-154346861.

nzjrs avatar Nov 06 '15 08:11 nzjrs

Thank you for the explanation. You are right, infact I felt 'unconfortable' when submitting the merges of pull requests. However this is another aspect not strictly related with what cyberpro4 says. I mean, both thinks can coexist. We can organize better the repository for the future changes and furthermore use FF rebase. Right?

dddomodossola avatar Nov 06 '15 09:11 dddomodossola

Yes, we can, and I do in other projects, use both. FF for small things, and feature branches + merges for large things.

nzjrs avatar Nov 06 '15 09:11 nzjrs