솔로 개발자로 분기를 사용하면 어떤 이점이 있습니까?

우선, 솔로 개발자로서 VCS에 대해 많은 질문을 받았지만 종종 너무 광범위하다는 것을 알고 있습니다. 이것은 분기에만 관련이 있으며 여전히 중복으로 표시되었습니다 ... 중복은 너무 광범위하고 구체적으로 분기와 관련이없는 다른 질문의 또 다른 복제로 표시됩니다. 그게 내 질문의 독창적 인 방법입니다.

솔로 개발자로 분기를 사용하면 어떤 이점이 있습니까? 나는 종종 솔로 개발자의 상황에서도 권장되는 것을 보았지만 개발을 위해 '마스터'트렁크를 사용하고 작동 가능한 릴리스 준비 코드로 분기하는 것 외에도 볼 수있는 한 어떻게 전체 개발 프로세스를 복잡하게하지 않고도 분기 기능 (예 : 새로운 기능을 구획화)을 활용할 수 있습니다.

장점은 대부분 개발자 그룹과 동일합니다. 항상 릴리스 가능한 마스터 분기 및 새 기능 개발을위한 기능 분기를 사용하면 항상 마스터를 해제 할 수 있습니다. 기능 작업 중에 중요한 버그를 찾으십니까? 분기 전환, 수정, 릴리스, 전환 및 계속 개발.

아니면 이것은 취미 프로젝트 일 수도 있고 분위기가 당신을 때리면이 기능과 그에 대해 약간의 작업을하는 것을 좋아합니다. 기본적으로 시간 분할을 통해 여러 사람으로 구성된 팀을 모방하고 있습니다.

DVCS가 복제본에서 수행하는 암시 적 분기는 권한 저장소의 공식적인 분기는 사람을 조정하는 것이 아니라 개발 방향을 조정하는 것에 관한 것이 아니라 단일 사람조차도 여러 개를 수행 할 수 있음을 의미합니다.

장기 개발

단일 사용자 팀을위한 브랜치는 릴리스주기에 맞지 않는 장기 실행 개발 기능에 유용합니다.

여러 달에 걸친 스패닝 변경에 대한 브랜치를 가져와도 정기적으로 메인 브랜치에서 매일 버그 수정 또는 변경 사항을 푸시 할 수 있습니다.

이는 메인 브랜치가 항상 배포 가능한 상태에 있기 때문에 단일 브랜치에서 '스위치'에 비해 이점이 있으며 장기 실행 기능의 어떤 것도 이전에 테스트 한 다른 코드에 영향을 미치지 않습니다.

실험적인 특징

브랜치는 프로토 타입을 만들고 싶지만 배포 된 코드로 만들 수없는 기능에도 유용 할 수 있습니다. 내가 궁극적으로 버려지는 지점에서 이것을 완성하면 불필요하게 주요 코드베이스를 오염시키지 않습니다.

중요한 웹 사이트 유지 관리에 사용합니다. 저는 유일한 개발자이지만 지점을 개발하고 개발하는 마스터가 있습니다.

사이트 설정 작업 과정은 다음과 같습니다.

1. 실행 가능한 마스터 브랜치를 만드십시오. 초기 커밋을 수행하십시오.

2. Checkout은 지점을 개발합니다. 아무 것도하지 말고, 마스터로 병합하기위한 테스트 버퍼로 기능을 개발하십시오.

3. 결제 문제 지점. 문제가 발생하면 코드를 작성하고, 개발에 참여하고, 문제가 발생하는지 확인하고, 충돌을 병합하는 등의 문제를 해결하십시오.

릴리스를 위해 충분한 문제가 개발에 병합되고 개발이 안정성을 테스트 한 경우 개발을 마스터로 가져옵니다.

   Master
     |
   Develop  - E
   / |  \  \
 A   B   C  D

그렇게하면 Master에 해를 끼칠 위험없이 커밋을 롤백 할 필요없이 안정성, 문제 등을 테스트 할 수있는 전체 테스트 모음을 개발할 수 있습니다.

또한 커밋을 위해 개별 브랜치를 사용하면 이미 수행 한 작업을 "나가고"더 긴급한 문제를 해결하기 위해 다른 작업을 시작하여 더 빨리 시작할 수 있습니다.

