어떤 Git 분기 모델이 귀사에 적합합니까?

어떤 Git 분기 모델이 귀사에 적합합니까?

당사는 현재 간단한 트렁크/릴리스/핫픽스 분기 모델을 사용하고 있으며 귀사 또는 개발 프로세스에 가장 적합한 분기 모델이 무엇인지에 대한 조언을 구하고 있습니다.

1. 워크플로우 / 분기 모델

   다음은 제가 본 세 가지 주요 설명이지만, 부분적으로 서로 모순되거나 우리가 직면한 후속 문제를 정리하기에는 충분하지 않습니다(아래 설명 참조).따라서 우리 팀은 지금까지 그다지 좋은 솔루션을 제공하지 못하고 있습니다.당신은 더 나은 일을 하고 있습니까?

   • git 워크플로우(7) 수동 페이지
   • (nvie) 성공적인 Git 분기 모델
   • (reinh) 민첩한 팀을 위한 Git 워크플로우

2. 병합 대 기본 재배치(엉킨 대 순차 기록)

   라도?pull --rebase아니면 작업이 완료될 때까지 메인 라인으로 다시 병합하여 기다리시겠습니까?으로 저는 에 대한 인 그림을 보존하기 합니다.merge --no-ff이를 위하여하지만 그것은 다른 단점을 가지고 있습니다.또한 많은 사람들이 병합의 유용한 속성을 깨닫지 못했습니다. 즉, 교환적이지 않습니다(주제 분기를 마스터로 병합하는 것이 마스터를 주제 분기로 병합하는 것을 의미하지는 않습니다).

3. 자연스러운 워크플로우를 찾고 있습니다.

   때때로 우리의 절차가 간단한 규칙으로 특정 상황을 포착하지 못하기 때문에 실수가 발생합니다.예를 들어, 이전 릴리스에 필요한 수정은 물론 업스트림이 필요한 모든 분기로 통합될 수 있을 정도로 충분히 다운스트림 기반이어야 합니다(이러한 용어의 사용이 충분히 명확합니까?).그러나 개발자가 다운스트림에 더 많이 배치했어야 한다는 것을 깨닫기 전에 수정이 마스터에 도달하는 경우가 발생하며, 이미 (더 나쁜 경우, 병합 또는 이를 기반으로 하는 것) 수정이 진행되면 남은 옵션은 관련 위험과 함께 체리 픽킹이 됩니다.당신은 어떤 간단한 규칙을 사용합니까?여기에는 다른 주제 분기를 제외한 한 주제 분기의 어색함도 포함됩니다(공통 기준선에서 분기되었다고 가정). 개발자들은 방금 작성한 코드가 더 이상 존재하지 않는 것처럼 느껴 다른 기능을 시작하기 위해 기능을 끝내기를 원하지 않습니다.

4. 체리픽으로 인한 병합 충돌을 방지하는 방법은 무엇입니까?

   병합 충돌을 만드는 확실한 방법은 분기 간 체리 픽으로, 다시는 병합할 수 없는 것처럼 보이는가?두 지점 모두에서 동일한 커밋을 역방향으로 적용(이를 수행하는 방법)하면 이 문제가 해결될 수 있습니까?이것이 제가 감히 대부분의 병합 기반 워크플로우를 추진할 수 없는 한 가지 이유입니다.

5. 어떻게 하면 주제별 가지로 분해할 수 있습니까?

   토픽 분기에서 완성된 통합을 조립하는 것이 멋지다는 것을 알고 있지만, 종종 개발자들에 의한 작업이 명확하게 정의되지 않고(때로는 "둘러보기"만큼 단순하다) 일부 코드가 이미 "misc" 토픽에 들어갔다면 위의 질문에 따라 그곳에서 다시 꺼내지 못할 수도 있습니다.주제 분기를 정의/승인/졸업/해제하는 작업은 어떻게 진행됩니까?

6. 코드 검토 및 졸업과 같은 적절한 절차는 물론 사랑스러울 것입니다.

   하지만 우리는 이것을 관리할 수 있을 정도로 상황을 정리할 수 없습니다. 어떤 제안이 있습니까?통합 분기, 그림?

다음은 관련 질문 목록입니다.

• 배포된 애플리케이션을 핫픽스할 수 있도록 지원하는 좋은 전략은 무엇입니까?
• 사내 개발을 위한 Git 사용 워크플로우 설명
• 기업 리눅스 커널 개발을 위한 Git 워크플로우
• 개발 코드와 생산 코드는 어떻게 유지합니까?(이 PDF에 감사드립니다!)
• git 릴리스 관리
• Git Cherry-pick vs 병합 워크플로우
• 여러 커밋을 선택하는 방법
• 선택한 파일을 git-merge와 병합하려면 어떻게 해야 합니까?
• 커밋 범위를 선택하고 다른 분기로 병합하는 방법
• ReinH Git 워크플로우
• git 워크플로우를 통해 원점으로 다시 밀어넣지 않을 수정 작업을 수행합니다.
• 병합 선택
• OS와 개인 코드를 결합한 적절한 Git 워크플로우?
• Git로 프로젝트 유지보수
• Git가 수정된 상위/마스터와 파일 변경을 병합할 수 없는 이유는 무엇입니까?
• Git 분기/베이스 변경 모범 사례
• 언제쯤 "기트풀 --리베이스"가 저를 곤경에 빠뜨릴 수 있을까요?
• 대규모 팀에서 DVCS는 어떻게 사용됩니까?

또한 Plastic SCM이 작업 중심 개발에 대해 작성한 내용을 확인하고 Plastic을 선택하지 않을 경우 nvie의 분기 모델과 지원 스크립트를 학습합니다.

DVCS의 신규 개발자들이 인식해야 할 가장 문제가 되는 기능은 출판 프로세스에 관한 것은 다음과 같습니다.

• 필요한 원격 저장소를 가져올 수 있습니다.
• 원하는 모든 (추가) 저장소에 게시(게시)할 수 있습니다.

이를 통해 몇 가지 규칙을 준수하여 질문을 쉽게 할 수 있습니다.

• 분기가 푸시되지 않은 경우에만 리베이스(마지막 리베이스 이후 푸시되지 않음)
• 맨 레포에만 푸시(Git1.7 이후 필수)
• 리베이스와 병합에 대한 리누스의 조언을 따릅니다.

이제:

워크플로우/분기 모델:

각 워크플로우는 릴리스 관리 프로세스를 지원하기 위해 존재하며 각 프로젝트에 맞게 조정됩니다.
내가 당신이 언급한 워크플로우에 추가할 수 있는 것은 각 개발자가 기능 분기를 만들지 말고 "현재 개발자" 분기만 만들면 된다는 것입니다. 왜냐하면 개발자는 종종 자신의 분기가 정확히 무엇을 생산할지 모르기 때문입니다. 하나의 기능, 여러 개의 기능(결국 너무 복잡한 기능), 하나의 기능(릴리스 준비가 되지 않았기 때문에), 하나의 기능,또 다른 특징(원래의 것이 "모조"되었기 때문에), ...

"통합자"만이 "중앙" 레포에 공식 기능 분기를 설정해야 하며, 개발자는 이를 가져와 해당 기능에 맞는 작업 부분을 재배치/합병할 수 있습니다.

병합 대 재베이스화(뒤얽힘 대 순차 기록):

말씀하신 제 답변("사내 개발을 위한 git 사용을 위한 워크플로우 설명")이 마음에 듭니다.

자연스러운 워크플로우를 찾고 있습니다.

