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 yourbranchname삭제되기 전에 분기가 완전히 병합되었는지 확인하는 이유 입니다.
분기를 유지해야하는 몇 가지 이유가 있습니다. 프로덕션에 도달 한 후 버그가 다시 발생하는 경우이를 유지하고 싶을 수도 있고, 과거 기록을 원할 수도 있습니다.
두 경우 모두 브랜치의 헤드를 삭제하기 전에 태그를 지정할 수 있습니다. 태그는 몇 가지 사소한 차이점을 제외하고는 커밋에 대한 포인터라는 점에서 브랜치와 같습니다. 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
답변
이것이 일반적인 워크 플로우라고 생각합니다 (병합 후 삭제)
편집 그래서 적어도 짧은 분기의 경우 병합하는 대신 마스터에 다시 기반을 두는 것이 아이디어라고 생각합니다. 그런 다음 선형 변경 내역으로 끝나고 전체 분기가 메인 트렁크의 일부가됩니다. 이 경우 모든 변경 사항이 있으므로 분명히 사본이 필요하지 않습니다.