개발 지점은 언제 만들어야합니까?


11

우리는 프로젝트 팀을 하나의 Main / Trunk 브랜치에서 Main으로 정기적으로 병합해야하는 여러 Development / Work 브랜치로 옮기고 있습니다. 이 기사TFS 분기 안내서 (TFS 및 Visual Studio 2010을 사용 하고 있음)를 기반으로 새 프로세스를 작성 합니다 .

현재 한 번에 1 ~ 5 명의 사람들이 프로젝트를 진행하고 있습니다. Main은 필요할 때마다 옵션을 해제하기를 원하기 때문에 항상 안정적이어야합니다. 우리는 최소한 아직 스프린트를 고치지 않았으며 현재 1-2 주마다 릴리스됩니다.

이 시점에서 각 사람은 응용 프로그램에서 버그를 수정하고 있습니다. 몇 주 안에 앱의 새로운 대형 컴포넌트 개발을 시작할 것입니다.

우리가 찾고있는 한 가지 중요한 점은 개발 브랜치를 생성해야하는 시점 입니다 . 개발자의 기술 세트에 따라 여러 사용자 스토리를 병렬로 구현할 것입니다. 우리는 각 개발자를위한 브랜치를 만드는 것에 대해 생각했지만 작업에 대한 협업이 항상 필요하기 때문에 이해가되지 않습니다. 다른 작업이 완료되는 동안 Main과 병합하기를 원하므로 단일 개발 지점을 이용할 수 없습니다.

누구든지 이것에 대한 지침이 있습니까?


TFS를 사용하고 지점을 만들어 주신 여러분의 영혼을 축복하십시오. 우리 회사의 이전 단계에서 그들은 TFS를 사용하기로 결정했으며 결국 모든 개발자는 병합 프로세스가 너무 무서워 분기가 프로그래머 두려움 요소로 바뀌 었습니다.
Jordan

@ 요르단 : 완전히 근거없는 두려움이 아닙니다.
Robert Harvey

답변:


9

나는 Fred의 버그 수정이나 Harry의 버그 수정과 같은 임의의 분기를 좋아하지 않습니다. 여러 개발자가 하나의 기능으로 작업 할 수있는 하나의 (독립적 인) 기능 하나의 브랜치에 훨씬 익숙합니다. 기능이 완료 될 때만 병합됩니다.

따라서 지금은 "bugfix"브랜치 만 필요하지만 개발을 시작하면 모든 중요한 기능에 대한 브랜치를 작성해야합니다. 그렇게하면 다른 버그 기능에 의존하지 않고 병합 및 해제 할 수 있습니다.

TFS가 얼마나 잘 병합되고 있는지 잘 모르겠지만 몇 달 안에 알게 될 것입니다. :)


이것은 내가 일하는 곳에서 우리가하는 일에 매우 가깝습니다. 변경 사항이 트렁크로 변경 될 때마다 트렁크에서 각 작업 분기로 종교적으로 만 병합해야하는 경우에는 매우 잘 작동합니다. 또한 자동 빌드를 동시에 설정하십시오. 각 분기 (소스 제어에 저장 됨)가 항상 빌드 가능한 상태임을 알면 작업이 훨씬 쉬워집니다. Visual Studio 도구를 사용하여 병합하는 경우 병합의 양쪽에 변경 사항이있는 긴 줄이 생길 때까지 잘 작동합니다.
CVn

5

다른 작업이 완료되는 동안 Main과 병합하기를 원하므로 단일 개발 지점을 이용할 수 없습니다.

여러 개발 브랜치를 만들어야한다는 것을 이미 알고있는 것 같습니다 . 두 가지 가능한 시나리오가 떠 오릅니다.

  1. 5 명의 개발자 각각이 프로젝트의 독립적 인 부분 (버그 수정)을 작업하고 있습니다 .- 개발자마다 개별 브랜치 작성해야합니다. 변경 사항이 다른 사람의 작업과 충돌하지 않도록 각 개발자에게 책임과 책임이 부여됩니다. 다섯 명의 개발자 중 한 명이 실수 할 가능성이 높습니다. 그럴 경우 / 다른 경우에 다른 모든 사람을지지하는 것은 말이되지 않습니다.
  2. 여러 기능 개발 -특정 기능 / 버그를 작업하는 개발자 수에 관계없이 이들을 분리 해야 합니다. 이것이 유리한 예는 모든 코드 커밋이 개발중인 기능의 일부라는 점입니다.

1

DVCS를 통한 묵시적 작업 지점

우리는 Mercurial을 사용하므로 개발자 dev 상자에 묵시적 작업 분기가 있습니다. 커밋은 항상 로컬 작업 영역으로 수행됩니다. 릴리스 가능한 작업이 완료되면 기본 리포 서버로 푸시되어 자동으로 빌드되고 테스트됩니다.

우리는 명백한 지점을 거의 만들지 않지만 스프린트는 1 주일을 넘지 않으며 카드를 완성하는 데 1-2 일 이상 걸리지 않습니다.

또한 코드의 다른 부분이나 다른 프로젝트에서 작업을 스레딩하여 병합 문제를 완화하여 사람들이 항상 어려운 병합 작업을 수행 할 필요가 없습니다.


0

나는 스토리 당 단일 브랜치와 릴리스 당 하나의 브랜치를 모두 사용했습니다 (모든 개발자는 자신의 스토리를 dev로 체크인하고 그 중 하나가 dev 브랜치를 중단하면 모두 중단됩니다). 갈등이 마음에 들지 않으면 스토리 당 하나의 브랜치를 추천합니다. dev 브랜치는 모든 개발자에 대해 항상 안정적으로 유지되며 개발자가 다른 개발자가 이미 위반 한 코드를 작업 할 때까지 대기 시간이 없습니다. 이야기가 끝나면 모든 코드가 지점에 있습니다. 충돌이 발생하는 경우이를 해결하고 체크인하고 테스트하지 말고 개발자와 병합하여 해결하고 충돌하는 사람에게 코드를 제거하지 않도록 요청하십시오. 그런 다음 dev로 병합하십시오. 이를 통해 모든 개발자가 원활하게 작업 할 수 있습니다. 또한 회사의 규모에 따라 다릅니다. 우리 회사는 하나의 코드 기반에서 동시에 작업하는 200 명의 개발자를 보유하고 있습니다. 그러나 그들의 이야기에 대한 별도의 지점. 코드가 dev 분기에 병합되면 스토리 분기가 즉시 삭제됩니다. 이게 도움이 되길 바란다. 감사


0

이것이 git을 기반으로하는 경우 각 버그 수정에 대한 분기를 만들고 가능한 짧은 시간에 버그를 수정하고 버그 수정 분기를 개발 분기와 병합 한 다음 변경 사항을 개발 분기로 푸시하십시오. 풀 요청을 검토하고해야 병합 가장 빨리 당신이 그것을 통합하는 문제가 발생하지 않는다는 것을, 더 나은 기회를 수행 할 수 있기 때문에, 우선 순위입니다. 병합 된 지점은 삭제할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.