마스터에서 작업 지점으로 변경 사항을 가져 오십니까?

우리 중 두 명이 무언가를 연구하고 있습니다. 이 분기 구조를 사용하고 있습니다

• 석사
• dev-A
• dev-B

우리는 별도의 브랜치 (dev-A, B)에서 일하고 완료 될 때마다 변경 사항을 마스터로 홍보합니다.

그러나 이것의 단점은 다른 개발자가 변경 한 내용을 얻을 수 없다는 것입니다. 모든 것은 마스터 트리에 존재하지만 다른 개발자가 만든 최신 업데이트는 얻을 수 없습니다.

이를 해결하는 방법이 있습니까? 아니면 기능별로 분기 구조를 변경해야합니까?

두 가지 주요 시나리오에서 개발자 분기가 사용되는 것을 보았습니다.

1. 이러한 브랜치가 실제로 리포지토리 포크 인 오픈 소스 커뮤니티는 프로젝트 관리자가 마스터 리포지토리에 대한 액세스를 잠그고 풀 요청을 통한 통합을 요구할 수 있습니다. 이것은 기여자에게는 삶을 어렵게하지만 관리자에게는 훨씬 쉽습니다. 물론 정확히 요점이며, 이것은 GitHub에서 매우 성공적인 모델입니다.

2. 지속적 통합이없고 배포시 불안정성에 대한 추적 기록이 없거나 빌드에서 불안정성이 악화 된 팀과 조직. 이 팀들은 일반적으로 메인 라인의 안정성을 보호하기위한 방법으로 개발자 브랜치를 사용하려고 시도합니다. 결과는 일반적으로 릴리스 전에 길고 매우 고통스러운 병합 기간이 지나고 때로는 더 길고 고통스러운 안정화 기간이 따릅니다. 출시 후 까지는 발생하지 않습니다 .

CI가 왜 필요한지에 대한 열렬한 대화를 원하지 는 않지만 변경 사항을 자주 통합하지 못한다는 것을 아는 것은 분명합니다 . 따라서 IMO는 문제와 관련하여 춤을 추는 데 아무런 의미가 없습니다.

외부 개발자의 변경 사항을 "게이트"해야하는 지리적으로 분산 된 팀에서 실제로 작업하지 않는 한 개발자 별 지점 모델은 실제로 의미가 없습니다. 모든 개발자는 이미 기술적으로 자신의 저장소를 가지고 있기 때문에 git에서는 특히 의미가 없습니다 . 대부분의 조직은 하루에 여러 번처럼 자주 통합해야합니다.

저는 현재 약 35 명의 기고자 그룹으로 4 개의 개별 팀으로 나뉘며, 대부분의 사람들은 하루에 적어도 2-3 번, 일부는 10-15 번 체크인합니다. 빌드가 깨져서 몇 분 이상 깨져있는 것이 매우 드문 경우입니다. Git은 원격 개발자 브랜치가 불필요하게 오버 헤드가되도록 대부분의 시간에 쉽게 병합을 처리합니다. 푸시하기 전에 끌어 당기고 로컬로 병합하고 커밋 테스트를 실행하면됩니다.

마스터 브랜치의 안정성을 보호하기 위해 통합 을 절대적으로 연기 해야하는 경우 일반적으로 입증 된 모델은 성공적인 Git 브랜칭 모델에 설명 된대로 불안정한 브랜치 ( 개발 브랜치 라고도 함 )를 사용하는 것 입니다. 개발자가 하루에 한 번 이상 이 분기에 성공적으로 통합 할 수없는 경우 ( 빌드 해야하며 완벽하게 실행하지 않아도 됨) 품질 / 수양 문제가 있으며 개정 관리 문제는 아닙니다. 통합되지 않은 개발자 브랜치를 사용하여 문제를 해결하면 문제가 지연되고 실제로 그렇게함으로써 실제 병합이 실제로 필요한 것보다 훨씬 더 고통스럽고 불안정 해집니다.

기능 브랜치는 최악이 아니지만 IMO는 실제로 프로젝트를 보증 할만큼 큰 프로젝트는 거의 없습니다. 프로젝트가 매우 큰 경우 (즉, 수많은 기능이 한 번에 처리되는 경우) 소스 제어 관련 문제를 문서화하는 것보다 별도의 자치 구성 요소로 분할하여 더 나은 결과를 얻을 수 있습니다.

당신이 원하는 경우이 조언을 무시 할 수 있고, 많은 팀은 할 수 있지만, 분기 모델은 위의 링크 된 이유 중 하나는 너무 인기가 성공적으로는이 작업에 설계이다 로 하지 반대, 지속적인 통합.

당신이가는 경우 작업 지점에서 :

git commit -am "Committing changes before merge"
git merge master

다른 개발자 브랜치에서 병합 할 수도 있습니다

git checkout dev-A
git merge dev-B

할 일은 마스터의 변경 사항을 개발 지점에 병합 하는 것 입니다.

dev-A와 dev-B가 프로젝트마다 다른 지점이라면 @scaryrawr이 대답 한 것이 가장 좋습니다.

그러나 dev-A와 dev-B가 실제로 정확히 동일한 코드 (동일한 프로젝트) 인 경우 대안은 두 가지 중 하나에서 작동하는 것입니다. 예를 들어 'devWork'라는 브랜치 오프 마스터를 만듭니다. devWork를 체크 아웃하고 작업하고 변경 사항을 커밋하고 푸시합니다. 푸시 된 변경 사항은 Master가 아니라 devWork에 있으며 지점의 다른 사용자는 푸시 된 변경 사항을 로컬로 가져 오기만하면됩니다.

그런 다음 표준 방법을 따라 devWork에서 Master 등으로 작업을 다시 수행 할 수 있습니다.