수정의 경우 각 수정 사항을 버그 추적의 티켓과 연결하는 데 도움이 될 수 있으며, 이는 개발자가 수정 사항을 수행해야 하는 지점(즉, "수정을 위한 전용 지점")을 기억하는 데 도움이 됩니다.
되지 않은 되는 하는 데 이 될 수 (특정 이 것을 환경에 해야 합니다.) 런다 여안 푸 되 중 그 저 분 터 보 든 모 없 이 솔 특 데 로 므는도하있수 으될정움호이루션에이기다니습를소장음 앙후크부검는증는의기로시는않밀되지은버서넣어어는정그수또▁(여▁then

체리픽으로 인한 병합 충돌을 방지하는 방법은 무엇입니까?

Jakub Narębski가 답변에서 언급한 바와 같이 체리 따기는 필요한 드문 상황에 대비해야 합니다.
체리 따기(즉, "희귀하지 않음")가 많이 포함된 설정인 경우 무언가 잘못되어 있습니다.

동일한 커밋을 적용하면 되돌릴 수 있습니까(어떻게 해야 합니까?)

git revert 그것을 처리해야 하지만, 그것은 이상적이지 않습니다.

어떻게 하면 주제별 가지로 분해할 수 있습니까?

개발자는 아직 모든 곳에서 분기가 추진되지 않는 한 커밋 기록을 다음과 같이 재구성해야 합니다(개발이 보다 확정적이고 안정적인 형태로 전환되는 것을 최종적으로 알게 되면).

• 필요한 경우 여러 분기(명확하게 식별된 기능별로 하나씩)
• 한 분기 내의 일관된 커밋 집합(트리밍 깃 체크인 참조)

코드 검토 및 졸업과 같은 적절한 절차?

통합 지점(전용 통합) repo를 통해 개발자는 다음과 같은 이점을 얻을 수 있습니다.

• 해당 원격 통합 분기 위에 자신의 개발 내용을 재배치합니다(vmdk --rebase).
• 국지적으로 해결하다
• 그 레포로 개발을 추진합니다.
• 혼란을 초래하지 않는 통합업체에 확인;)

제 생각에, 제가 틀릴 수도 있습니다. 깃에 대해 가장 오해를 받는 것 중 하나는 그것의 분산된 본성이라고 생각합니다.이것은 당신이 원할 경우 SVN 동작을 모방할 수 있지만 당신이 일할 수 있는 방식으로 전복을 말하는 것을 매우 다르게 만듭니다.문제는 거의 모든 워크플로우가 가능하다는 것입니다. 이는 훌륭하지만 오해를 불러일으킬 수도 있습니다.

만약 제가 커널 개발에 대한 이해가 있다면(저는 그것에 초점을 맞출 것입니다), 모든 사람들은 커널을 개발하기 위한 그들만의 git 저장소를 가지고 있습니다.Torvalds가 관리하는 Linux-2.6.git라는 하나의 저장소가 릴리스 저장소 역할을 합니다."release" 분기에 대한 기능 개발을 시작하려면 여기서 복제합니다.

다른 리포지토리는 일부 개발을 수행합니다.이 아이디어는 Linux-2.6에서 복제하여 "새로운" 기능이 작동할 때까지 원하는 만큼 분기하여 복제하는 것입니다.그런 다음 이것이 준비되면 신뢰할 수 있는 사용자로 간주되는 사용자가 이 분기를 리포지토리에서 해당 분기로 가져와서 메인스트림에 병합할 수 있습니다.리눅스 커널에서 이것은 리눅스-2.6.git에 도달할 때까지 여러 수준(신뢰할 수 있는 중위수)에서 발생하며, 그 시점에서 "커널"이 됩니다.

여기서 혼란스러운 부분이 있습니다.지점 이름은 리포지토리 간에 일관성을 유지할 필요가 전혀 없습니다.내가 할 수 있는.git pull origin master:vanilla-code그리고 그로부터 가지를 얻습니다.origin는 제 의마가내저분있습다라는 vanilla-code상황을 파악할 수 있다면 문제가 되지 않습니다. SVN과 같은 여러 컴퓨터 간에 공유되는 것이 아니라 모든 리포지토리가 서로 피어(peer)라는 의미로 배포됩니다.

이 모든 것을 염두에 두고:

