집단 개발한 Git는 개발 지점에서 master를 찾을 때 rebase를 사용할 수 없습니까?

왜 이 기사를 썼어요?

최근 사업을 시작하여 처음으로 Git를 집단 개발에서 접하게 되었다.
그래서 나는 즉시 이력서를 망가뜨렸다...
발표된 개발 지점에서 마스터 업데이트를 가져올 때 다음 절차를 수행했습니다.

git checkout master
git pull
git checkout feature
git rebase master
git push -f origin feature

예, GitHub에 표시되는 업데이트 내역은 엉망입니다.
조사해 보니 원격으로 주는 지점이 위험한데 왜 위험한지 알아보기로 했어요.
가장 명확한 것은 정부의 문서다.
Git 분기 기능 - 베이스의, 사실은 무서운 리베스 종목이다.이렇게 되면 나는push가 제출한 다른 사람들의 이력서가 엉망진창으로 변할 수 있다는 것을 알게 되었다.
하지만 신기하기도 하다.
나push의 개발 지점은 나만 건드린다.다른 사람이 가입하지 않았다.하지만 rebase push를 하면 그때 GitHub의 이력이 엉망진창이 된다.나는 이 점에 대해 설명이 없다고 생각한다.
그래서 나는 실제 개발된rebase를 구상하는 실험을 해 보고 싶다.

실험 방침

git rebase git push-f 하면 어떻게 되는 거예요?의 방법을 참고했다.
우선,remote 저장소repos.준비
그리고 거기서 제인과 존이라는 개발용 자료고를 복제해서 만들었어요.
그리고 제인과 존은 각각 마스터에서 개발 지점을 잘라내고 각자 약속을 쌓아 중도에서라도remote에서push 각자의 지점을 만들 것이다.
이번 구상은 제인의 개발이 더 일찍 끝났고, 제인은 먼저 마스터에 합병되었다.그리고 존은 리베이스로 마스터를 가져와 자신의 개발 지점이merge 없이remotepush에 의해 이런 상황을 재현했다.
이때,repos.git의 지점은 어떻게 됩니까?그거 확인하고 싶어요.

실험 프로그램

자세한 단계는 다음과 같습니다.

$ cd /tmp
$ (mkdir repos.git && cd repos.git && git init --bare)
$ git clone repos.git/ Jane
$ git clone repos.git/ John
# repos.gitは直接いじれないので、まずJaneでファーストコミットを作りremoteとJohnに同期させる
$ cd Jane/
$ git commit --allow-empty -m "init"
$ git push
$ cd ../John/
$ git pull
# 次にJaneで開発リポジトリbranchAにコミットを積み、remoteにpushする
$ cd ../Jane/
$ git checkout -b branchA
$ git commit --allow-empty -m "firstA"
$ git commit --allow-empty -m "secondA"
$ git push origin branchA
# 次にJohnで開発リポジトリbranchBにコミットを積み、remoteにpushする
$ cd ../John/
$ git checkout -b branchB
$ git commit --allow-empty -m "firstB"
$ git commit --allow-empty -m "secondB"
$ git commit --allow-empty -m "thirdB"
$ git push origin branchB

이 리모트 저장소는 다음과 같습니다.

$ cd ../repos.git/
$ git show-branch
! [branchA] secondA
 ! [branchB] thirdB
  * [master] init
---
 +  [branchB] thirdB
 +  [branchB^] secondB
 +  [branchB~2] firstB
+   [branchA] secondA
+   [branchA^] firstA
++* [master] init

계속

# Janeの開発ブランチをmasterにmergeしてremoteにpushします
$ cd ../Jane/
$ git checkout master
$ git merge branchA
$ git branch -d branchA
$ git push origin master
$ cd ../repos.git/
$ git branch -d branchA
# Johnの手元のmasterに先ほどmergeしたmasterを取り込みます
$ cd ../John/
$ git checkout master
$ git pull origin master
# そして開発ブランチに移動し、masterをrebaseします
$ git checkout branchB
$ git rebase --keep-empty master

