통합 vs 기반 재설정

merge와rebase는 모두 Git공구가 집중된 우수한 공구로 때로는 혼동되고 오용될 수도 있지만 각기 다른 용례와 관련이 있다.팀 규칙이 처음에는 도움과 지도를 위해 만들어졌지만 단순성을 방해하는 경우가 많기 때문이다.
사람들이 Git를 사용하는 대부분의 방식은 개발자로서의 문화와 경험에서 나온다.합병과 재기초는 확실히 없지만 정해진 상황에서 항상 올바른 방법이 있다.어떤 경우, 사람들은 기준을 재설정하는 것이 더 적합하다는 것을 발견할 수도 있고, 합병은 결국 더 도움이 될 수도 있다.

병합

Git 문서:

git-merge - Join two or more development histories together

합병 조작의 용례는 전진하는 생각과 관련이 있다.공통 목표는 다음과 같습니다.

기능(테마) 분기 업데이트main 분기를 사용합니다.

분기의 최신 작업 업데이트 기능(주제) 분기를 사용합니다.

두 히스토리를 결합하는 가장 일반적인 예는 주제 분기를 상위 분기로 통합하는 것입니다. 일반적으로 GitHub과 같은 원격 공급업체에서 수행합니다.

git checkout A  # Could be "main", or "master"
git merge B  # Update A with B

결합 커밋 M1을 사용하여 분기 B를 분기 A에 결합합니다.
동일한 원칙에 따라 작업을 계속하거나 상향 합병을 준비하기 전에 부모 레벨로 테마 지점을 업데이트할 수도 있다.

git checkout B  # A topic branch
git fetch remote A  # Make sure to download the latest stuff
git merge remote/A  # Update B with latest A

통합 커밋 M1이 있는 분기 A로 분기 B를 업데이트합니다.
Git도 코드를 틈새 없이 통합하기 위해 최선을 다하지만, 때로는 코드를 한데 연결하는 데 도움을 필요로 할 뿐이다.이 시간들은 충돌이라고도 불린다.그러나 합병 제출의 장점 중 하나는 충돌이 합병 단계에서 해결되고 내부의 제출을 고려하지 않는다는 것이다.합병의 본질은 앞으로 추진하는 것이기 때문에 충돌이 처리되면 다시는 문제가 생기지 않는다.

git checkout A  # Could be "main", or "master"
git merge B  # Update A with B
# --- conflict resolution work ---
git add conflicting-file.txt  # Mark conflict as resolved
git commit  # Finish merging (by creating a merge commit)

분기 B를 분기 A로 결합하고 결합 커밋 M1에서 충돌을 해결합니다.
또 다른 흔한 방법은 빠른 추진 전략으로 지점을 합병하는 것이다.위의 예를 고려하면 합병 프로세스가 합병 제출을 생성하지 않을 것입니다. 왜냐하면 지점 B의 맨 왼쪽 제출은 지점 B의 맨 오른쪽 제출 후에 만들어졌기 때문입니다.

git checkout A  # Could be "main", or "master"
git merge --ff B  # Update A with B with fast-forward strategy

빠른 속도로 분기 B를 분기 A로 결합합니다.
합병에 들어가면 합병 과정의 역사가 더욱 뚜렷해 보이지만, 합병이 무엇인지 영원히 알 수 없다는 단점도 있다. 합병의 제출은 기본 제시 이후에만 부가되고, 그 아버지의 지점에 대한 정보는 포함되지 않기 때문이다.그러나 일부 팀은 이것이 열세라고 생각하지 않는다. 그들은 사실상 빠른 합병을 추진할 것이다. 따라서 자주 rebase 합병을 해야 한다.

중요한 기초

Git 문서:

git-rebase - Re-apply commits on top of another base tip

rebase 작업의 용례는 다시 쓰기와 정리에 대한 생각과 관련이 있습니다.공통 목표는 다음과 같습니다.

분기를 main로 재설정하고 제출 기록을 다시 재생하여 분기의 최신 작업 업데이트 기능(테마) 분기를 사용합니다.

Rebase는 자주 사용되지 않거나 고급 장면에서도 유용합니다.

제출 역사를 역사의 다른 점으로 이동합니다.

이전 제출을 변경하기 위해 역사 기록을 다시 작성합니다.

병합과 베이스 작업은 다른 역사로 지점을 업데이트하는 데 사용할 수 있습니다.리베이스의 예에서 우리는 사실상 하나의 기점에서 기존 역사를 재기조했다.

git checkout A  # Could be "main", or "master"
git merge --ff B  # Hmmm no can do! B doesn't start after A
git checkout B  # Go back to B
git rebase A  # Reset to A then replay commits from B
git checkout A  # Let's try again
git merge --ff B  # Oh yeah

