내 저장소에 여러 지점이 있고 시간이 지남에 따라 최신 상태로 유지하는 것이 어려워지고 있음을 알게되었습니다. 기억하기 쉽기 때문에 마스터가 항상 최신 상태인지 항상 확신 할 수 있습니다. 아직 SVN의 정신이 남아 있다고 생각합니다.내 지사를 최신 상태로 유지하는 방법
내 문제 난을 이런 식으로. bugfix2 브랜치를 변경하고 커밋을 마친 후에는 변경 사항을 마스터에 병합합니다.하지만 다른 여러 가지 브랜치가 있습니다. bugfix2를 다른 모든 분기에 수동으로 병합해야합니다. 내 지사 목록이 커짐에 따라이 모든 병합 작업을 수행하는 것은 비현실적이라고 생각합니다.
이 명령이 있습니까, 아니면 내 워크 플로가 잘못 되었습니까?
일반적인 워크 플로는 특정 분기에서 덜 구체적인 분기로 병합하는 것입니다.
그러나 a bug needed to be reported to all other branches를 들어, 다른 지점에 대한 간단한 병합이 충분하고 (심지어 별칭) 스크립팅 할 수 있습니다
for i in $branches; do
git checkout $i
git merge bugfix2
done
내 제안 워크 플로우 마스터가 강행되면, 마스터에 버그 수정 지점을 리베이스하는 것입니다. 그래서 당신의 역사는 깨끗하고 많은 병합 커밋을 포함하고 있지 않습니다.
좋은 습관이 아닙니다. 특정 코드베이스 상태에서 버그 수정이 이루어지며 마스터에 리베이스하면 "부동 커밋"이되고 적용 시점에 대한 지식은 줄어 듭니다. 다른 지점에서 병합하는 것이 더 좋습니다. – CharlesB
버그 수정 분기의 경우에 맞습니다. 자신의 예제에서 newfeature 브랜치와 같은 기능 브랜치의 경우, 내 작업 흐름이 더 나은 선택이 될 것입니다. 일단 병합되면 버그 수정 브랜치를 리베이스하는 것이 아닙니다. 그러나 (아직 병합되지 않은) bugfix 브랜치에서 작업하고 있고 master의 현재 변경 사항을 원한다면 왜 rebase하지 않아야할까요? bugfix 지점이 시작되었을 때 정보가 실제로 필요합니까? – dunni
기능 분기를 리베이스하는 것이 좋습니다. 버그 수정과 관련하여 올바른 상태를 파악하는 것이 중요합니다. 또한 리베이스 (rebase)하면 다른 버그가 생길 수 있으므로 더 복잡한 역사가됩니다. – CharlesB
내 충고는 현재 작업중인 모든 지점에 필요한 모든 것을 병합하고 나중에 작업 할 때까지 최신 상태로 유지하는 것에 대해 걱정하지 않는 것입니다. 내 회사의 중앙 집중식 VCS에서 git를 로컬로 사용하는 이유 중 하나는 지점을 조금 오래되게 할 수 있다는 것입니다. 재현하기 어려운 버그는보고 된 정확한 버전과 비교하여 작업 할 수 있습니다. 별도의 수정 프로그램을 푸시하기 위해 문제를 일으킨 변경 사항 또는 방금 가져온 업데이트 사항이 궁금하지 않고도 새로운 기능을 디버깅 할 수 있습니다. 꼭 여러분의 지점이 master에서 너무 멀어 지도록 두지 말고, "항상 그렇기 때문에"항상 최신 상태로 유지하는 것에 대해 종교적이지 마십시오. 개별 지점에 가장 적합한 시간에 업데이트하십시오.
이것은 다소 자동화되어 있습니다. 바로 앉아 있지 않는 뭔가가 있습니다. 유용한 해결책이지만, 당분간 나는 이것을 고수 할 것입니다. –
@Vince : 일반적으로 어떤 종류의 "옳지 않은가"는 지점 간의 관계가 부족합니다 (어떤 지점에서 어떤 지점으로 병합해야할지 모릅니다). 좋은 분기 명명 규칙이 도움이 될 수 있습니다. – VonC