Git에서 분기를 언제 삭제합니까?

안정적인 응용 프로그램이 있다고 가정하십시오.

내일 누군가 누군가 우리가 바로 핫픽스를 결정하기로 한 큰 버그를보고합니다. 따라서 "master"에서 해당 핫픽스에 대한 분기를 작성하고 이름을 "2011_Hotfix"로 지정한 다음 모든 개발자가이를 수정하기 위해 공동 작업 할 수 있도록이를 푸시합니다.

버그를 수정하고 "2011_Hotfix"를 "master"및 현재 개발 지점으로 병합합니다. "마스터"를 누르십시오.

이제 "2011_Hotfix"로 무엇을합니까? 그것이 끝날 때까지 영원히 지점으로 앉아야합니까, 아니면 목적을 달성 했으므로 삭제해야합니까? 가지 목록이 매우 길어질 가능성이 높기 때문에 대부분의 지점이 더 이상 필요하지 않기 때문에 지점을 어디에나 두는 것이 부정한 것처럼 보입니다.

삭제해야 할 경우 기록은 어떻게 되나요? 실제 지점을 더 이상 사용할 수 없어도 유지됩니까? 또한 원격 지점을 어떻게 제거합니까?

로 분기를 안전하게 제거 할 수 있습니다 git branch -d yourbranch. 병합되지 않은 변경 사항이 포함 된 경우 (예 : 분기를 삭제하면 커밋이 손실 됨) git에서 알려주고 삭제하지 않습니다.

따라서 병합 된 브랜치를 삭제하는 것은 저렴하며 기록을 잃어 버리지 않습니다.

원격 지점을 삭제하려면 git push origin :mybranch원격 이름이 origin이고 삭제하려는 원격 지점의 이름이 mybranch라고 가정하고을 사용하십시오.

당신이해야 할 일은 당신이 릴리스하는 모든 것을 태그입니다. 적극적으로 개발할 때 지점을 유지하십시오.

와 함께 오래된 지점 삭제

git branch -d branch_name

서버에서 삭제

git push origin --delete branch_name

또는 이전 구문

git push origin :branch_name

"원점에서 branch_name에 아무것도 넣지 마십시오"라고 읽습니다.

즉, DAG (directed acyclic graph)가 지시 할 수있는 한, 커밋은 히스토리에있을 것입니다.

구글 "git-flow"는 릴리스 관리, 브랜칭 및 태깅에 대한 통찰력을 제공 할 수 있습니다.

질문에 "github"태그가 있기 때문에 특히 이것을 추가 할 것입니다. 특히 Github 에서 분기 를 풀 요청 하면 UI를 통해 또는 풀 요청 분기를 병합하여 병합됩니다. 분기를 제거하더라도 풀 요청 데이터 (주석 포함)가 손실됩니다 .

결과 : 풀 요청을 워크 플로의 일부로 통합하면 (코드 검토와 잘 혼합 됨) 분기가 병합 되 자마자 안전하게 삭제할 수 있습니다. 이것은 Github이 최근에 풀 요청을 병합 한 직후 "지점 삭제"버튼을 표시하는 (달콤한) 기능을 추가 한 매우 흔한 일입니다.

그러나 각 그룹이 자신에게 가장 적합한 워크 플로우를 채택해야한다는 점에 주목할 필요가 있습니다 (그러한 브랜치를 삭제하거나 생성하지 않을 수도 있음). 예를 들어, 현재의 작업 팀은 풀 요청이 병합 되 자마자 마스터 또는 배포 관련이 아닌 모든 지점 (예 : 생산, 준비 등)을 제거하고 관련 커밋이 어떻게 형성되었는지를 추적합니다. 각 제품의 각 점진적 개선.

물론 히스토리 관리 (풀 요청 또는 기타 방법)가 버전의 적절한 태그 지정을 대체하지 않으므로 (버전을 배포 / 패키징하는 동일한 도구 / 스크립트로 자동화하는 것이 바람직 함) 사용자가있는 모든 상황으로 항상 빠르게 전환 할 수 있습니다 주어진 순간에. 태깅은 원래 문제를 해결하기위한 핵심이기도합니다. "작업"분기에 병합 된 분기를 삭제할 수 있고 삭제해야하고 버전 태그, "생산"등으로 병합 된 분기를 삭제하지 않아야하는 경우 이후 버전에 통합 될 때까지 항상 핫픽스가 유지됩니다.

브랜치를 삭제하는 단점은 GitHub의 해당 브랜치에 대한 하이퍼 링크를 끊는다는 것입니다 (이 질문에는 github 태그가 붙어 있습니다). 당신은 얻을 것이다 404 Not Found그 링크에 오류가 발생했습니다. 이것이 GitHub에서 브랜치를 삭제 한 후 커밋 또는 태그를 가리 키도록 링크를 변경하는 이유입니다.

