트렁크 기반 개발과 Git Flow

고품질 소프트웨어를 개발하려면 모든 변경 사항을 추적하고 필요한 경우 되돌릴 수 있어야 합니다. 버전 관리 시스템은 프로젝트 이력을 추적하고 여러 사람이 변경한 사항을 병합하도록 도와줌으로써 그 역할을 수행합니다. 작업 속도를 크게 높이고 버그를 더 쉽게 찾을 수 있는 기능을 제공합니다.

또한 이러한 도구 덕분에 분산된 팀에서 작업할 수 있습니다. 여러 사람이 동시에 프로젝트의 다른 부분에서 작업하고 나중에 그 결과를 단일 제품으로 결합할 수 있습니다. 버전 관리 시스템을 자세히 살펴보고 트렁크 기반 개발과 Git 흐름이 어떻게 생겨났는지 설명하겠습니다.

버전 관리 시스템이 세상을 바꾼 방법

버전 관리 시스템이 만들어지기 전에 사람들은 이전 버전의 프로젝트를 수동으로 백업하는 데 의존했습니다. 그들은 동일한 프로젝트에서 여러 개발자의 작업을 통합하기 위해 수정된 파일을 손으로 복사했습니다.

많은 시간, 하드 드라이브 공간 및 비용이 들었습니다.

역사를 살펴보면 3세대 버전 관리 소프트웨어를 크게 구분할 수 있습니다.

그것들을 살펴봅시다:

버전 제어 시스템이 성숙해짐에 따라 프로젝트에서 병렬로 작업하는 능력이 증가하는 경향이 있음을 알 수 있습니다.

가장 획기적인 변경 사항 중 하나는 파일 잠금에서 변경 사항 병합으로 전환한 것입니다. 프로그래머가 더 효율적으로 작업할 수 있게 해주었습니다.

또 다른 상당한 개선 사항은 분산 시스템의 도입이었습니다. Git은 이 철학을 통합한 최초의 도구 중 하나였습니다. 말 그대로 오픈 소스 세계가 번성할 수 있도록 했습니다. Git을 사용하면 개발자가 포크라는 작업으로 전체 저장소를 복사하고 병합 충돌에 대해 걱정할 필요 없이 원하는 변경 사항을 도입할 수 있습니다.

나중에 변경 사항을 원래 프로젝트에 병합하기 위해 끌어오기 요청을 시작할 수 있습니다. 초기 개발자가 다른 저장소의 변경 사항을 통합하는 데 관심이 없는 경우 자체적으로 별도의 프로젝트로 변경할 수 있습니다. 중앙 저장소의 개념이 없기 때문에 이 모든 것이 가능합니다.

개발 스타일

현재 가장 인기 있는 버전 관리 시스템은 단연 Git으로 2016년에는 시장 점유율이 약 70%에 달했습니다.

Git은 Linux의 부상과 오픈 소스 장면 전반에 걸쳐 대중화되었습니다. 현재 공공 프로젝트를 위한 가장 인기 있는 온라인 저장소인 GitHub도 보급에 상당한 기여를 했습니다. 관리하기 쉬운 끌어오기 요청을 Git에 도입한 덕분입니다.

간단히 말해서 풀 리퀘스트는 소프트웨어 개발자가 생성한 변경 사항을 메인 프로젝트와 결합하기 위해 생성한 요청입니다. 여기에는 이러한 변경 사항을 검토하는 프로세스가 포함됩니다. 검토자는 개선될 수 있다고 생각하거나 불필요하다고 생각되는 모든 부분에 주석을 삽입할 수 있습니다.

피드백을 받은 후 작성자는 이에 응답하여 토론을 만들거나 단순히 팔로우하고 그에 따라 코드를 변경할 수 있습니다.

Git은 단지 도구일 뿐입니다. 다양한 방법으로 사용할 수 있습니다. 현재 가장 많이 접할 수 있는 두 가지 개발 스타일은 Git 흐름과 트렁크 기반 개발입니다. 종종 사람들은 이러한 스타일 중 하나에 익숙하지만 다른 스타일은 무시할 수 있습니다.

둘 다 자세히 살펴보고 언제 어떻게 사용해야 하는지 알아보겠습니다.

힘내 흐름

Git 흐름 개발 모델에는 엄격한 액세스 권한이 있는 하나의 기본 개발 분기가 있습니다. 흔히 develop 분기라고 합니다.

