Git 기능 브랜치를 삭제할 적절한시기는 언제입니까?

Git 기능 브랜치를 삭제할 적절한시기는 언제입니까?

---

82 개의 기능 브랜치 로 끝나고 싶지 않기 때문에 마스터에 병합하자마자 기능 브랜치를 간단히 삭제하는 것이 잠재적 인 단점이 무엇인지 궁금합니다.

워크 플로우 :

git co -b feat-xyz
hack hack
git ci
hack some more
git ci
git co master
git merge feat-xyz
smoke test
git br -d feat-xyz

여기에 문제가 있습니까?

---

병합 후 삭제는 일반적인 방법입니다. 이것이 git branch -d삭제되기 전에 분기가 완전히 병합되었는지 확인하는 이유 입니다.

분기를 유지해야하는 몇 가지 이유가 있습니다. 프로덕션에 도달 한 후 버그가 다시 발생하는 경우이를 유지하고 싶거나 과거 기록을 원할 수 있습니다.

두 경우 모두 브랜치의 헤드를 삭제하기 전에 태그를 지정할 수 있습니다. 태그는 몇 가지 사소한 차이점을 제외하고는 커밋에 대한 포인터라는 점에서 브랜치와 같습니다. 1) porcelain은 일반적으로 체크 아웃시 git show-branch 또는 tab-auto complete와 같은 탐색 명령에 태그를 표시하지 않습니다. 2) 하나를 체크하면 분리 된 (비 참조) HEAD에 놓이게됩니다. 3) " 태그 지정 메시지 "를 남길 수 있습니다. 그러면 태그가 커밋처럼 객체 저장소에 객체로 저장됩니다.

이렇게하면 기록을 보존 할 수 있으며 버그 수정이 필요한 경우 수정을 위해 master에서 새 분기를 만드는 것이 좋습니다.

---

병합 후 삭제하지만 git merge --no-ff, 분기 기록이 그래프에 표시되도록 빨리 감기를 방지하기 위해 항상을 수행합니다 . 기능 브랜치가 개발 브랜치에서 출발 한 위치와 다시 결합 된 위치에 대한 기록을 갖고 싶습니다.

이것은 Vincent Driessen 의 성공적인 Git 분기 모델 에서 가져 왔으며 , 대부분의 프로젝트에 적용하는 git과 함께 사용하기에 매우 좋은 워크 플로입니다.

---

기능 분기를 잠시 유지하려는 두 가지 이유를 생각할 수 있습니다.

• 업스트림에서 더 많은 작업을 수행하기 위해 다시 쫓겨날 가능성이 있습니다.
• 다른 개발자는 마스터에서 다른 모든 것을 원하지 않고 해당 기능을 원할 수 있습니다.

실제로 병합 후 삭제하는 대부분의 경우 괜찮습니다.

---

일반적인 워크 플로우는 다음과 같습니다.

 // Create new branch
 $ git checkout -b myfeature
 // and then do some changes and commit them

 // Switch to master branch
 $ git checkout master

 // Merge myfeature to master. --no-ff will always keep branch information.
 $ git merge --no-ff myfeature

 // Delete myfeature branch
 $ git branch -d myfeature

 // Push the changes
 $ git push origin master

---

이것이 일반적인 워크 플로우라고 생각합니다 (병합 후 삭제)

편집 그래서 병합보다는 적어도 수명이 짧은 분기의 경우 아이디어는 마스터에 기반을 두는 것이라고 생각합니다. 그런 다음 선형 변경 내역으로 끝나고 전체 분기가 기본 트렁크의 일부가됩니다. 이 경우 모든 변경 사항이 있으므로 분명히 사본이 필요하지 않습니다.

참고 URL : https://stackoverflow.com/questions/3392392/when-is-the-right-time-to-delete-a-git-feature-branch