이때 John의 저장소는 다음과 같습니다.

$ git show-branch
* [branchB] thirdB
 ! [master] secondA
--
*  [branchB] thirdB
*  [branchB^] secondB
*  [branchB~2] firstB
*+ [master] secondA
$ git show-branch --sha1-name
* [branchB] thirdB
 ! [master] secondA
--
*  [e476307] thirdB
*  [f529fc5] secondB
*  [25159d5] firstB
*+ [d2ad4cc] secondA

혼란 없이 리베이스에 잘 걸려.
또한remote 저장소는 다음과 같습니다.

$ cd ../repos.git/
$ git show-branch --sha1-name
! [branchB] thirdB
 * [master] secondA
--
+  [bf7bb97] thirdB
+  [4ab5a72] secondB
+  [165ca53] firstB
 * [d2ad4cc] secondA
 * [d0f004a] firstA
+* [207fe15] init

따라서 push -f.

$ cd ../John/
# 念の為開発ブランチにいることを確認しておきます
$ git branch
* branchB
  master
$ git push -f origin branchB

그럼 어떻게 될까요?
이번에는 리모트와 로컬을 함께 보기로 했습니다.

$ git show-branch -a --sha1-name
* [branchB] thirdB
 ! [master] secondA
  ! [origin/branchB] thirdB
   ! [origin/master] secondA
----
* +  [e476307] thirdB
* +  [f529fc5] secondB
* +  [25159d5] firstB
*+++ [d2ad4cc] secondA

이것을 보니, 리모트도 혼란스럽지 않게 리모트되어 보인다.
정상적인 상황git log에서도 제출 순서에 따라 혼란이 일어나지 않는다.

$ git log
commit e4763074f5a508cdc9470d406ce63c693db62858 (HEAD -> branchB, origin/branchB)
Author: rotelstift <[email protected]>
Date:   Wed Sep 4 18:46:28 2019 +0900

    thirdB

commit f529fc50f97cf57b776127bf44aaba2623df531a
Author: rotelstift <[email protected]>
Date:   Wed Sep 4 18:46:20 2019 +0900

    secondB

commit 25159d52ad933d8f3308e1240caf83461d79adf7
Author: rotelstift <[email protected]>
Date:   Wed Sep 4 18:46:14 2019 +0900

    firstB

commit d2ad4cccd5c9586d4ee73283f59343211ca9ca19 (origin/master, master)
Author: rotelstift <[email protected]>
Date:   Wed Sep 4 18:44:53 2019 +0900

    secondA

commit d0f004a2d17414005a0c4e786d0f31e1c028dd86
Author: rotelstift <[email protected]>
Date:   Wed Sep 4 18:44:40 2019 +0900

    firstA

commit 207fe1529b72bebc78e17160e89d369cdb3c4282
Author: rotelstift <[email protected]>
Date:   Wed Sep 4 18:43:12 2019 +0900

    init

이 실험의 절차와 결과는 아래와 같다.

그러면 GitHub의 혼란은 뭘까요?

GitHub 도움말 페이지에 명확한 답변이 있습니다.
　 왜 제출 순서가 틀렸습니까?
재시작 실행 중에 Git 제출 기록을 다시 작성하면 시간 연속체가 변경됩니다.즉, GitHub 인터페이스가 예상한 대로 커밋되지 않을 수 있습니다.
따라서 GitHub의 제출 순서 혼란은 Git도 재현할 수 있는 것이 아니다.

총결산

master를 개발 지점에 도입할 때 rebase를 사용하면 GitHub에 표시된 역사가 엉망진창으로 변한다.

만약에 여러 명이 개발할 때push의 제출을 완료하고rebase를 진행했다면,rebase 전부터 이 제출을 도입한 사람의 이력은 매우 복잡해진다.

push의 제출에 대해rebase 자체가 역사를 파괴하지 않습니다.

그러나 1, 2의 단점이 매우 커서push가 완성한 제출을rebase할 수 없습니다.