개발자는 이 기본 분기에서 기능 분기를 만들고 작업합니다. 완료되면 pull 요청을 생성합니다. 끌어오기 요청에서 다른 개발자는 변경 사항에 대해 언급하고 종종 꽤 긴 토론을 할 수 있습니다.

변경 사항의 최종 버전에 동의하는 데 시간이 걸립니다. 일단 동의하면 풀 요청이 수락되고 메인 브랜치에 병합됩니다. 메인 브랜치가 출시될 만큼 충분히 성숙했다고 판단되면 최종 버전을 준비하기 위해 별도의 브랜치를 생성합니다. 이 분기의 응용 프로그램은 테스트되고 버그 수정은 최종 사용자에게 게시할 준비가 되는 순간까지 적용됩니다. 완료되면 최종 제품을 master 브랜치에 병합하고 릴리스 버전으로 태그를 지정합니다. 그동안 develop 브랜치에서 새로운 기능을 개발할 수 있습니다.

아래에서 일반 워크플로를 나타내는 Git 흐름 다이어그램을 볼 수 있습니다.

Git 흐름의 장점 중 하나는 엄격한 제어입니다. 승인된 개발자만이 변경 사항을 면밀히 검토한 후 승인할 수 있습니다. 코드 품질을 보장하고 버그를 조기에 제거하는 데 도움이 됩니다.

그러나 이것이 큰 단점이 될 수도 있음을 기억해야 합니다. 깔때기를 만들어 소프트웨어 개발 속도를 늦춥니다. 속도가 주요 관심사라면 심각한 문제일 수 있습니다. 별도로 개발된 기능은 메인 프로젝트와 결합하기 어려울 수 있는 오래 지속되는 분기를 생성할 수 있습니다.

또한 pull 요청은 새 코드에만 코드 검토를 집중합니다. 코드를 전체적으로 보고 개선하기 위해 노력하는 대신 새로 도입된 변경 사항만 확인합니다. 어떤 경우에는 더 빠르게 수행하기 위해 무언가를 구현하는 것이 항상 가능하기 때문에 조기 최적화로 이어질 수 있습니다.

게다가 풀 리퀘스트는 리드 개발자가 말 그대로 코드의 모든 라인을 관리하는 광범위한 마이크로 관리로 이어질 수 있습니다. 신뢰할 수 있는 경험 많은 개발자가 있으면 처리할 수 있지만 시간과 기술을 낭비할 수 있습니다. 또한 개발자의 의욕을 심하게 저하시킬 수 있습니다.

대규모 조직에서는 pull 요청 중 사무실 정책이 또 다른 문제입니다. pull 요청을 승인하는 사람들이 특정 개발자가 코드 베이스를 변경하지 못하도록 의도적으로 차단하기 위해 자신의 위치를 ​​사용할 수도 있습니다. 자신감 부족으로 인해 그렇게 할 수 있지만 일부는 개인 점수를 정산하기 위해 자신의 위치를 ​​남용할 수 있습니다.

Git Flow 찬반 양론

보시다시피 pull 요청을 수행하는 것이 항상 최선의 선택은 아닐 수도 있습니다. 적절한 경우에만 사용해야 합니다.

Git Flow는 언제 가장 잘 작동합니까?

• 오픈 소스 프로젝트를 실행할 때.
  이 스타일은 오픈 소스 세계에서 유래했으며 그곳에서 가장 잘 작동합니다. 모든 사람이 기여할 수 있으므로 모든 변경 사항에 대해 매우 엄격한 액세스 권한을 갖기를 원합니다. 솔직히 말해서 기여하는 사람들을 신뢰할 수 없기 때문에 코드의 모든 라인을 확인할 수 있기를 원합니다. 일반적으로 상업용 프로젝트가 아니므로 개발 속도는 문제가 되지 않습니다.

• 주니어 개발자가 많을 때.
  주로 주니어 개발자와 작업하는 경우 작업을 자세히 확인할 수 있는 방법이 필요합니다. 일을 더 효율적으로 수행하고 기술을 더 빨리 향상시키는 방법에 대한 여러 가지 힌트를 줄 수 있습니다. pull 요청을 수락하는 사람들은 반복되는 변경 사항을 엄격하게 제어하여 코드 품질 저하를 방지할 수 있습니다.

  

