[
https://issues.apache.org/jira/browse/FINERACT-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17207340#comment-17207340
]
Petri Tuomola commented on FINERACT-1154:
-----------------------------------------
[~aleks] Yes, you're absolutely right: as we are making the same change in the
develop branch and in the release branch - but as two different PRs / commits -
git will see these as merge conflicts.
In the worst case we would then need to manually resolve these changes when
merging the release branch to the develop branch.
But my point would be: is that the right thing to do anyway? Surely it's
error-prone in that a) we may forget some changes b) some changes may be
mistakenly different in the release branch vs develop branch.
Would it not be better to keep this consistent - i.e. make the "hotfix" changes
in the release branch only, and keep rebasing the develop branch on the release
branch (or merge from release to develop)? That way the changes are kept
consistent across the two branches, and the commit history / release tag also
works out nicely.
> Git branch strategy is wrong, use tags instead
> ----------------------------------------------
>
> Key: FINERACT-1154
> URL: https://issues.apache.org/jira/browse/FINERACT-1154
> Project: Apache Fineract
> Issue Type: Bug
> Reporter: Michael Vorburger
> Assignee: Petri Tuomola
> Priority: Major
> Fix For: 1.5.0
>
>
> It seems wrong to me that we have 20 open branches (on
> https://github.com/apache/fineract/branches), including for the just released
> 1.4.0. IMHO a 1.4.0 should be a tag not a branch, and there could be a branch
> named 1.4.x instead - if anyone actually wanted to maintain that (which I
> doubt anyone does).
> [~aleks], [~ptuomola] or anyone else reading along here, do you agree?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
