2.6 버전 관리와 소스 관리

개요와 동기

버전 관리를 코드베이스의 기록 시스템으로 생각하십시오. 누가, 언제, 왜 했는지를 포함해 모든 변경을 포착하고, 많은 사람이 서로를 덮어쓰지 않고 같은 소프트웨어에서 일할 수 있게 합니다. 큰 조직에서는 백업 이상입니다. 협업, 지속적 통합(CI), 감사, 릴리스 관리가 모두 의존하는 토대입니다. 브랜칭, 저장소 구조, 커밋 규율에 대한 선택이 팀이 얼마나 빠르게, 얼마나 안전하게 움직일 수 있는지를 형성합니다.

큰 팀에서 소스 관리는 사실상 규모에서의 조율 문제입니다. 수백 명의 엔지니어가 공유 코드에 변경을 밀어 넣을 때, 병합을 작게 유지하고, 메인라인을 릴리스 가능하게 하고, 이력을 읽을 수 있게 하는 전략이 필요합니다. 지속적으로 통합하는 팀은 매끄럽게 흐릅니다. 브랜치가 몇 주씩 갈라지도록 두는 팀은 한 통합 위기에서 다음 위기로 휘청거립니다. 저장소 구조, 하나의 큰 저장소 대 여러 개도 팀이 코드를 공유하고 조율하는 방식을 형성합니다.

기업과 정부 환경은 추적성, 접근 통제, 보존이라는 요구를 몇 가지 더합니다. 변경은 감사를 위해 승인된 작업 항목에 연결되어야 할 수 있습니다. 비밀은 절대 이력에 들어가서는 안 됩니다. 저장소 접근은 보안 경계를 존중해야 합니다. 여기서 버전 관리 관행은 조직의 통제 프레임워크의 일부가 되며, 유출된 비밀이나 감사 불가능한 이력 같은 실수는 심각한 결과를 낳을 수 있습니다.

핵심 원칙

작은 변경을 자주 통합하십시오. 긴 분기는 병합 고통의 뿌리입니다.
메인라인을 항상 릴리스 가능하게 유지하십시오.
이력은 문서입니다. 이유를 이해해야 하는 미래의 독자를 위해 커밋을 쓰십시오.
비밀을 절대 커밋하지 마십시오. 이력에 닿은 비밀은 침해된 것으로 다루십시오.
위생의 시행을 규율에만 의존하지 말고 자동화하십시오(훅, CI 검사).
유행이 아니라 팀이 실제로 코드를 공유하고 조율하는 방식으로 저장소 구조(모노 대 폴리)를 고르십시오.
추적성을 위해 변경을 그 근거(작업 항목, 티켓, 결정)에 연결하십시오.

권장 사항

수명이 짧은 브랜치를 쓰는 트렁크 기반 개발을 선호한다

트렁크 기반 개발 쪽으로 기우십시오. 몇 주가 아니라 몇 시간이나 며칠로 측정되는 수명이 짧은 기능 브랜치를 써서 공유 메인라인에 자주 통합하는 것입니다. 짧은 브랜치는 병합을 작게, 통합을 지속적으로 유지하며, 이 습관은 높은 전달 성능과 강하게 연관됩니다. 작업이 아직 끝나지 않았으면 수명이 긴 브랜치에 주차시키지 마십시오. 대신 미완성 작업을 숨기는 런타임 스위치인 기능 플래그를 써서 안전하게 병합하십시오. 수명이 긴 릴리스 브랜치는 진정한 다중 버전 지원에 남겨 두고, 그것이 지닌 유지보수 비용을 알고 들어가십시오.

릴리스 주기에 맞는 브랜칭 모델을 고른다