• 확립된 제품이 있을 때.
  이 스타일은 이미 성공적인 제품을 가지고 있을 때도 잘 작동하는 것 같습니다. 이러한 경우 일반적으로 애플리케이션 성능 및 로드 기능에 중점을 둡니다. 이러한 종류의 최적화에는 매우 정밀한 변경이 필요합니다. 일반적으로 시간은 제약이 없으므로 이 스타일이 여기에서 잘 작동합니다. 게다가 대기업은 이 스타일에 아주 적합합니다. 수백만 달러의 투자를 중단하고 싶지 않기 때문에 모든 변경 사항을 면밀히 제어해야 합니다.

Git Flow는 언제 문제를 일으킬 수 있습니까?

• 당신이 막 시작했을 때.
  이제 막 시작했다면 Git 흐름이 적합하지 않습니다. 최소한의 실행 가능한 제품을 빠르게 만들고 싶을 수 있습니다. pull 요청을 수행하면 전체 팀을 극적으로 느리게 하는 거대한 병목 현상이 발생합니다. 당신은 단순히 그것을 감당할 수 없습니다. Git 흐름의 문제는 pull 요청에 많은 시간이 걸릴 수 있다는 사실입니다. 그런 식으로 빠른 개발을 제공하는 것은 불가능합니다.

• 빠르게 반복해야 할 때.
  제품의 첫 번째 버전에 도달하면 고객의 요구 사항을 충족하기 위해 제품을 몇 번 피벗해야 할 가능성이 큽니다. 다시 말하지만, 다중 분기 및 pull 요청은 개발 속도를 극적으로 감소시키며 이러한 경우에는 권장되지 않습니다.

• 주로 시니어 개발자와 작업할 때.
  팀이 주로 더 오랜 기간 동안 서로 작업한 시니어 개발자로 구성되어 있다면 앞서 언급한 풀 리퀘스트 미세 관리가 필요하지 않습니다. 당신은 당신의 개발자를 신뢰하고 그들이 전문가라는 것을 알고 있습니다. 그들이 일을 하도록 하고 모든 Git 흐름 관료주의로 속도를 늦추지 마십시오.

트렁크 기반 개발 워크플로

트렁크 기반 개발 모델에서 모든 개발자는 단일 분기에 대한 개방형 액세스 권한으로 작업합니다. 종종 단순히 master 브랜치입니다. 그들은 그것에 코드를 커밋하고 실행합니다. 아주 간단합니다.

어떤 경우에는 수명이 짧은 기능 분기를 생성합니다. 분기의 코드가 컴파일되고 모든 테스트를 통과하면 곧바로 master 에 병합됩니다. 이는 개발이 진정으로 연속적인지 확인하고 개발자가 해결하기 어려운 병합 충돌을 생성하는 것을 방지합니다.

트렁크 기반 개발 워크플로를 살펴보겠습니다.

이러한 접근 방식으로 코드를 검토하는 유일한 방법은 전체 소스 코드 검토를 수행하는 것입니다. 일반적으로 긴 토론은 제한적입니다. 소스 코드 기반에서 수정되는 내용을 엄격하게 제어할 수 있는 사람은 아무도 없습니다. 따라서 시행 가능한 코드 스타일을 마련하는 것이 중요합니다. 이러한 스타일로 작업하는 개발자는 경험이 있어야 소스 코드 품질이 저하되지 않는다는 것을 알 수 있습니다.

이러한 스타일의 작업은 노련한 소프트웨어 개발자 팀과 함께 작업할 때 유용할 수 있습니다. 이를 통해 불필요한 관료주의 없이 신속하게 새로운 개선 사항을 도입할 수 있습니다. 또한 master 브랜치에 직접 코드를 도입할 수 있으므로 신뢰할 수 있음을 보여줍니다. 이 워크플로의 개발자는 매우 자율적입니다. 직접 제공하고 작업 제품의 최종 결과를 확인합니다. 이 방법에는 사무실 정치에 대한 미시 관리 및 가능성이 훨씬 적습니다.

반면에 노련한 팀이 없거나 어떤 이유로 팀을 신뢰할 수 없다면 이 방법을 사용해서는 안 됩니다. 대신 Git 흐름을 선택해야 합니다. 불필요한 걱정을 덜어드립니다.

트렁크 기반 개발의 장단점

비용의 양면, 즉 최상의 시나리오와 최악의 시나리오를 자세히 살펴보겠습니다.

