Skip to main content
added 593 characters in body
Source Link

I'd say it depends on following cases:

  1. If maintaining the main branch, the correct place is hotfix/.
  2. If maintaining the release/ branch, the correct place is bugfix/.
  3. The best case scenario (and if possible) is to maintain refactoring candidates in the feature/ branch right away.

Keep in mind that the options 1. and 2. are real world scenarios and covered by the git flow strategy because of meeting release deadlines or saving costs (or better gaining profit in time or money). So I don't see any troubles in organizing that way since git flow updates main, develop and feature/ branches in order.

Comment: If you have never expirienced case 1 or 2 then feel lucky and share good vibes with othersso far this might change if development goes on.

EDIT: 2025-01-21 10:45 Since I'm still convinced with my answer a further approach came into my mind. Why not refactoring the release-branch if there shall be a unique rule? According to the well known picture of nvie.com the release branch might be an accepted candidate for refactorings since it's also a place for bugfixes. The refactoring changes are going to develop and main branch which meets all criterias. Source: https://nvie.com/img/git-model@2x.png

I'd say it depends on following cases:

  1. If maintaining the main branch, the correct place is hotfix/.
  2. If maintaining the release/ branch, the correct place is bugfix/.
  3. The best case scenario (and if possible) is to maintain refactoring candidates in the feature/ branch right away.

Keep in mind that the options 1. and 2. are real world scenarios and covered by the git flow strategy because of meeting release deadlines or saving costs (or better gaining profit in time or money). So I don't see any troubles in organizing that way since git flow updates main, develop and feature/ branches in order.

Comment: If you have never expirienced case 1 or 2 then feel lucky and share good vibes with others.

I'd say it depends on following cases:

  1. If maintaining the main branch, the correct place is hotfix/.
  2. If maintaining the release/ branch, the correct place is bugfix/.
  3. The best case scenario (and if possible) is to maintain refactoring candidates in the feature/ branch right away.

Keep in mind that the options 1. and 2. are real world scenarios and covered by the git flow strategy because of meeting release deadlines or saving costs (or better gaining profit in time or money). So I don't see any troubles in organizing that way since git flow updates main, develop and feature/ branches in order.

Comment: If you have never expirienced case 1 or 2 so far this might change if development goes on.

EDIT: 2025-01-21 10:45 Since I'm still convinced with my answer a further approach came into my mind. Why not refactoring the release-branch if there shall be a unique rule? According to the well known picture of nvie.com the release branch might be an accepted candidate for refactorings since it's also a place for bugfixes. The refactoring changes are going to develop and main branch which meets all criterias. Source: https://nvie.com/img/git-model@2x.png

correct typo
Source Link

I'd say it depends on following cases:

  1. If maintaining the main branch, the correct place is hotfix/.
  2. If maintaining the release/ branch, the correct place is bugfix/.
  3. The best case scenario (and if possible) is to maintain refactoring candidates in the feature/ branch right away.

Keep in mind that the options 1. and 2. are real world scenarios and covered by the git flow stragetystrategy because of meeting release deadlines or saving costs (or better gaining profit in time or money). So I don't see any troubles in organizing that way since git flow updates main, develop and feature/ branches in order.

Comment: If you have never expirienced case 1 or 2 then feel lucky and share good vibes with others.

I'd say it depends on following cases:

  1. If maintaining the main branch, the correct place is hotfix/.
  2. If maintaining the release/ branch, the correct place is bugfix/.
  3. The best case scenario (and if possible) is to maintain refactoring candidates in the feature/ branch right away.

Keep in mind that the options 1. and 2. are real world scenarios and covered by the git flow stragety because of meeting release deadlines or saving costs (or better gaining profit in time or money). So I don't see any troubles in organizing that way since git flow updates main, develop and feature/ branches in order.

Comment: If you have never expirienced case 1 or 2 then feel lucky and share good vibes with others.

I'd say it depends on following cases:

  1. If maintaining the main branch, the correct place is hotfix/.
  2. If maintaining the release/ branch, the correct place is bugfix/.
  3. The best case scenario (and if possible) is to maintain refactoring candidates in the feature/ branch right away.

Keep in mind that the options 1. and 2. are real world scenarios and covered by the git flow strategy because of meeting release deadlines or saving costs (or better gaining profit in time or money). So I don't see any troubles in organizing that way since git flow updates main, develop and feature/ branches in order.

Comment: If you have never expirienced case 1 or 2 then feel lucky and share good vibes with others.

deleted 1 character in body
Source Link

I'd say it depends on following cases:

  1. If maintaining the main branch, the correct place is hotfix/.
  2. If maintaining the release/ branch, the correct place is bugfix/.
  3. The best case scenario (and if possible) is to maintain refactoring candidates in the feature/ branch right away.

Keep in mind that the options 1. and 2. are real world scenarios and covered by the git flow stragety beacausebecause of meeting release deadlines or saving costs (or better gaining profit in time or money). So I don't see any troubles in organizing that way since git flow updates main, develop and feature/ branches in order.

Comment: If you have never expirienced case 1 or 2 then feel lucky and share good vibes with others.

I'd say it depends on following cases:

  1. If maintaining the main branch, the correct place is hotfix/.
  2. If maintaining the release/ branch, the correct place is bugfix/.
  3. The best case scenario (and if possible) is to maintain refactoring candidates in the feature/ branch right away.

Keep in mind that the options 1. and 2. are real world scenarios and covered by the git flow stragety beacause of meeting release deadlines or saving costs (or better gaining profit in time or money). So I don't see any troubles in organizing that way since git flow updates main, develop and feature/ branches in order.

Comment: If you have never expirienced case 1 or 2 then feel lucky and share good vibes with others.

I'd say it depends on following cases:

  1. If maintaining the main branch, the correct place is hotfix/.
  2. If maintaining the release/ branch, the correct place is bugfix/.
  3. The best case scenario (and if possible) is to maintain refactoring candidates in the feature/ branch right away.

Keep in mind that the options 1. and 2. are real world scenarios and covered by the git flow stragety because of meeting release deadlines or saving costs (or better gaining profit in time or money). So I don't see any troubles in organizing that way since git flow updates main, develop and feature/ branches in order.

Comment: If you have never expirienced case 1 or 2 then feel lucky and share good vibes with others.

deleted 1 character in body
Source Link
Loading
Source Link
Loading