브랜칭 모델을 실제로 릴리스하는 방식에 맞추십시오. 지속적으로 배포한다면 최소한의 브랜칭을 쓰는 트렁크 기반 개발이 잘 맞습니다. 고객에게 버전이 매겨진 릴리스를 내놓거나 여러 살아 있는 버전을 한꺼번에 지원한다면 릴리스 브랜치와 백포팅이 필요할 수 있습니다. 릴리스 모델이 정말 요구하지 않는 한, 수명이 긴 브랜치가 많은 무거운 모델은 병합과 유지보수 오버헤드를 곱하므로 피하십시오.

모노레포 대 폴리레포를 의도적으로 결정한다

팀이 코드를 많이 공유하고, 프로젝트를 가로지르는 원자적 변경이 필요하고, 통합된 도구와 가시성을 원할 때는 많은 프로젝트를 담은 단일 저장소인 모노레포를 쓰십시오. 대신 확장된 빌드 도구와 접근 통제의 필요를 받아들입니다. 팀과 서비스가 진정으로 독립적이고, 격리된 접근과 릴리스 주기를 원하고, 저장소를 가로지르는 원자적 변경이 필요 없을 때는 프로젝트나 서비스별로 별도 저장소인 폴리레포를 쓰십시오. 대신 저장소에 걸친 변경을 조율하는 비용을 받아들입니다. 둘 다 규모에서 동작합니다. 끊임없는 마찰을 만드는 것은 결합 패턴에 맞지 않는 선택입니다.

커밋 위생과 컨벤셔널 커밋을 시행한다

커밋 메시지가 무엇만이 아니라 변경이 왜 이루어졌는지를 설명하도록 요구하십시오. 메시지가 구조화되고 기계가 파싱할 수 있도록 컨벤셔널 커밋 같은 관례를 채택하면 변경 로그와 버전 관리를 자동화할 수 있습니다. 이력이 이분 탐색 가능하고 되돌리기 쉽도록 커밋을 원자적으로, 각각 하나의 논리적 변경으로 유지하십시오. 기억에 의존하는 대신 훅과 CI 검사가 메시지 형식과 기본 위생을 시행하게 하십시오.

큰 바이너리와 생성된 코드를 일반 이력 밖에 둔다

큰 바이너리 자산을 메인 이력에 곧바로 커밋하지 마십시오. 모든 클론을 영원히 부풀립니다. 대신 대용량 파일 저장 메커니즘이나 산출물 저장소를 쓰십시오. 원칙적으로 생성된 코드도 커밋하지 마십시오. 빌드에서 생성하십시오. 생성된 산출물을 정말 커밋해야 한다면, 리뷰와 차이를 오염시키지 않도록 격리하고 분명히 표시하십시오.

비밀이 저장소에 들어가지 못하게 막는다

프리 커밋 훅과 CI에 자동 비밀 스캔을 넣어 자격 증명이 착지하기 전에 차단하십시오. 엔지니어에게 제대로 된 비밀 관리 시스템을 주어 애초에 자격 증명을 하드코딩할 필요가 없게 하십시오. 그리고 이력에 닿은 비밀은 침해된 것으로 다루어 즉시 교체하십시오. 비밀이 푸시되고 클론되고 나면 이력에서 제거하기는 어렵고 신뢰할 수 없습니다.

접근 통제와 추적성을 확립한다

저장소 접근이 보안 경계와 최소 권한을 존중하도록 설정하십시오. 커밋이나 풀 리퀘스트를 작업 항목에 연결해, 모든 변경이 그 근거까지 추적되게 하면 일상의 엔지니어링 맥락과 감사 모두에 도움이 됩니다. 핵심 브랜치를 필수 검사와 리뷰로 보호해, 합의한 관문을 통과하지 않고는 아무것도 병합되지 않게 하십시오.

장단점

선택	장점	단점
트렁크 기반 개발	지속적 통합. 작은 병합. 높은 흐름	기능 플래그와 규율이 필요. 격리가 적음
수명이 긴 기능 브랜치	진행 중인 작업의 강한 격리	고통스러운 병합. 통합 지연. 표류
모노레포	프로젝트를 가로지르는 원자적 변경. 공유 도구. 가시성	확장된 빌드 도구가 필요. 기본적으로 거친 접근 통제
폴리레포	독립 릴리스. 격리된 접근. 저장소별 단순한 도구	저장소를 가로지르는 변경이 어려움. 버전 조율 오버헤드
컨벤셔널 커밋	자동 변경 로그와 버전 관리. 일관된 이력	선행 관례. 시행이 필요