1. 나는 그들이 어떻게 분기를 하는지는 각 프로그래머들에게 달려있다고 생각합니다.릴리스 등을 관리하기 위한 중앙 저장소만 있으면 됩니다.트렁크는 다음과 같습니다.head릴리스는 태그 또는 분기일 수 있으며 핫픽스는 그 자체로 분기일 수 있습니다.사실, 릴리스를 분기로 사용하여 패치를 계속 적용할 수 있습니다.
2. 저는 병합하고 재배치하지 않을 것입니다.예를 들어, 저장소를 복제하고 분기한 다음 일부 개발을 수행한 경우 다음에서 꺼냅니다.origin당신은 아마도 당신의 저장소에서 다른 분기를 만들고 최신 분기를 병합해야 합니다.master안으로yourbranch다른 사용자가 가능한 한 적은 노력으로 사용자의 변경사항을 처리할 수 있도록 합니다.제 경험상, 진정으로 기반을 바꿀 필요는 거의 없습니다.
3. 저는 Git이 작동하는 방식과 그것이 무엇을 할 수 있는지 이해하는 경우라고 생각합니다.시간과 많은 좋은 의사소통이 필요합니다. 저는 다른 개발자들과 GIT를 사용하기 시작했을 때 비로소 진정으로 무슨 일이 일어나고 있는지 이해하기 시작했고 지금도 잘 모르는 몇 가지 사항이 있습니다.
4. 병합 충돌은 유용합니다.알아요, 알아요, 당신은 모든 것이 작동하기를 원하지만, 사실은 코드 변경이고 당신은 그 결과를 작동하는 것으로 병합해야 합니다.병합 충돌은 사실 더 많은 프로그래밍일 뿐입니다.나는 그것들에 대해 무엇을 해야 하는지에 대한 쉬운 설명을 찾지 못했기 때문에, 여기에 있습니다: 병합 충돌이 있는 파일을 기록하고, 그것들을 원래 상태로 변경하십시오.git add .그리고 나서.git commit.
5. 잘 어울리는데요.이미 말했듯이, 각 사용자 git 저장소는 가지고 놀 수 있는 고유한 저장소이며 지점 이름이 같을 필요는 없습니다.예를 들어 스테이징 저장소가 있는 경우 이름 지정 스키마를 시행할 수 있지만 각 개발자에 대해서는 릴리스 repo에만 이름을 지정할 필요가 없습니다.
6. 병합 단계입니다.코드를 검토/품질 테스트를 통과할 때만 릴리스 분기 등에 병합됩니다.

그게 도움이 되길 바랍니다.VonC가 방금 아주 비슷한 설명을 올린 것을 알고 있습니다.타이핑이 너무 빠르지 않아요!

광고 환경에서 깃을 사용하는 방법에 대한 몇 가지 추가적인 생각을 편집하십시오. 코멘트에서 OP와 관련이 있는 것으로 보입니다.

• 릴리스 저장소, 우리는 그것을 부를 것입니다.product.git제품 자체를 실제로 관리하는 책임이 있는 다수의 선임 프로그래머/기술자가 액세스할 수 있습니다.OSS에서 유지관리자의 역할과 유사합니다.
• 이 프로그래머들은 부분적으로 새로운 버전의 개발을 주도할 수도 있기 때문에 스스로 코딩하고 다양한 저장소를 유지할 수도 있습니다.새로운 기능을 위한 스테이징 저장소를 관리할 수도 있고 자체 저장소를 보유할 수도 있습니다.
• 아래는 개별 비트 개발을 담당하는 프로그래머들입니다.예를 들어 UI 작업을 담당하는 사용자가 있을 수 있습니다.따라서 UI.git 저장소를 관리합니다.
• 그들 아래에는 기능을 일상 업무로 개발하는 실제 프로그래머들이 있습니다.

