2018 년에 생계를위한 소프트웨어를 작성한다면 “Git에 익숙하다”고 확신 할 수 있습니다. Linus Torvalds가 만든 도구는 버전 관리와 동의어가되었으며 의심 할 여지없이 Git의 가장 좋은 기능 중 하나는 분기 및 병합의 고통을 제거하는 방법입니다. Git에서 브랜치를 만드는 방법에는 여러 가지가 있습니다. 이 글에서 우리는 그들 중 일부를 검토 할 것입니다. 그런 다음 Git의 분기 모델과 일반적인 분기에 대한 약간의 반성으로 마무리 할 것입니다.

마스터에서 분기 만들기

분기 명령을 사용하여 당연히 Git에서 분기를 만듭니다. 다른 많은 Git 명령과 마찬가지로 “branch”는 매우 강력하고 유연합니다. 분기를 만드는 것 외에도 분기를 나열하고 삭제하는 데 사용할 수 있으며 추가 사용자 정의가 가능합니다. 광범위한 매개 변수 목록을 사용하여 명령을 실행합니다. 분기를 만드는 첫 번째 방법부터 시작하겠습니다. “my-app”이라는 새 폴더를 만들고 입력 한 다음 새 Git 저장소를 시작한다고 가정 해 보겠습니다. 이것이 정확히 수행 한 방법입니다.

mkdir my-appcd my-appgit init

이제 비어있는 새 Git 저장소가 있습니다.하지만 비어있는 저장소는 지루합니다. “Hello World!”가 작성된 새 마크 다운 파일을 만드는 것은 어떻습니까?

echo Hello World! > file.md

‘git status’를 실행하면 파일이 추적되지 않는다는 메시지가 표시됩니다.

추적되지 않은 파일도 멋있지 않으므로 추적 해 보겠습니다.

git add file.md

그리고 마지막으로 첫 번째 커밋 :

git commit -m "First commit"

이제 정확히 하나의 커밋이있는 하나의 브랜치가있는 저장소가 있습니다. 세상에서 가장 흥미 진진한 것 (진짜 “아님”이니까요)하지만 커밋이 전혀없는 리포지토리를 갖는 것보다 확실히 덜 지루하지 않습니까? 자, 어떤 이유로 든 파일을 변경해야한다고 말합시다 “의 내용.하지만 당신은” 그렇게하고 싶어요. 문제가 발생하여 파일의 아름답고 깨끗한 내용을 망칠 경우 어떻게됩니까? (예, “Hello World!”가 포함 된 어리석은 파일이라는 것을 알고 있습니다.하지만 상상력의 놀라운 힘을 사용하고 파일을 훨씬 더 복잡한 프로젝트의 프록시로 생각하십시오.)이 딜레마에 대한 해결책 물론 새 분기를 만드는 것입니다.

git branch exp

이제 실험을 위해 “exp”라는 새 분기가 있습니다. 다른 버전 관리 시스템, 특히 중앙 집중식 시스템을 사용하는 데 익숙한 일부 사람들은 브랜치가 동일한 “컨텐츠”를 가지고 있다고 말할 수 있습니다.하지만 Git에 대해 이야기 할 때 이것이 완전히 정확하지는 않습니다. 분기를 주어진 커밋을 가리키는 참조와 같은 것으로 생각하십시오.

커밋에서 분기 만들기

어떤 이유로 든 우리가 단일 항목을 추가하지 않고 실험을 포기한다고 가정합니다. 새 브랜치에 커밋합니다. master로 돌아가서 exp 브랜치를 삭제하겠습니다.

git checkout mastergit branch -d exp

이제 단일 브랜치로 돌아갑니다. 수행중인 작업을 시뮬레이션하기 위해 몇 가지 커밋을 추가해 보겠습니다.

이 모든 “작업”을 수행 한 후에 어떤 이유에서든 시간을 거슬러 올라갈 필요가 있음을 배운다고 상상해보십시오. 파일에 두 줄 뿐이고 그때부터 새로운 변경 사항을 생성합니다. 그러나 동시에 이미 수행 한 진행 상황을 유지해야합니다. 즉, 과거 커밋에서 분기를 생성하려고합니다. 어떻게 수행합니까? ? Git에서 각 커밋에는 고유 한 식별자가 있습니다. 따라서 “git log”명령을 사용하여 쉽게 확인할 수 있습니다. 특정 커밋을 기반으로 새 분기를 만들려면 해당 해시를 분기 명령에 매개 변수로 전달하면됩니다.

git branch new-branch 7e4decb

제외로, 대부분의 경우 전체 해시가 필요하지 않습니다. 처음 5 ~ 6 개의 문자 만 가능합니다.

태그에서 브랜치 만들기

