Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better branch model #53

Open
cyberpro4 opened this issue Nov 6, 2015 · 6 comments
Open

Better branch model #53

cyberpro4 opened this issue Nov 6, 2015 · 6 comments

Comments

@cyberpro4
Copy link
Collaborator

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?

@nzjrs
Copy link
Collaborator

nzjrs commented Nov 6, 2015

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.

@dddomodossola
Copy link
Collaborator

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

@dddomodossola
Copy link
Collaborator

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

@nzjrs
Copy link
Collaborator

nzjrs commented Nov 6, 2015

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 notifications@github.com 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
#53 (comment).

@dddomodossola
Copy link
Collaborator

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?

@nzjrs
Copy link
Collaborator

nzjrs commented Nov 6, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants