背景：假设从 master 1.0 版本新建分支重构代码，新分支叫 v2。 重构过程中，master 1.0 不断有新的修改或 bug 修复合并。等到 v2 开发完成时，两个分支之间差异太多，冲突也很多。
这样的场景下，如何处理才能比较好的发布 master 2.0？
实践中，当重构代码时，如何操作才能比较好的避免大量冲突的出现？
迷茫2017-05-02 09:28:06
안녕하세요. 합병 시 플러시 아웃을 처리하는 간단한 방법은 없습니다. 해당 사업 담당자가 하나씩 처리해야 할 수도 있습니다.
리팩토링 방식에 대해 몇 가지 이의가 있습니다. 리팩토링 과정에서 마스터가 버그를 처리하고 기능을 릴리스해야 합니다. v2가 시간에 맞춰 병합되지 않는 이유는 무엇입니까?
매번 마스터 1이 정식 출시되면 마스터 2도 시간 맞춰서 병합할 수 있고 충돌 횟수도 줄어들 거예요!
过去多啦不再A梦2017-05-02 09:28:06
저희도 비슷한 문제에 직면했습니다.
예를 들어 stable 버전이 있으면 그 아래에 fs
라는 디렉터리가 있고, 그 다음에는 개발 브랜치가 있고 그 아래에 디렉터리가 있습니다. fsv2라고 불렀습니다
개발시 새 버전이 개발되었으며, fs 디렉토리는 폐기되었으며 fsv2 디렉토리에서는 해당 fs 코드가 수정되었습니다.
이때 바로 핫픽스가 필요한 문제가 있습니다. 핫픽스가 stable fs에서 이루어지는데 어떻게 하면 개발 브랜치를 적극적으로 병합할 수 있을까요? 백포트를 수행하고 새 브랜치에 새 패치를 구현합니다.
핫픽스의 경우에는 일반적으로 stable이 필요하지 않습니다. 양쪽 모두 수행해야 하는 경우 공통 디렉터리에 넣고 보다 일반적인 모듈로 만드는 것이 가장 좋습니다. 병합합니다.
저만의 경험이라 뒤쳐질 수도 있으니 조언 부탁드립니다.
伊谢尔伦2017-05-02 09:28:06
일반적으로 마스터 1.0에서 리팩토링된 부분을 수정하지 않았다면 당연히 문제가 되지 않습니다.
리팩토링된 부분에 새로운 수정 사항이 있다면 두 작업을 수행하는 사람들의 의사소통이 잘 되어야 하며, 그렇지 않으면 병합 시 분명히 문제가 발생할 것입니다.
그러나 일반적으로 코드의 동일한 부분을 동시에 리팩토링하고 수정할 필요는 없습니다. 정말로 이렇게 하고 싶다면 두 작업을 완전히 동기화할 필요는 없습니다. 하루는 리팩토링하고 하루는 수정하고 브랜치를 반복적으로 병합하면 됩니다.