분기 B를 분기 A에서 베이스 주소를 재정의한 다음 빠른 속도로 분기 B를 분기 A로 결합합니다.
위의 그림은 기본 작업의 가장 흔히 볼 수 있는 용례를 보여 줍니다. 가능한 한 깨끗한 방식으로 최신 역사 업데이트 테마 지점을 사용합니다.그러나'가장 깨끗하다'는 것은 비슷하지만 서로 다른 제출 대상으로 역사를 다시 쓰는 것을 의미한다는 것을 주의하십시오.

Rebasing a branch will, invariably, rewrite its history.

앞에서 말한 바와 같이 일부 팀은 깨끗한 선형 제출 역사만 좋아할 뿐이다. 이것은 사람들에게 재정의 기반을 파악하고 진속 전략과 시종일관 융합하도록 요구할 것이다.누군가가 지점의 기초를 다시 설정해야 할 때마다, 위의 예는 그들이 지점을 합병할 준비가 될 때까지 반복된다.

git checkout B  # We already know we need a rebase
git rebase A  # Let's see...
# --- conflict resolution work on commit B2 ---
git add conflicting-file.txt  # Looks good now
git commit --amend  # Commit with the "amend" option to fixup B2
git rebase --continue  # Now we go
# --- conflict resolution work on commit B3 ---
git add another-conflicting-file.txt  # Ouch
git commit --amend  # Fixup B3
git rebase --continue  # Done

분기 B를 분기 A에서 기지를 재정립하여 B로부터 약속된 충돌을 해결한 다음 빠른 속도로 분기 B를 분기 A에 통합합니다.
충돌에 관해서, 재결정은 일반적으로 더 많은 작업을 필요로 한다. 왜냐하면 충돌은 제출 단계에서 해결해야 하기 때문이다.따라서 기초 지점에 변경이 도입되면 기초를 재설정하는 과정에서 충돌을 다시 해결해야 할 수도 있다.
기본 주소를 다시 정할 때 고려해야 할 또 다른 일은 다른 사람이 보낸 대상을 버리거나 다시 쓸 수 있다는 것이다. 일반적인 제출이든 충돌 해결 방안과 통합된 제출이든.이런 행위는 중대한 기반이 되지 않는 사람들의 작품을 방해하기 때문에 강력하게 반대한다.기지를 다시 설정하면 Git에서 지점이 원격 피어와 연결이 끊어진 것을 발견하면 지점에 경고해야 하기 때문에 지점을 강제로 밀어넣기main해야 원격으로 올릴 수 있다.

git checkout B  # Let's clean this up
git rebase A  # Reset to A then replay commits from B
git push remote B  # Upload rewritten history
# --- Branch A was updated by other people ---
git fetch remote  # Make sure to download the latest stuff
git rebase remote/A  # Reset to latest A then re-replay commits from B
git push remote B  # Oops it doesn't work, histories differ!
git push --force remote B  # Force-push branch B

분기 A에서 분기 B의 기본 주소를 재설정한 다음 분기 A에서 업데이트한 후 분기 A에서 분기 B의 기본 주소를 재설정합니다.
기록을 고려하면, 베이스 리셋 작업은 비교적 새로운 역사 기록을 사용하여 지점을 업데이트하는 이벤트를 무시합니다. 지점을 리셋하면 선형 제출 로그가 남기 때문입니다.

기본 주소 및 기본 주소 재정의

깨끗하고 선형적인 역사를 유지하기 위해 하나의 지점을 강제로 밀어붙인 후 Git에 대해 경험이 많지 않은 사용자는 일반적인 git push --force를 사용하여 지점의 최신 버전을 자신의 위로 끌어올려 혼란스럽고 필요로 하지 않는 합병 제출을 초래할 수 있다.이것은 클릭을 숨김 Git 명령으로 바꾸는 그래픽 사용자 인터페이스에서 특히 흔히 볼 수 있다.

Merge remote-tracking branch 'origin/feature-x' into feature-x

이러한 상황을 방지하기 위해서 git pull 분기를 원격 상태로 초기화한 다음, 그 위에 업데이트된 제출을 다시 적용합니다. 이것은 보통 최초의 의도입니다.이 비헤이비어는 Git configuration에서 기본 비헤이비어로 설정할 수 있습니다.

git config --global pull.rebase true

나 어떡하지?

이것은 당신의 목표가 무엇인지, 그리고 팀이 무엇을 동의하는지에 달려 있다.간단히 말하면:

합병은 합병 역사에 가장 적합하며 지루함과 간단함을 유지하기에 적합하다.그것은 또한 충돌 해결과 사건을 기록하는 데 도움이 된다. 예를 들어 지난주 화요일에 상위권에서 나의 지점을 갱신했다.

원격 서버가 여전히 어떤 지점을 모르거나 어떤 이유로 역사 기록을 다시 써야 할 때 터미널을 다시 정하는 것이 관리 작업에 가장 적합하다.

일반적으로 이 모든 것은 팀이 Git를 사용한 경험과 모든 사람들이 자신의 공헌이 하나의 공통된 목표에 모이는 것을 보고 싶어 하는 것으로 귀결된다.