이메일과 같은 일부 링크는 변경할 수 없으므로 이제 GitHub 브랜치에 대한 하이퍼 링크를 피하고 첫날부터 커밋 또는 태그에 링크합니다.

병합 된 분기를 삭제하는 것이 좋습니다. 이렇게하면 리포지토리에있는 긴 분기 목록의 시각적 혼란을 막을 수 있습니다. 이 지점은 또한 모든 저장소의 포크로 전파됩니다.

먼저 로컬 지점을 삭제합니다. 이렇게하면 나중에 실수로 밀리지 않습니다.

git branch -d branchName

그런 다음 원격 추적 지점을 삭제합니다.

git branch -dr remoteName\branchName

그런 다음 GitHub에서 분기를 삭제합니다. 웹 인터페이스를 사용하지만 해당 명령은 다음과 같습니다.

git push remoteName :branchName

지점이 병합되지 않더라도 일반적으로 여전히 후손을 위해 커밋을 유지하고 싶습니다. 그러나 여전히 지점을 삭제하고 싶습니다. 커밋을 분산시키고 가비지 수집기에서 먹지 못하게하기 위해 삭제 된 분기와 동일한 커밋을 가리키는 주석이 달린 태그를 만듭니다.

git tag -a tagName commitOrBranchName

그런 다음 태그를 github에 푸시합니다.

git push remoteName tagName

2011_Hotfix기록을 잃지 않고 지점 을 삭제하려고합니다 . 먼저 삭제와 역사에 대해 논의하겠습니다.

일반적인 git분기 삭제 방법은 이미 위에서 설명했으며 예상대로 작동합니다. git" git로컬 및 원격 분기를 모두 삭제하십시오 "라는 의미의 한두 단어 명령이 없습니다 . 그러나이 동작은 쉘 스크립트를 통해 흉내낼 수 있습니다. 예를 들어 Zach Holman의 쉘 스크립트 'git-nuke'를 사용하십시오 . 매우 간단합니다 :

#!/bin/sh
git branch -D $1
git push origin :$1

이것을 디렉토리 git-nuke중 하나의 실행 파일 (예 :)에 넣으십시오 $PATH. 2011_Hotfix지점 에 있지 않으면 단순히 실행 git-nuke 2011_Hotfix하면 로컬 및 원격 지점이 모두 삭제됩니다. 이것은 표준 git명령 보다 훨씬 빠르고 간단하지만 더 위험 합니다.

역사 보존에 대한 우려는 좋은 것입니다. 이 경우 걱정할 필요가 없습니다. 병합 후 2011_Hotfix에 master, 모든 커밋이 2011_Hotfix추가됩니다 master의 역사를 커밋합니다. 간단히 말해서 간단한 병합으로 기록을 잃지 않을 것입니다.

추가 할 단어가 하나 더 있습니다. 아마도 귀하의 질문 범위를 벗어나지 만 관련이 있습니다. 20 개의 작은 "진행 중"커밋이 있다고 상상해 봅시다 2011_Hotfix. 그러나 하나의 완전한 커밋 만의 기록에 2011_Hotfix추가하려고 master합니다. 20 개의 작은 커밋을 하나의 큰 커밋으로 어떻게 결합합니까? 다행히을 git사용하여 여러 커밋을 하나의 커밋으로 통합 할 수 있습니다 git-rebase. 여기서는 어떻게 작동하는지 설명하지 않습니다. 그러나 관심이 있다면 설명서git-rebase 가 훌륭합니다. git rebase역사 를 다시 쓰므로 주의 깊게 사용해야합니다. 특히 처음 사용하는 경우 더욱 그렇습니다. 마지막으로 2011_Hotfix시나리오는 솔로 개발자가 아닌 개발자 팀에 관한 것입니다. 프로젝트 팀원이git rebase팀의 git rebase일부 카우보이 개발 팀이 프로젝트의 git역사를 무의식적으로 손상시키지 않도록하기 위해 사용에 대한 명시적인 지침을 마련하는 것이 현명합니다 .

성공적으로 병합되고 태그가 추가되면 더 이상 사용하지 않는다고 말할 수 있습니다. 따라서 안전하게 할 수 있습니다 git branch -d branchname.

원점에서 제거 된 로컬 브랜치를 프룬하려면 다음을 사용하면서 프룬 할 수 있습니다. git fetch

git fetch --prune

github, BitBucket과 같은 모든 주요 웹 UI에서 분기를 삭제할 수 있습니다. 지점을 온라인으로 삭제 한 후 다음을 사용하여 로컬 지점을 삭제할 수 있습니다

git remote prune origin