실생활에서 나는 보통 하나의 이슈 브랜치를 가지고 있으며, 그 하나를 개발 단계에서 끌어 낸 다음 마스터로 끌어들입니다. 때때로 지루하지만, 적어도 2 개월에 한 번 누군가 RightNow ™를 만들어야한다는 생각이 들었고, 이렇게하면 신속하게 기본 상태로 다시 전환 할 수 있다는 생각이 들기 때문에 모자를 떨어 뜨려 놓아야합니다. 그리고 나서 내가 있던 곳을 계속합니다. 특히 몇 주가 걸리는 대규모 프로젝트의 경우 지점을 빠르게 전환 할 수있는 신의 선물입니다.

이 시나리오를 고려하십시오. 항상 메인 브랜치에서 작업하고 마스터 브랜치를 열린 심장 수술로 남겨두고 긴급 수정이 필요한 YugeBug ™ 팝업이있는 작업에 AwesomeCodeThing ™이 있으며 그렇지 않으면 수천 명의 사용자가 BigProblems ™에 대해 불만을 표시합니다
. 이러한 시나리오에서 문제를 신속하게 해결하는 유일한 방법

1. 이전 커밋을 확인하고
2. 마지막 안정적인 커밋이 언제되었는지 확인
3. 그 커밋으로 롤백
4. 수정하다, 수정하다
5. 이제 AwesomeCodeThing ™ 상태로 돌아 가려고하는 모든 충돌 및 문제 해결
6. 포기하고 울고 일을 시작하십시오. (선택 사항)

분기를 사용하는 경우 :

1. 결제 마스터
2. 지점 UrgentFix ™ 생성 및 수정
3. UrgentFix ™를 마스터로 당기십시오
4. 생산을 추진하다
5. 마스터를 개발에 병합
6. AwesomeCodeThing ™으로 개발 병합
7. 맥주를 마시고 계속 일하십시오.

지점을 사용하면 한 번에 여러 기능을보다 쉽게 ​​작업 할 수 있으므로 프로젝트 진행 중에 우선 순위가 변경 될 때 매우 유용합니다.

이제 기능이 더 중요하다고 결정했다고 가정 해보십시오. 라이브 시스템에서 치명적인 버그를 패치해야 할 수도 있습니다. 오랜 기간 동안 여러 기능에 대해 클라이언트와 작업 할 수 있으며 각 기능의 진행 상황을 개별적으로 시연 할 수 있습니다. 어쩌면 당신은 불쾌한 제로 데이 익스플로잇에 대해 읽었고 클라이언트가 그것에 대해 읽기 전에 그것에 착수하기를 원할 것입니다.

각 기능 / 핫픽스에 대해 브랜치를 사용하는 경우 모든 것에 단일 브랜치를 사용하는 것보다 이러한 수정 사항을보다 쉽고 깨끗하고 신속하게 격리 및 배포 할 수 있습니다. 이것은 당신이 유일한 개발자이거나 팀의 일원 이건 사실입니다.

실제 프로세스는 git flow가 잘 작동한다는 것을 알았습니다. Daniel Kummer의 git flow 치트 시트 는 훌륭한 리소스이므로 git을 사용하지 않더라도 살펴볼 가치가 있습니다.

다른 포스터에서 언급했듯이, 장점은 팀에서 일하는 것과 실질적으로 유사합니다. 기능을 독립적으로 개발 및 테스트하고 핫픽스 / 생산 배포를위한 별도의 마스터 브랜치를 유지하는 기능 실험.

개인적으로, 나는 내가 잘 작업하고있는 영역을 잘 알고 있다면 일반적으로 마스터에서 일하는 경향이 있습니다. 어쨌든 병합하기 때문에 지점에 오버 헤드를 추가합니다.

그러나 변경 사항에 대한 망설임 이 있으면 지점이 예상대로 동작하고 일반적으로 완전히 테스트되면 지점을 만들고 PR / 병합 만합니다. 그런 식으로 롤백이 최상의 조치 과정 인 문제를 발견하면 전체 시리즈 대신 단일 커밋입니다 (일련의 커밋을 롤백하는 구문을 기억할 수는 없지만 단일 커밋은 쉽습니다).