큰 트레이드오프는 통합 빈도 대 격리입니다. 수명이 긴 브랜치는 작업이 따로 놓여 있어서 더 안전하게 느껴지지만, 바로 그 격리가 나중에 비싼 병합과 통합의 놀라움을 일으킵니다. 트렁크 기반 개발은 그 격리의 느낌을 지속적이고 싼 통합과 맞바꾸며, 기능 플래그와 규율을 가져오라고 요구합니다. 모노레포/폴리레포 결정은 프로젝트 간 편의성과 팀 독립성을 맞바꿉니다. 코드가 실제로 얼마나 긴밀히 결합되어 있는지에 맞는 쪽을 고르십시오.

팀과 논의할 질문

보호된 메인라인에 병합되기 전에 어떤 검사가 통과해야 하며, 그 메인라인은 정말 항상 릴리스 가능합니까? 이 장은 릴리스 가능한 메인라인을 핵심 원칙으로 다루고, 깨졌거나 리뷰되지 않은 코드가 모두가 의존하는 브랜치에 닿는 보호되지 않은 메인라인을 안티패턴이라 부릅니다. 큰 팀에서 빨간 메인라인은 모두를 한꺼번에 막으므로, 요구하는 관문은 개인적이 아니라 공유된 안전 속성입니다. 증거를 가져오십시오. 브랜치 보호가 오늘 실제로 무엇을 시행하는지, 메인라인이 현재 얼마나 자주 깨져 있는지입니다. 필요한 집합, 즉 통과하는 테스트, 보안 스캔, 리뷰를 정하고 메인라인을 희망이 아니라 정책으로 릴리스 가능하게 만드십시오. 그 관문이 많은 사람이 두려움 없이 지속적으로 통합할 수 있게 합니다.
자동화하는 것을 감안할 때, 컨벤셔널 커밋을 채택하는 것이 팀에 관례 오버헤드를 감수할 가치가 있습니까? 이 장은 구조화되고 기계가 파싱할 수 있는 커밋 메시지를 바로 변경 로그와 버전 관리를 자동화할 수 있기 때문에 권하고, 이력이 이분 탐색과 되돌리기가 가능하도록 원자적 커밋을 요구합니다. 트레이드오프는 실제입니다. 생성된 릴리스 노트와 믿을 만한 이력을 얻는 대신 선행 관례를 치르고 시행이 필요합니다. 오늘 손으로 하는 일, 예컨대 변경 로그를 손으로 쓰거나 어느 커밋이 회귀를 도입했는지 찾아 헤매는 일의 신호를 가져오십시오. 릴리스를 자주 하거나 여러 버전을 유지한다면 자동화는 대개 본전을 뽑고, 릴리스를 거의 내지 않는다면 더 가벼운 관례로 충분할 수 있습니다. 형식이 기억에 의존하지 않도록 훅과 CI가 시행하게 하십시오.
모노레포 도구든 저장소 간 조율이든, 저장소 구조가 요구하는 운영 비용을 받아들였습니까? 이 장은 모노레포와 폴리레포가 규모에서 모두 동작하며, 끊임없는 마찰을 만드는 것은 결합 패턴에 맞지 않는 선택이라고 말합니다. 모노레포는 확장된 빌드 도구와 더 세밀한 접근 통제를 필요로 하고, 폴리레포는 저장소에 걸친 변경을 버전 불일치 위험이 있는 조율 프로젝트로 만듭니다. 구체적 신호를 가져오십시오. 변경이 프로젝트 경계를 얼마나 자주 가로지르는지, 빌드와 접근 도구가 가진 구조를 감당할 수 있는지입니다. 프로젝트를 가로지르는 원자적 변경이 흔하면 모노레포 도구에 투자하고, 팀과 서비스가 진정으로 독립적이면 저장소 간 조율 비용을 의도적으로 받아들이십시오. 요점은 구조를 코드가 실제로 얼마나 긴밀히 결합되어 있는지에 맞추고, 그 구조가 필요로 하는 도구에 재원을 대는 것입니다.
지금 바쁜 저장소에 살아 있는 자격 증명이 커밋된다면, 얼마나 빨리 탐지하며, 교체는 희망이 아니라 실제로 자동입니까? 이 장은 이력에 닿은 모든 비밀을 침해된 것으로 다루고 나중에 제거하는 일이 어렵고 신뢰할 수 없다고 경고하므로, 예방과 빠른 교체가 유일한 진짜 방어입니다. 큰 팀에서 노출은 누적됩니다. 공유 저장소에 푸시된 비밀은 몇 분 안에 수십 대의 머신에 복제되고 CI 캐시에 미러링되어, 느린 사람의 대응은 침해를 보장합니다. 상충하는 고려는 마찰입니다. 공격적인 프리 커밋 스캔과 강제 교체는 사람들을 늦추고 오탐을 만들기 때문에, 끄는 대신 통제를 조정해야 합니다. 증거를 가져오십시오. 비밀 스캔이 프리 커밋 훅과 CI 모두에서 실행되는지, 알려진 유출을 탐지하고 교체하는 평균 시간, 하드코딩의 유혹을 없애 주는 비밀 관리 시스템을 엔지니어가 갖고 있는지입니다. 기업과 정부 환경에서는 이를 인시던트 프로세스와 보존 규칙에 연결하십시오. 감사 가능한 이력에 유출된 자격 증명은 보안 사건이자 컴플라이언스 사건이며, 규제 기관은 누가 알았고 얼마나 빨리 행동했는지 물을 것이기 때문입니다.
브랜치는 정말 수명이 짧습니까, 그렇지 않다면 왜 미완성 작업을 기능 플래그 뒤에 숨기는 대신 브랜치에 주차시켜 둡니까? 이 장은 긴 분기가 병합 고통의 뿌리이므로 트렁크 기반 개발 쪽으로 강하게 기울며, 기능 플래그를 미완성 작업을 몇 주 동안 격리하는 대신 안전하게 병합하게 하는 메커니즘으로 제시합니다. 큰 팀에서 이것은 개인 취향이 아니라 조율 속성입니다. 몇 주 사는 모든 브랜치는 누군가 결국 조정해야 하는 현실의 사적 포크가 되고, 그 조정 비용은 인원이 늘수록 커집니다. 상충하는 고려는 기능 플래그에도 자체 비용이 있다는 점입니다. 런타임 복잡성, 조합 테스트, 폐기해야 할 낡은 플래그입니다. 데이터를 가져오십시오. 브랜치 수명의 실제 분포, 통합이 충돌이나 놀라움을 낳는 빈도, 지금 수명이 긴 브랜치가 몇 개 있고 왜인지입니다. 크거나 규제를 받는 조직에서는 릴리스 그림을 더하십시오. 진정한 다중 버전 지원은 규율 있는 백포팅이 있는 수명이 긴 릴리스 브랜치를 정당화할 수 있으며, 이는 일상 기능 작업을 메인라인 밖에 주차시키는 것과는 다른 결정입니다.
이력의 모든 변경을 올바른 보안 경계 안에서 작성자와 근거까지 추적할 수 있으며, 감사를 견딜 수 있습니까? 이 장은 접근 통제, 최소 권한, 변경을 작업 항목에 연결하는 것을 선택적 마감이 아니라 조직의 통제 프레임워크의 일부로 다룹니다. 큰 팀에서 추적성은 불투명한 커밋의 흐름을 인시던트나 컴플라이언스 검토 중에 추론할 수 있는 것으로 바꾸며, 접근 경계는 침해된 단일 계정이 닿아서는 안 될 코드에 닿는 것을 막습니다. 상충하는 고려는 개발자 속도입니다. 필수 작업 항목 연결, 세밀한 권한, 필수 리뷰는 작고 빠르게 움직이는 팀이 합리적으로 건너뛸 수 있는 의식을 더하기 때문입니다. 증거를 가져오십시오. 보호된 브랜치가 주장하는 검사와 리뷰를 요구하는지, 커밋이 승인된 작업 항목을 실제로 참조하는지, 접근이 오늘 실제 보안 경계에 어떻게 대응되는지입니다. 기업과 정부 맥락에서는 이를 분류, 보존, 감사 의무에 연결하십시오. 감사 불가능한 이력이나 지나치게 넓은 접근 부여는 프로그램을 멈추거나 인증을 실패시킬 수 있는 지적이 되기 때문입니다.

분야별 관점

스타트업. 속도와 생존이 이깁니다. 하나의 저장소를 쓰고, 트렁크 기반으로 일하고, 수명이 짧은 브랜치를 하루에 여러 번 병합하고, 미완성 작업은 긴 브랜치 대신 단순한 기능 플래그 뒤에 숨기십시오. 첫 커밋부터 비밀 스캔을 켜십시오. 공개 저장소에 유출된 키는 수습할 보안 팀이 없는 회사를 침몰시킬 수 있기 때문입니다. 정교한 브랜칭 모델과 무거운 프로세스는 건너뛰십시오. 보호된 main 브랜치와 의미 있는 커밋 메시지면 빠르게 움직이기에 충분한 규율입니다.

소기업. 전담 플랫폼이나 DevOps 전문가도 빠듯한 예산도 있으니, 관리형 기본값을 만들지 말고 사십시오. 호스팅 Git 제공자는 브랜치 보호, 필수 리뷰, 비밀 스캔을 기본으로 주므로, 유지할 수 없는 서버를 자체 호스팅하는 대신 그것에 의지하십시오. 결정을 데이터 위생으로 설명하십시오. 어느 저장소가 민감한 설정을 담고 있는지 알고, 자격 증명을 제공자의 비밀 관리자에 보관하고, 정말 필요한 소수의 규칙을 플랫폼이 시행하게 하십시오.

대기업. 어려운 문제는 많은 팀에 걸친 일관성입니다. 브랜치 보호, 커밋 관례, 비밀 스캔을 조직 전체 정책으로 표준화해 그룹들이 각자 재발명하지 않게 하고, 모노레포 대 폴리레포 선택을 결합 패턴에 따라 의도적으로 하며, 그것이 요구하는 확장된 빌드 도구나 저장소 간 조율에 재원을 대십시오. 코드 소유 규칙으로 변경을 올바른 리뷰어에게 라우팅하고, 추적성을 위해 커밋을 작업 항목에 연결하고, 버전 관리 위생을 개인의 습관 문제가 아니라 소유자와 지표가 있는 다스려지는 통제로 다루십시오.

정부. 조달 규칙, 투명성, 공적 책임성이 전체 구성을 형성합니다. 모든 커밋이 승인된 작업 항목을 참조하도록 요구하고, 분류 경계별로 접근을 통제하고, 비밀 스캔과 즉각적인 교체를 문서화된 인시던트 프로세스 아래 의무화하십시오. 모든 사이트가 한꺼번에 업그레이드할 수 없는 곳에서는 수명이 긴 릴리스 브랜치와 규율 있는 백포팅으로 여러 배포 버전을 지원하고, 인증, 정보 공개, 감독 요청에 허둥대지 않고 응답할 수 있도록 이력을 감사 가능하고 보존되게 유지하십시오.

사례

