이 자식 분기 모델 또는 워크 플로 에 대해 묻고 있습니다. 나는 정말로 이것을 좋아한다. 그것은 매우 직관적이고 생산적인 것 같습니다. 그러나 내가 요구하는 것은 아직 명확하지 않은이 접근법에 결함이나 부정적인 점이 있는지 여부입니다 (ClearCase가 오늘을 지배 한 다른 세계에서 온 것입니다).
(당신이 도움이 될 수있는 모든 질문에 대답 할 필요는 없습니다)
이 또는 유사한 git branching workflow를 사용합니까?
이것이 생산적인 접근 방법이라고 생각하십니까?
이 접근 방식에 결함이 있습니까? 잠재적 인 단점이 있습니까?
더 나은 접근 방법이 있다면 공유하거나 기사 또는 토론 링크를 제공 하시겠습니까?
답변:
대부분의 경우 이것은 지금까지 사용한 VCS와 함께 사용되는 일반적인 워크 플로입니다. 일부 (CVS, SVN)에서는 수행하기가 어렵고 GIT에서는 사소합니다. 즉, 나는 두 가지 언급이 있습니다.
첫째, 지점을 다루는 두 가지 사고 학교가 있습니다.
(1) 기사가 제안한 것입니다. 병합 커밋 문제는 이른바 Evil Merges 입니다. 특히, 함수가 브랜치 중 하나에서 의미가 변경된 개발 경로에 참여하지만 자동 병합은 다른 브랜치에서 오는 코드에서 모든 발생을 패치하지 못합니다. 그런 식으로 도입 된 회귀는 디버그하기가 어렵다. GIT 사용자는 일반적으로 git bisect원인을 자동으로 찾아야 하기 때문에 회귀에 대해 훨씬 더 편할 수 있습니다 . 그러나 설명 된 상황 git bisect에서 병합 커밋을 지적하면 전혀 도움이되지 않습니다.
(2) 가능한 한 이력을 선형으로 유지하여이 문제를 방지합니다. 반대하는 리베이스는 리베이스 이전에 수행 한 모든 테스트를 무효화한다고 주장합니다.
개인적으로 저는 캠프 (2)에 굳게 섰습니다. 왜냐하면 git bisect적절한 CI 시스템을 사용하여 쉽게 보상 할 수있는 테스트 범위의 손실 가능성보다 결과 의 유효성을 높이 평가하기 때문 입니다.
둘째, 개발자들 사이에서 추진하는 것이 좋은 생각이 아니라고 결정했습니다. 모든 사람이 당신의 상자에 들어가서 git-deamon을 가져 오거나 로컬로 실행할 수있게하는 것과 관련된 보안 문제가 있으며, 더 중요한 것은 매우 작은 팀에서는 감독이 오히려 빠르게 사라질 수 있습니다.
즉, 하위 팀이 기본 서버와는 다른 중앙 서버를 통해 진행중인 작업을 공유 할 수 있는 스테이징 저장소 (때로는 scratch ) 를 선호 합니다 공개되지 않은 경우 직면). 일반적으로 각 하위 팀은 자체적으로 하나의 토픽 브랜치를 유지하고 CI 시스템은 모든 토픽 브랜치를 주기적 으로 하나의 큰 통합 브랜치로 병합 하여 충돌 및 빌드 오류에 대해 불평합니다.
git bisect당시에도 전략을 유지해야하는 이유가있었습니다.
git bisect혼자 와 아무 관련이 없습니다 . 기능 A가 기능 B가 사용하는 기능을 변경할 때 발생합니다. 모든 테스트는 병합 전에 A와 B를 모두 통과하지만 A와 B 사이의 호환되지 않는 변경으로 인해 병합 테스트가 중단 될 수 있지만 git bisect한 분기를 다른 분기에 부분적으로 적용 할 수는 없으므로 병합 커밋이 유일한 단서입니다 버그가 소개 된 시점입니다.
현재 다른 팀 구성원이 계속해서 새로운 기능에 대해 작업하고 있기 때문에 대규모 리팩토링 (애플리케이션을 다른 GUI 툴킷으로 변환)하고 성공적인 리베이스 중심 워크 플로우를 수행하고 있습니다.
master새로운 기능이 개발되는 toolkit-conversion지점 과 지점에는 두 가지 주요 지점이 있습니다. 가장 중요한 규칙은 간단합니다. toolkit-conversion분기와 관련하여 변환과 관련된 작업 만 수행 하십시오. master(구 GUI 툴킷) 에서 할 수있는 일이있을 때마다 나는 그것을 toolkit-conversion하고 새로운 변경 사항을 다시 적용합니다 master. 또 다른 규칙은 toolkit-conversion지점을 매우 짧게 유지하는 것 입니다. 따라서 종종 재설정, cherry-pick 및 amend-commit 및 rebase를 사용하여 작은 커밋을 큰 커밋에 붙입니다 (결국 동일한 목적을 가짐). 이것은 변경 사항을 "실행 취소"하기 위해 잘 작동하지 않는 것을 시도했을 때 또는 임시 도우미 코드로 일부 코드를 리팩토링 한 후에도 잘 작동합니다.
변경 사항 master을 toolkit-conversion브랜치 로 병합하지 않기로 결정했습니다 . 브랜치를 깨끗하고 검토하기 쉽게 유지하기 위해 이전 커밋을 리베이스하는 것이 훨씬 어려워지기 때문입니다. 또한 병합은 정리 기록을 유지할 때와 같이 해결 방법이 명확하지 않은 충돌을 일으킬 수 있습니다.
물론이 워크 플로에는 단점도 있습니다. 가장 중요한 것은 한 사람에게만 잘 작동한다는 것입니다. toolkit-conversion지점을으로 변경 한 후 지점을 강제로 푸시하면 master다른 저장소 에서 지점을 가져 오는 것이 어려워집니다 (추적 지점에 자동으로 기반을 두는 것은 종종 충돌로 실패합니다).
결국 내 toolkit-conversion지점은 짧고 깨끗하며 검토하기 쉽습니다. 예를 들어 SVN에서 이와 비슷한 강력한 작업을 수행했다고 상상할 수 없었습니다.
이 또는 유사한 git branching workflow를 사용합니까?
우리는 직장에서 유사한 워크 플로를 사용하지만 조금 덜 복잡합니다. 그러나이 기사를 여러 번 읽었으므로이 워크 플로우에서 큰 영감을 받았습니다. 나는 심지어 책상 옆에 색상으로 인쇄 된 분기 모델의 PDF를 가지고 있습니다 :)
이것이 생산적인 접근 방법이라고 생각하십니까?
생산적인. 생산성을 어떻게 정의합니까? 글쎄, 적어도 항상 더 나은 품질을 시도하고 달성하기 위해 높은 품질을 유지하는 것이 가장 중요합니다. 프로세스 등을 지속적으로 개선합니다. 품질 코드를 생성 할 수 있으면 생산성이 향상됩니다. 문제는 실제로 : 소프트웨어의 품질을 향상 시키는가? 그리고 그것에 대한 나의 대답은 분명히 그렇습니다.
이 유형의 브랜칭 모델에서 내가 가장 좋아하는 것은 다른 품질 계층의 브랜치를 소개한다는 것입니다. 사진에서 오른쪽으로 갈수록 안정성과 품질이 향상됩니다. 마스터 브랜치는 거룩하며 모든 커밋은 소프트웨어의 안정적인 버전으로 간주되어야합니다. 왼쪽으로 갈수록 더 실험적이고 안정성이 떨어집니다.
새로운 기능과 버그 수정을 테스트하자마자 왼쪽에서 오른쪽으로 점진적으로 전송하여 코드가 요구하는 품질 요구 사항을 충족한다는 것을 정확히 알 때 정확하게 고품질로 코드를 이동할 수 있습니다. 글쎄, 적어도 이론적으로는 100 %까지 모든 것을 테스트 할 수는 없으며 항상 버그가 있기 때문에 코드에 버그가 없음을 알고 있습니다. 그러나 높은 신뢰를 유지할 수 있습니다.
코드에 대한 자신감이없는 시스템에서 작업하는 것보다 프로그래머에게는 더 많은 것이 없습니다.
이 접근 방식에 결함이 있습니까? 잠재적 인 단점이 있습니까?
조직의 요구에 잘 맞도록 분기 모델을 통해 생각하는 것이 중요합니다. 이 모델이 일부 사람들에게 잘 작동한다고해서 반드시 다른 사람에게 최적이거나 바람직한 것은 아닙니다.
이 경우에도 항상 트레이드 오프가 있습니다. 한 가지 단점은 분기 수와 복잡성입니다. 다양한 지점 유형을 도입하면 워크 플로의 복잡성이 증가합니다. 예를 들어 사람들이 몇 줄의 코드를 변경하여 간단한 버그를 수정하려고 할 때 항상 새로운 기능 분기를 작성하도록하는 것은 잘못 일 수 있습니다.
우리는 버그가 해결하기가 다소 복잡하다는 것을 알고 있습니다. 따라서 사소한 버그가 발견되면 복잡성과 관리를 줄여 추가 오버 헤드를 없애고 사람들이 직접 마스터 또는 지점 개발에 전념하도록 할 수 있습니다. 그러나 수정 사항의 본질이 더 복잡 해짐에 따라 새 분기를 작성하는 추가 오버 헤드가 필요합니다. 특히 크기와 길이가 확실하지 않거나 다른 개발자와의 협업을 향상시키려는 경우에 특히 그렇습니다.
더 나은 접근 방법이 있다면 공유하거나 기사 또는 토론 링크를 제공 하시겠습니까?
이것은 좋은 접근 방법 일 것입니다. 우리 대부분은 비슷한 개발 프로세스를 가지고 있기 때문에 대부분의 경우에 적합 할 수 있지만 모든 사람에게 적합하지 않을 수도 있습니다. 지금 코드를 처리하는 방법을 생각하고 이미 가지고있는 브랜칭 모델을 만들어 보길 강력히 권합니다.
가장 중요한 점은 git을 시작하는 것이고 나머지는 자연스럽게 따릅니다. 간단하게 시작하고 점차 개선하십시오! 창의력을 발휘하십시오!
건배