이전 투고 기사의 계속.
지난번에'Giit의 창고 구조'와'상용하는 기본 Giit 명령'을 소개했다.
이번에는 응용이 좀 있어서 팀 개발이 필수입니다.
'지점 전략' 과'merge,rebase 명령 '을 초점으로 설명하다.

분기 전략

분기전략은 기릿의 최대 특징인'병행개발'을 더욱 효과적으로 활용하기 위해 각 분기를 어떻게 관리하고 어느 분기로 통합하는지 등 명확한 운용규칙을 말한다.

분기

하나의 소프트웨어와 제품에서 갈라져 여러 구성원이 동시에 기능 추가, 오류 수정 등을 진행한다.
또한 지점 지점은 다른 지점의 영향을 받지 않기 때문에 같은 창고에서 여러 개의 변경을 동시에 할 수 있다.

(참조) git flow

지트의 지점 운용 전략을 활용한 범례 중 하나다.( git flow 소개 )
기타 github flow 같은 git flow 모뎀도 있습니다.
이러한 차이점에 대해 다음 Qita의 글은 간결하게 요약되었으니 참고하시기 바랍니다.1

브랜치 결합

발행판은 언제든지 제작할 수 있는 지점을 위한 것이다.
또 화제의 분기인 지부도 사용해야 하기 때문에 항상 안정적인 상태를 유지해야 하기 때문에 젠킨스 등 CI 도구를 이용한 자동 구축과 테스트에서 품질을 보증하는 것이 좋다.
일부 수정 또는 기능을 추가하려면 병합 지점에서 테마 지점을 만들어서 작업을 진행하십시오.
(Subversion이 말한 것과 trunk 개념은 같다.Giit에서 다중 손가락master

이른바 화제의 갈래

기능 추가와 오류 수정 등 어떤 과제와 특정 목적 실현에 관한 작업을 하기 위해 제작된 지점이다.
여러 과제를 동시에 진행할 때 여러 주제의 지점을 만들 수 있다.
테마 지점은 합병 지점 지점의 형식으로 만들어졌으며 작업이 끝나면 합병 지점으로 들어갑니다.

분기 전환 및 분기 결합

지점 전략을 실시할 때 어떻게 지점을 신설하고 작업이 끝난 지점을 합병 지점에 도입하는지 구체적으로 설명한다.

분기 전환

Giit에서는 다음 명령을 실행하여 분기를 생성하고 전환할 수 있습니다.

git branch(분기 제작)

테마 지점을 만듭니다.

git branch <branchname>: 신규 브랜치 생성

git checkout -b <branchname>: 새 브랜치를 생성하고 브랜치로 전환

git checkkout(분기의 전환)

업무 지점을 전환합니다.

git checkout <branchname>: 로컬 브랜치를 지정된 브랜치로 전환

분기 결합

합병 지점에서 주제 지점을 사용하는 방법은rebase과merge 두 가지가 있다.
먼저 설명rebase.
리베이스란 말 그대로'베이스 재정의'다.
제가 대략적인 절차를 설명하겠습니다.

현재의 정보는 다음과 같이 정리되어 있다.
【마스터 지점】
• 발행 등에 쓰이는 지부.
· 다른 변경도 있었고 현재 최신 버전은'D'(버전명은 편의를 위한)입니다.
【develop 지점】
• Master 분기의 버전 "B"분기의 버그를 수정하는 데 사용되는 분기
●develop 분기는 마스터 분기의 버전'B'를 바탕으로 X, Y 두 가지 버그 수정 제출을 실시했다.
이 상태에서 bugfix 지점에서
rebase 명령git rebase <repository>/<branch name(今回はmaster)>"마스터 지점의 최신 제출된base를 다시 정의합니다."를 실행하면 다음과 같습니다.

개발자 지점의 시작점인 마스터 지점의 버전이 'B' 에서 'D' 로 변경되었습니다.
그때 지금까지 버그픽스가 변경한 제출'X, Y'가'X', Y'로 바뀌었다.
리베이스를 실행함으로써 버그픽스가 제출한 내용이 그대로'교환베이스를 통해 X, Y가 다른 제출로 식별되고 제출한 해시 값이 변경되기 때문이다'고 설명했다.
리베이스를 진행할 때 버그믹스 지점에서 마스터 지점의 최신 정보 + 버그믹스 수정이 진행 중이기 때문에 "X", Y "의 변경 사항을 마스터 지점에서 처리해야 합니다.
그러나merge를 진행할 때 bugfix의 원격 창고에 대한 회답을 하고 C, D의 결과를 제출하여push를 해야 하며, 일반적인 상황에 따라push를 진행하면 다음과 같은 오류가 발생할 수 있습니다.
$ git push origin develop
To <git repository informarion>
! [rejected] develop -> develop (non-fast-forward)
error: failed to push some refs to '<git repository informarion>'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
이것은 non-fast-forward(대체적으로 로컬 제출 정보가 원격 창고의 최신 제출에 대한 간단한 보충 상태가 되지 않은 상태) 때문에 발생한 오류입니다.
리베이스, X, Y의 제출이 사라지면서 X'가 생겼고 Y'라는 Git가 모르는 제출이 생겨서 간단하게 처리할 수 없었기 때문이다.
처리하려면git push -f origin develop 참조
강제 덮어쓰기는 -f 옵션(force Pus)만 추가할 수 있습니다.
무사히 완성하면 아래의 나무가 된다.

분기 결합(merge)

만약rebase가 간단하게 말하면, 합병 지점의 시작에 화제 지점의 정보를 추가하면,merge는 합병 지점과 주제 지점 두 가지 변경된 합병 제출을 만들고, 합병 지점의 시작은 제출로 이동합니다.

상기 트리 구조의 경우merge 명령을 실행할 때 구조는 다음과 같다.

rebase와merge의 차이

베이스와merge는 모두 지점을 통합시키는 동작이지만 '역사 관리' 에는 차이가 있다.
・rebase: 이력서가 간단해졌지만 원서에서 변경 내용이 변경되었습니다.
이 때문에 원 위원들은 때때로 움직이지 않는 상태다.
• merge: 변경된 이력서는 그대로 유지되지만 이력서는 복잡해집니다.
어떤 것을 채택할지는 개발의 운용 상황에 따라 정해지지만 따로 사용하면 다음과 같이 분류할 수 있다.
• 화제 분기를 주어로 하다
합병된 지점의 최신 코드를 꺼낼 때:rebase
(GiitHub 또는 GitLab을 사용할 때 회답하는 화제 지점을 종합 지점에 맞추어 Pull/Merge Request를 제시하는 인상을 준다)
/종합 지점을 주어로 하다
특정 테마 지점의 변경 사항을 지점으로 통합하려면:merge
(원시적인 Giit를 사용할 때 합병 지점에서 화제 지점의 제출을 받기 때문에 이것을 사용할 기회가 많다)
참조git flow와 github flow는 무엇입니까?그 차이점은?↩