스타트업. 세 명 규모의 스타트업은 습관과 필요 모두에서 트렁크 기반으로 일하며, 수명이 짧은 브랜치를 하루에 여러 번 main에 병합하고 반쯤 끝난 기능은 단순한 플래그 뒤에 숨깁니다. 첫 커밋부터 CI에서 비밀 스캔을 켭니다. 공개 저장소에 유출된 API 키는 수습할 보안 팀이 없는 회사를 침몰시킬 수 있기 때문입니다. 하나의 저장소, 보호된 main 브랜치, 의미 있는 커밋 메시지가 자신의 이력에 걸려 넘어지지 않고 빠르게 움직이기에 충분한 규율을 줍니다.

대기업. 한 대형 기술 회사는 수백 개의 서비스와 공유 라이브러리가 있는 모노레포를 운영합니다. 확장된 빌드 도구와 코드 소유 규칙이 각 변경을 올바른 리뷰어에게 라우팅합니다. 하나의 커밋이 공유 라이브러리와 모든 소비자를 원자적으로 한꺼번에 갱신할 수 있어, 분산 저장소를 괴롭히는 버전 불일치 문제를 피합니다. 기능 플래그를 쓰는 트렁크 기반 개발이 메인라인을 릴리스 가능하게 유지하고, 비밀 스캔이 저장소 전체에서 커밋 시점에 자격 증명을 차단합니다.

정부. 한 국가 국방 계약자는 엄격한 추적성을 지킵니다. 모든 커밋은 승인된 작업 항목을 참조해야 합니다. 브랜치 보호는 통과하는 보안 스캔과 독립적인 리뷰를 요구하고, 접근은 분류 경계별로 엄격히 통제됩니다. 비밀 스캔은 의무이며, 노출된 자격 증명은 인시던트 프로세스 아래 즉시 교체를 촉발합니다. 수명이 긴 릴리스 브랜치는 모든 사이트가 한꺼번에 업그레이드할 수 없는 곳에서 여러 배포 버전을 지원하며, 보안 수정의 규율 있는 백포팅을 수행합니다.

비즈니스 사례: 동기, ROI, TCO

건전한 소스 관리는 도입하기는 거의 공짜이고 없이 지내기는 비쌉니다. 트렁크 기반 개발과 지속적 통합은 높은 소프트웨어 전달 성능과 가장 강하게 연관된 관행에 속하며, 이는 다시 더 나은 조직 성과와 상관됩니다. 깨끗하고 추적 가능한 이력은 인시던트를 진단하고 감사를 충족하는 데 걸리는 시간을 줄이고, 규율 있는 브랜칭은 통합 위기와 병합 마라톤이라는 반복되고 예산에 없던 비용을 아껴 줍니다.

가장 큰 비대칭 위험은 버전 관리에 있는 비밀입니다. 유출된 자격 증명 하나가 어떤 도구 투자도 압도하는 비용의 침해를 일으킬 수 있고, 이력은 그런 유출이 계속 남게 합니다. 막는 것은 싸고, 뒷수습은 그렇지 않습니다. 나쁜 구조 선택은 만성적 마찰로 나타납니다. 모든 저장소 간 변경이 조율 프로젝트가 되거나 모든 모노레포 빌드가 병목이 됩니다. 리더십을 설득하려면 브랜칭 전략을 전달 지표와 인시던트 진단 시간에 연결하고, 비밀 스캔과 접근 통제를 비싼 침해 및 감사 위험에 대한 저비용 통제로 설명하십시오.

안티패턴과 함정

수명이 긴 갈라진 브랜치: 고통스럽고 위험한 통합 사건으로 병합되는 몇 주의 고립된 작업.
이력의 비밀: 클론에 영원히 남고 일단 노출되면 교체가 필요한 하드코딩된 자격 증명.
큰 바이너리를 메인 이력에 커밋: 모든 클론을 영구히 부풀리고 모든 연산을 늦춥니다.
의미 없는 커밋 메시지: 문서로서의 이력의 가치를 파괴하는 “fix”, “wip”, “changes”.
생성된 코드를 손으로 쓴 것처럼 커밋: 시끄러운 차이, 병합 충돌, 진실의 원천에 대한 혼란.
결합에 맞지 않는 저장소 구조: 긴밀히 결합된 코드에 폴리레포, 또는 확장된 도구 없는 모노레포.
보호되지 않은 메인라인: 필수 검사가 없어 깨졌거나 리뷰되지 않은 코드가 모두가 의존하는 브랜치에 닿는 것.

