-
-
Notifications
You must be signed in to change notification settings - Fork 401
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
Comments
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. |
Yeah, we should use that git model to ensure stable versions on master and make the repository more readable and well organized. |
John, what is the purpose of an FF rebase? I have't deep knowledge of git usage. |
For single commits - tiny bugfixes or other small things that are not large That extends for local master merges, where git creates a merge commit Just look at the git history for all the recent small fixes by contributors
On 6 November 2015 at 09:49, Davide notifications@github.com wrote:
|
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? |
Yes, we can, and I do in other projects, use both. FF for small things, and feature branches + merges for large things. |
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?
The text was updated successfully, but these errors were encountered: