충돌을 병합하지 않는 변경을 어떻게 작성합니까?

Question

자동 병합이 완벽하지 않습니다. 라인 편집 충돌이 없다고해서 구문 충돌이 없다는 것을 의미하는 것은 아니며 의미 충돌을 의미하지는 않습니다.

낮은 충돌 변경 사항을 작성하는 전략이 있습니까? 이것은 TDD 나 다른 접근법에서 벗어나는 것입니까 (물론 TDD가이를 잡는 데 도움이 될 것입니다 만 실제로 예방합니까?).

Answer 1

single responsiblity principle을 위반하는 클래스는 병합하기가 가장 어렵습니다. 아마도 병합하기 어려운 클래스를 찾는 것이 아마도 더 많은 부분의 방향으로 리팩토링되어야한다는 신호 일 것입니다.

Answer 2

우선 코드베이스가 모듈이어야합니다. 둘째, 필요한 것은 나머지 팀과 입니다. 누구나 누가 무엇을하고 있는지 알아야합니다. 내부 API에 변경 사항이있는 경우 팀 전체에 명확해야합니다.

또한 커밋하기 전에 항상 마지막 버전을 가져오고 복잡한 병합이 필요한 경우 로컬로 수행하십시오.

이것은 실제로 기술적 인 문제가 아니라 인간의 문제입니다. 소스 제어 이 올바른 통신 채널을 대체하지 않습니다. 프로젝트 관리자는 모든 변경 사항을 관리해야하며 변경 사항이 여러 사람에게 적용될 때이를 파악해야합니다.

또한 공통점이 필요합니다. :)

단위 테스트는 물론 병합 할 때 발생할 수있는 가장 도비적인 버그를 잡는 데 큰 도움이됩니다.

Answer 3

동료 개발자에게 이야기하고 가능하면 같은 코드 블록을 동기식으로 편집하지 않도록하십시오. 잘 모듈화 된 아키텍처 (소규모 클래스, 분리 된 기능)를 사용하면 거의 항상이 작업을 수행 할 수 있습니다.

우리가 충돌을 일으킨다면, 우리는 종종 테스트되지 않은 코드에 대한 단위 테스트를 쓰는 것으로 전환합니다.

Answer 4

필자는 항상 커밋이 작을수록 병합 충돌이 적다는 사실을 발견했습니다. 큰 문제가있는 사람들은 언제나 며칠 동안 일을하고 일을 처리 한 다음 한꺼번에 병합하려고합니다.

지금 나는 항상 동일한 코드베이스에있는 2 인 팀에 종사하고 있습니다. 우리는 각각 개인 지사에서 일하고 나서 우리가 일할 때마다 공유 지부에 통합합니다. 그것은 보통 하루에 여러 번입니다. 우리는 거의 갈등을 병합하지 않으며, 우리가 할 때 그들은 아주 사소합니다.

이렇게 ... 저장소에서 최신 코드를 자주 얻으십시오. 자신의 지사에서 작업하여 변경 사항을 커밋하고 나머지 팀원에게 영향을주지 않으면 서 다른 사람들의 작업을 병합 할 수 있습니다. 그런 다음 가능한 한 자주 공유 분기로 자신의 코드를 밀어서 변경 사항을 최대한 작게 만듭니다.

또한 팀과상의하십시오. 다른 사람이 특정 파일에서 작업하고 있다는 것을 알고 있다면, 작업을 시작하기 전에 기다려야 할 수도 있습니다. 가끔은 도움을 줄 수 없지만 적어도 의사 소통을 통해 복잡한 병합을 계획 할 수 있습니다 놀랐다.