그래서 어떻게 될까요?모든 사용자는 매일 "업스트림" 소스, 즉 이전 날 개발에서 나온 최신 자료를 포함하는 릴리스 저장소에서 시작합니다.모든 사람들이 직접적으로 이렇게 합니다.이 작업은 저장소의 분기("마스터" 또는 "최신"이라고 불리는 경우)로 진행됩니다.그러면 프로그래머가 약간의 작업을 할 것입니다.이 일은 그들이 확신할 수 없는 것일 수도 있습니다. 그래서 그들은 나뭇가지를 만들고, 일을 합니다.작동하지 않으면 지점을 삭제하고 돌아갈 수 있습니다.만약 그렇게 된다면, 그들은 현재 작업 중인 주요 지점으로 있는 주요 지점으로 통합해야 합니다.이것은 UI 프로그래머가 작업하는 것입니다.latest-ui그래서 그는 합니다.git checkout latest-ui다음에git merge abc-ui-mywhizzynewfeature그런 다음 그는 기술적 리드(UI 리드)에게 이봐, 나는 그런 작업을 완료했어, 내게서 빼라고 말합니다.따라서 UI 리드는git pull user-repo lastest-ui:lastest-ui-suchafeature-abc그런 다음 UI 리드가 해당 분기에서 해당 분기를 보고 "매우 좋습니다."라고 말합니다.ui-latest그러면 그는 그의 아래에 있는 모든 사람들에게 그들의 차에서 그를 끌어내라고 말할 수 있습니다.ui-latest분기 또는 그들이 지정한 이름이 무엇이든 간에, 그래서 그 기능은 개발자들에 의해 탐구됩니다.팀이 만족할 경우 UI 리드가 테스트 리드를 제거하고 변경 사항을 병합하도록 요청할 수 있습니다.이를 테스트하고 버그 보고서 등을 제출하는 모든 사용자(변경 다운스트림)에게 전파됩니다.마지막으로 기능이 테스트 등을 통과하면 상위 기술 리드 중 하나가 해당 기능을 프로그램의 현재 작업 복사본에 병합할 수 있으며, 이때 모든 변경 사항이 다시 아래로 전파됩니다.등등.

이는 "전통적인" 작업 방식이 아니며 SVN/CVS와 같은 "계층적"이 아닌 "동료 중심"으로 설계되었습니다.기본적으로 모든 사용자는 로컬에서만 커밋 액세스 권한을 가집니다.이는 저장소에 대한 액세스 권한이며 계층을 사용할 수 있는 릴리스 저장소로 지정하는 리포지토리입니다.

제가 사용한 모델 중 좋은 결과는 다음과 같습니다.

"축복된" 레포는 기본적으로 클라이언트-서버 토폴로지와 주고 받습니다.

마스터 브랜치가 없기 때문에 어떤 개발자도 코드를 "메인라인"으로 밀어넣을 수 없습니다.

모든 개발은 주제 분기에서 발생합니다.책임자를 쉽게 탐지하기 위해 jn/newFeature 또는 jn/issue-1234와 같은 이름을 지정합니다.

또한 화이트보드에는 지점과 칸반/스크럼 카드 간에 거의 1대 1의 매핑이 있습니다.

분기를 해제하기 위해 축복받은 레포로 밀리고 칸반 카드를 검토 준비로 이동합니다.

그러면 심사에서 지점이 받아들여지면 해제 후보가 됩니다.

릴리스는 승인된 분기 집합이 함께 병합되고 버전 번호로 태그 지정될 때 발생합니다.

새 태그를 축복받은 레포에 밀어넣음으로써 새로운 기능을 위한 새로운 가능한 기반이 마련됩니다.

병합 충돌을 방지하기 위해 개발자는 릴리스되지 않은 분기를 최신 릴리스 태그로 업데이트(병합)하도록 요청받습니다.

개인적으로, 저는 마스터 브랜치에 릴리스 준비 코드만 보관하려고 합니다.

새로운 기능이나 버그 수정 작업을 수행할 때는 지점에서 수행합니다.저는 지점에서 유닛 테스트도 합니다.모든 것이 정상적으로 작동하는 경우에만 마스터로 병합/기본 재배치됩니다.

다음과 같은 일반적인 분기 명명 규칙도 사용하려고 합니다.

• 버그 수정/수정_루프
• bugfix/sql_bugfix
• 특징/새로 나온_기능
• 특징/특징_검색

언급URL : https://stackoverflow.com/questions/2621610/what-git-branching-models-work-for-you