트렁크 기반 개발은 언제 가장 잘 작동합니까?

• 당신이 막 시작했을 때.
  최소한의 실행 가능한 제품으로 작업하는 경우 이 스타일이 적합합니다. 최소한의 형식으로 최대 개발 속도를 제공합니다. 풀 리퀘스트가 없기 때문에 개발자는 빛의 속도로 새로운 기능을 제공할 수 있습니다. 경험 많은 프로그래머를 고용하십시오.

• 빠르게 반복해야 할 때.
  제품의 첫 번째 버전에 도달하고 고객이 다른 것을 원한다는 것을 알게 되면 두 번 생각하지 말고 이 스타일을 사용하여 새로운 방향으로 전환하십시오. 당신은 아직 탐색 단계에 있으며 가능한 한 빨리 제품을 변경할 수 있어야 합니다.

• 주로 시니어 개발자와 작업할 때.
  팀이 주로 시니어 개발자로 구성되어 있다면 그들을 신뢰하고 그들이 일을 하도록 해야 합니다. 이 워크플로는 그들에게 필요한 자율성을 부여하고 직업에 대한 숙달을 휘두를 수 있도록 합니다. 그들에게 목적(달성해야 할 작업)을 부여하고 제품이 어떻게 성장하는지 지켜보십시오.

트렁크 기반 개발은 언제 문제를 일으킬 수 있습니까?

• 오픈 소스 프로젝트를 실행할 때.
  오픈 소스 프로젝트를 실행하는 경우 Git 흐름이 더 나은 옵션입니다. 변경 사항에 대한 매우 엄격한 제어가 필요하며 기여자를 신뢰할 수 없습니다. 결국 누구나 기여할 수 있습니다. 온라인 트롤 포함.

• 주니어 개발자가 많을 때.
  주로 주니어 개발자를 고용한다면 그들이 하는 일을 엄격하게 통제하는 것이 좋습니다. 엄격한 pull 요청은 기술을 향상하는 데 도움이 되고 잠재적인 버그를 더 빨리 찾을 수 있습니다.

• 제품을 구축하거나 대규모 팀을 관리할 때.
  이미 번창하는 제품을 보유하고 있거나 거대한 기업에서 대규모 팀을 관리하고 있다면 Git 흐름이 더 나은 아이디어일 수 있습니다. 수백만 달러의 가치가 있는 잘 정립된 제품에 대해 어떤 일이 일어나는지 엄격하게 통제하기를 원합니다. 아마도 애플리케이션의 성능과 로드 기능이 가장 중요할 것입니다. 이러한 종류의 최적화에는 매우 정밀한 변경이 필요합니다.

올바른 작업에 적합한 도구 사용

앞서 말했듯이 Git은 도구일 뿐입니다. 다른 모든 도구와 마찬가지로 적절하게 사용해야 합니다.

Git 흐름은 pull 요청을 통해 모든 변경 사항을 관리합니다. 모든 변경 사항에 대한 엄격한 액세스 제어를 제공합니다. 오픈 소스 프로젝트, 대기업, 기존 제품을 보유한 회사 또는 경험이 부족한 주니어 개발자 팀에 적합합니다. 소스코드에 도입되는 내용을 안전하게 확인할 수 있습니다. 다른 한편으로, 그것은 광범위한 미세 관리, 사무실 정치와 관련된 분쟁 및 상당히 느린 개발로 이어질 수 있습니다.

트렁크 기반 개발은 프로그래머에게 완전한 자율성을 부여하고 프로그래머와 그들의 판단에 대한 더 많은 믿음을 표현합니다. 소스 코드에 대한 액세스는 무료이므로 팀을 신뢰할 수 있어야 합니다. 우수한 소프트웨어 개발 속도를 제공하고 프로세스를 줄입니다. 이러한 요소는 신제품을 만들거나 기존 애플리케이션을 완전히 새로운 방향으로 전환할 때 완벽합니다. 경험 많은 개발자와 주로 작업하는 경우 작동합니다.

그래도 주니어 프로그래머나 완전히 신뢰하지 않는 사람들과 함께 작업하는 경우 Git 흐름이 훨씬 더 나은 대안입니다.

이 지식을 바탕으로 프로젝트와 완벽하게 일치하는 워크플로를 선택할 수 있기를 바랍니다.