Git에 대해 조금 더 익숙하다면 태그의 개념입니다. 특정 커밋이 어떤 방식 으로든 중요하거나 특별하다는 것을 나타 내기 위해 태그를 사용합니다. 예를 들어, 태그는 일반적으로 제품의 실제 버전을 나타내는 데 사용됩니다. 한동안 애플리케이션에서 작업하고있는 경우 버전 1.0을 출시 할 때라고 생각합니다. 일반적으로 필요한 경우 버전 번호를 높이고 이러한 변경 사항을 적용한 다음 특정 시점에 태그를 추가합니다. 태그를 생성하려면 일반적으로 다음과 같이 실행합니다.

git tag -a v1.0 -m "First major version"

“-a”매개 변수는 이것이 진행됨을 나타냅니다. 경량 태그와 달리 이것은 커미터의 이름과 이메일, 타임 스탬프 및 메시지와 같은 정보를 포함하는 완전한 Git 객체입니다. 이제 역사상이 특정 지점이 특별하고 이름이 있음을 나타내는 태그가 있습니다. 좋은. 평소와 같이 계속해서 1.1 버전에 포함될 변경 사항을 만들고 커밋 할 수 있습니다. 버그 보고서가 올 때까지. 일부 클라이언트는 1로 업데이트되었습니다.0 버전의 제품에서는 가져 오기 기능이 “의도 한대로 작동하지 않는다고 말합니다. 이론적으로 마스터 브랜치에서 버그를 수정하고 배포 할 수 있습니다.하지만 클라이언트는 잠재적으로 테스트되지 않고 불완전한 기능을 받게됩니다.” -아니. 그래서 당신은 무엇을합니까? 답 : 메이저 버전을 나타 내기 위해 생성 한 태그에서 새 브랜치를 생성합니다. 여기서 문제를 수정하고 빌드하고 배포합니다. 나중에이를 마스터에 다시 병합해야하므로 다음 릴리스에 수정 사항이 포함됩니다. . 어떻게 하시겠습니까? 쉬움 :

git branch <NAME-OF-THE-BRANCH> <TAG>

더 구체적으로, 이전 예를 사용하여 :

git branch fix-bug-123 v1.0

그런 다음 평소처럼 새 브랜치를 확인할 수 있습니다. 더 나은 방법은 한 번에 모든 작업을 수행하는 것입니다.

git checkout -b fix-bug-1234 v1.0

분리 된 헤드 상태에서 분기 만들기

시간을 거슬러 올라가고 싶었던 적이 있습니까? Git을 사용하면 가능합니다 … 적어도 저장소의 파일과 관련하여. 해시를 알고 있으면 언제든지 커밋을 확인할 수 있습니다.

git checkout <SHA1>

실행하면 Git에서 흥미로운 메시지를 표시합니다.

You are in "detached HEAD" state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

결제 할 때 커밋하면 특별한 상태가됩니다. c 보시다시피 “분리 된 HEAD”입니다. 이 상태에서 변경 사항을 커밋 할 수 있지만 해당 커밋은 어떤 브랜치에도 속하지 않으며 다른 브랜치를 확인하자마자 액세스 할 수 없게됩니다.하지만 이러한 커밋을 유지하려면 어떻게해야합니까? 당연히 대답은 다음을 사용하는 것입니다. “체크 아웃”명령을 다시 실행하여 새 브랜치를 만듭니다.

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

물론 이제는 마지막 두 줄을 단일 명령으로 :

git checkout -b new-branch-to-keep-commits

매우 쉬웠 죠?

할 수 있기 때문에 … 그렇게해야한다는 의미는 아닙니다.

Git의 분기 모델은 판매 포인트 중 하나입니다. 다른 소스 제어 시스템에서 고통스럽고 느린 프로세스를 쉽게 처리 할 수 있습니다. Git이 대중을 위해 성공적으로 분기를 민주화했습니다. 그러나 심각한 위험이 있습니다. Git의 분기가 저렴하기 때문에 일부 개발자는 매우 오래 지속되는 분기로 작업하거나 통합을 지연시키는 워크 플로 또는 분기 모델을 사용하는 함정에 빠질 수 있습니다. 격자. 우리는 산업으로서 거기에있었습니다. 우리는 그렇게했습니다. 작동하지 않습니다. 대신 매우 짧은 분기를 사용하는 워크 플로를 수용하십시오. 당신은 “일을 깨뜨 리거나 동료의 시간을 낭비하는 것에 대한 두려움없이 코딩 할 수있는 안전한 샌드 박스를 갖게 될 것입니다.” 하지만 “부분적으로 완성 된 기능을 사용하여 코드를 배포하려면 어떻게해야합니까?”라는 질문이 있습니까? 이 경우 구조를위한 기능 플래그입니다. Git 브랜치는 강력한 도구입니다. 현명하게 사용하고 남용하지 마십시오. 또한 충분하지 않은 경우에는 특수 도구를 포함하여 기능 플래그와 함께 지속적 배포 / 지속적 통합을 사용하여 애플리케이션을 다음 단계로 끌어 올릴 수 있습니다.