사내 개발을위한 git 사용을위한 워크 플로우 설명

Question

내가 일하는 회사는 월별 릴리스를 원하며 git으로 전환하도록 유도하려고합니다. 이 문제를 해결하는 적절한 방법은 각 릴리스 (예 : 매월)마다 통합 분기를 만들고 새로운 개발 및 변경을 위해 통합 분기에서 기능 분기를 만드는 것입니다. 환경에는 상호 의존성이로드되고 다른 외부 시스템의 필수 기능이 지연되기 때문에 기능이 다른 달로 연기되어야하는 경우가 있습니다. 프로젝트는 일반적으로 2 ~ 3 개의 통합 지점에서 동시에 활동하며 활동은 상당히 밀접한 관계가있는 사람들로 제한됩니다. (이는 우리가 마지막 통합 지점에있는 동안 리베이스를 사용할 수 있다고 생각하는 것을 의미합니다. 절반의 사람들에게 절반 이상이 사실입니다.)

많은 사람들이 관련되어 있으므로 이 작업을 수행하는 방법에 대한 몇 가지 간단한 지침이 필요합니다. 분기/병합 구조에 대한 논리적 인 설명과이를 수행하기위한 실질적인 git 명령이 필요합니다. 누구나 그런 워크 플로우에 알맞은 설명을 알고 있습니까? 통합 지점과 지점을 제공 :

Answer 1

분기/병합 구조

구조의 논리적 인 설명은 기본적으로 당신이 한 말을 다음과 같습니다.
이런 종류의 워크 플로에서는 모든 개발이 다음 릴리스로 넘어 가지 않는다는 것을 이해하는 것이 중요합니다.
그러나 DVCS를 사용하면 지점을 게시하고 복제 할 수 있음을 이해하는 것이 중요합니다. 마지막 포인트 (게시)를 병합에 큰 영향을 미칠 것이다

즉, 명령 :

• 병합
• REBASE. 개발자가 어떤 통합 지점에 그의 작품을 병합 할 때마다

(그는 "중앙"저장소에서 가져온), 내가 추천 :

# switch back to previous release tag (from where feature branches for next release where done) 
$ git checkout previousReleaseTag 
# create one's own private 
$ git checkout -b myIntegrationBranch 
# merge or cherry-pick what we want to actually put in the next release 
$ git merge... from our feature branch 
# rebase that private integration branch on top of actual integration branch 
$ git rebase integrationBranch 

마지막 REBASE은 지역의 역사를 다시 쓸 것 지회에서 당신은 아무렇게나 출판하지 않을 것입니다 (해를 끼치 지 않음).
모든 새 기능이 작동하면 해당 개인 분기를 관련 통합 분기의 현재 HEAD에 병합 할 수 있습니다.

"개인 분기 - 병합 또는 체리 선택 - rebase - 로컬 확인 - 병합"은 여러 작업 팀이 자신의 작업을 공통 분기에 병합해야하기 때문에 필요한 작업 과정입니다. 사설 지사에 게시하려는 내용을 일반 지사에 병합하기 전에 재생해야합니다. 그렇지 않으면 각 지사가 공통 지사의 HEAD로 표시된 것을 해할 수 있습니다. 질문에

기타 자세한 사항 :

• git commit frequency
• git releases management (다른 병합 워크 플로우)
• JC Hamano articles (Jakub Narębski 덕분에)