성숙도 모델

1단계, 시작: 그때그때 이루어지고 반응적입니다. 브랜칭은 즉흥이고, 브랜치는 몇 주씩 살며, 커밋 메시지는 “fix”나 “wip”이고, 비밀 스캔이 없으며, 통합은 한 병합 위기에서 다음으로 휘청거립니다.
2단계, 발전: 기본 관행이 나타나지만 팀마다 다릅니다. 브랜칭 모델과 메시지 관례가 일부에 있지만 브랜치는 여전히 너무 오래 살고, 시행은 부분적이고, 비밀 스캔은 들쭉날쭉하며, 저장소 구조는 선택된 것이 아니라 물려받은 것입니다.
3단계, 표준화: 관행이 문서화되어 조직 전체에서 시행됩니다. 짧은 브랜치를 쓰는 트렁크 기반 개발, 보호되고 항상 릴리스 가능한 메인라인, 시행되는 커밋 관례, 훅과 CI 모두의 비밀 스캔, 최소 권한 접근, 의도적인 모노레포 또는 폴리레포 선택입니다.
4단계, 관리: 소스 관행이 데이터로 측정되고 통제됩니다. 브랜치 수명, 통합 빈도, 메인라인 깨짐률, 유출된 비밀을 탐지하고 교체하는 평균 시간, 변경에서 작업 항목까지의 추적성을 합의된 기준선에 대해 추적하고, 다음 인시던트를 기다리지 않고 수치가 표류하면 행동합니다.
5단계, 오케스트레이션: 관행이 지속적으로 개선되고 조직 전반에 통합됩니다. 브랜칭, 저장소 구조, 도구는 팀과 코드 결합이 변함에 따라 적응하고, 자동화는 위생을 끝에서 끝까지 시행하며, 버전 관리 데이터는 조직 전체의 전달, 보안, 위험 결정에 공급됩니다.

논의를 위한 아이디어

팀의 브랜치 수명은 실제로 짧습니까, 그렇지 않다면 무엇이 지속적 통합을 막고 있습니까?
모노레포 또는 폴리레포 선택은 코드가 실제로 얼마나 결합되어 있는지에 맞습니까?
오늘 큰 바이너리와 생성된 산출물을 어떻게 다루며, 그것이 얼마나 비용이 듭니까?
지금 살아 있는 자격 증명이 커밋된다면 어떻게 되며, 얼마나 빨리 탐지하고 교체하겠습니까?
여러분의 맥락에서 커밋 메시지와 추적성 규율을 얼마나 시행할 가치가 있습니까?
기능 플래그는 브랜칭 전략을 어떻게 바꾸며, 어떤 새 위험을 도입합니까?

핵심 요점

수명이 짧은 브랜치로 자주 통합하십시오. 긴 분기는 피하려던 고통을 일으킵니다.
메인라인을 릴리스 가능하게, 필수 검사로 보호하여 유지하십시오.
비밀이 이력에 들어가지 못하게 하십시오. 자동으로 스캔하고, 들어갔다면 즉시 교체하십시오.
실제 결합과 조율의 필요에 따라 모노레포 또는 폴리레포를 고르십시오.
커밋 이력을 의미 있고, 관례를 따르고, 원자적인 커밋으로 된 문서로 다루십시오.

참고 문헌과 더 읽을거리

Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: The Science of Lean Software and DevOps
Jez Humble and David Farley, Continuous Delivery
Scott Chacon and Ben Straub, Pro Git
Paul Hammant and others, writings on trunk-based development
Conventional Commits specification (as a reference standard)
Martin Fowler, articles on branching patterns and continuous integration