Re: Branches and Commits and Cherry-Picking

2019-10-07 Thread Carlos Rovira
HI Alex, right, I'm only saying that as part as the natural process, people should not need to ask for agreement, since what is in develop should not go to release. And if something need to be fixed in release it will happen there (of course promoted by some discussion about something is not

Re: Branches and Commits and Cherry-Picking

2019-10-05 Thread Alex Harui
On 10/5/19, 7:08 AM, "Carlos Rovira" wrote: Hi Alex, - release: Here's where I see differences. Once we decided we want to release, is because develop has the final state to cut a release. No more commits are needed for that release. So once a RM start the process and

Re: Branches and Commits and Cherry-Picking

2019-10-05 Thread Carlos Rovira
Hi Alex, I'm with the article exposed in [1], I think I'm using it since 2010. But I think we have a different interpretation of a release branch. For what I saw for almost 10 years using git is that we have: - master: Is the "stable" branch with "released" content. So latest release can be

Branches and Commits and Cherry-Picking

2019-10-04 Thread Alex Harui
Hi, I think we may need to be more careful about branches and commits in the future. I saw a fair number of merge conflicts for the RM to have to resolve to merge the release branch back into develop. The use of cherry-picking may be part of the problem. I wrote down my thoughts on the