병합 대 리베이스: 그래프로 선택

• 동일한 복사본에서 병합 및 리베이스를 시작하면 비교가 공정해집니다.
• 병합 커밋의 두 상위 커밋과 리베이스 커밋의 단일 새 상위를 읽습니다.
• 두 개의 복사본이 동일한 파일로 끝나면서도 여전히 다른 기록을 가질 수 있는 이유를 설명하십시오.
• 하나의 규칙으로 선택하세요. 다른 사람이 갖고 있지 않은 커밋만 다시 작성하세요.

gittree-merge 및 gittree-rebase라는 20과의 분기에 대한 두 개의 별도 복사본이 필요합니다. 각 복사본에서 feature/signup-form 브랜치에는 하나의 커밋(S라고 함)이 있고, updated-main 브랜치는 하나의 다른 커밋(N이라고 함)이 있으며 둘 다 동일한 커밋 M에서 시작되었으며 rescue/signup-before-rebase는 S를 가리킵니다. 주제 브랜치가 체크아웃되고 작업 트리가 깨끗해졌습니다. 첫 번째 결과에서 두 번째 복사본을 만들지 마십시오.

여기에 있는 모든 것은 로컬이며 무료 요금제(GitTree에서 로그인을 요청함)입니다. 호스팅 계정도, 공급자도, 인터넷도 없습니다. 모든 신원은 허구이며(example.com) 실제 프로젝트 내에서 이 강의를 실행해서는 안 됩니다.

동일한 사본에서 둘 다 수행하지 말고 GitTree 또는 기본 Git 명령을 사용하여 변경하십시오. 나중에 결과를 읽는 것은 항상 안전합니다. 메뉴 라벨은 GitTree 2.0 자체 문자열에서 나옵니다. 기본 명령은 일회용 복사본에서 Git 2.43을 사용하여 실행되었습니다. GitTree 단계는 macOS, Windows 또는 Linux에서 실행되지 않았습니다. 앱의 바로가기는 이 페이지에서 Ctrl을 쓰는 macOS의 Command를 사용합니다.

비교는 두 사본이 모두 동일한 참조 및 동일한 파일에서 시작되는 경우에만 공정합니다. 먼저 병합한 다음 그 결과를 리베이스하면 다른 질문을 하게 됩니다. 이제 재생의 해당 범위에 병합 커밋이 있습니다.

Merge는 두 작업 라인을 모두 유지합니다. 두 개의 상위 커밋인 S를 먼저 추가하고 N을 추가합니다. S와 N은 ID를 유지합니다.

Rebase는 N 위에 커밋을 재생합니다. 결과 S′에는 S와 변경 사항이 동일하지만 새 상위 항목이 있고 커밋 ID에 상위 항목이 포함되므로 S′에는 새 ID가 있습니다. 오래된 S는 구조 지점이 여전히 그것을 가리키고 있기 때문에 살아남습니다.

충돌하는 항목이 없으면 두 복사본 모두 동일한 파일 트리로 끝납니다. 동일한 트리는 동일한 기록을 의미하지 않습니다. 한 그래프는 다이아몬드 모양을 유지하고 다른 그래프는 직선을 유지하며 커밋 ID는 다릅니다.

어느 것이 옳은지는 취향의 문제가 아닙니다. 다른 사람이 이미 커밋을 갖고 있는 경우 이를 재생하면 복사본이 손상되므로 병합하세요. 커밋이 비공개인 경우 리베이스는 안전하며 팀이 원하는 경우 선형 기록을 제공합니다. 어느 쪽도 코드를 더 좋게 만들지 않습니다.

각 사본에서는 주제 분기만 이동합니다. 서버, updated-main 및 원래 기본 서버는 건드리지 않습니다.

하나의 발산을 만든 다음 두 번 복사합니다. 18과에서 남긴 프로젝트의 별도의 일반 복사본에서 시작합니다(기본은 병합 커밋 M입니다). 원본 gittree-features을(를) 그대로 두고 소스 체크아웃에서 실행하지 마세요. 데모 ID는 GitTree Demo(demo@example.com)이며 이 저장소에서만 서명이 해제되어 있습니다.

아래에 명명된 단계에서만 저장하십시오. 이는 최종 개행 문자가 포함된 완전한 UTF-8/LF 본문입니다. 마크다운 펜스를 붙여넣지 마세요. 변경되지 않은 실행 가능 파일은 명명된 입력을 상속합니다. 별도의 변형 버전이 원본을 덮어쓰면 안 됩니다.

index.html — 가입

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>GitTree Features — course demo</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main" tabindex="-1">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">See your work clearly.</h1>
      <p id="hero-copy">Choose one change, then check what Git saved.</p>
    </section>
    <section class="features" aria-labelledby="features-title">
      <h2 id="features-title">Follow your work</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>History</h3>
          <p>Read commits and branches together.</p>
        </article>
        <article class="feature-card">
          <h3>Changes</h3>
          <p>Review the exact content selected for a commit.</p>
        </article>
        <article class="feature-card">
          <h3>Recovery</h3>
          <p>Inspect the scope of a recovery point before using it.</p>
        </article>
      </div>
    </section>
    <section aria-labelledby="plans-title">
      <h2 id="plans-title">Choose the workflow you need</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>Local Git</h3>
          <p>Local Git workflows work without signing in.</p>
        </article>
        <article class="feature-card">
          <h3>Connected workflows</h3>
          <p>Provider integrations and Nour require Pro or an applicable trial.</p>
        </article>
      </div>
    </section>
    <section aria-labelledby="signup-title">
      <h2 id="signup-title">Try the demo form</h2>
      <form id="signup-form" novalidate>
        <label for="demo-email">Demo email</label>
        <input id="demo-email" name="email" type="email" autocomplete="off" aria-describedby="signup-hint">
        <p id="signup-hint">Use a fictional example.com address. Nothing is sent.</p>
        <button type="submit">Check the address locally</button>
        <p id="signup-result" role="status"></p>
      </form>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn. Review one change at a time.</p></footer>
  <script type="module" src="site.js"></script>
</body>
</html>

docs/integration-note.md — DOC_MERGE

# Integration review

This note was written on main while signup work was private.

Command+Shift+P(Ubuntu에서는 Ctrl+Shift+P)로 팔레트를 열고 정확한 명령 이름을 입력한 후 선택하세요. 명명된 분기에 대한 작업은 해당 분기의 오른쪽 클릭 메뉴를 사용합니다.

1. gittree-merge을(를) 엽니다. 그런 다음 New Tab을 선택하고 Recent 목록에서 gittree-rebase을 엽니다. 각 탭의 제목은 폴더 이름으로 지정되므로 두 탭을 구분할 수 있습니다.
2. gittree-merge 탭에서 feature/signup-form을(를) 체크아웃 상태로 유지하세요. updated-main을 마우스 오른쪽 버튼으로 클릭하고 Merge updated-main into feature/signup-form을 선택합니다.
3. Record it as에서 Always a merge commit을 선택한 후 Merge를 한 번 선택합니다. 새 커밋에는 두 개의 부모가 있습니다: 먼저 S, 그 다음 N입니다.
4. gittree-rebase 탭으로 전환하세요. 저장한 그대로 여전히 S와 N에 있습니다. 병합 사본을 사용하지 마십시오.
5. updated-main을(를) 마우스 오른쪽 버튼으로 클릭하고 Rebase feature/signup-form onto updated-main을(를) 선택합니다. Options for this rebase을 읽고 두 옵션을 모두 해제한 다음 Rebase feature/signup-form을 한 번 선택하세요.
6. 재생된 커밋을 선택합니다. 해당 부모는 N이고 ID는 새 것입니다. 이전 S의 이름은 여전히 ​​rescue/signup-before-rebase에 의해 지정됩니다.
7. 각 탭에서 Show Files → index.html 및 docs/integration-note.md을 엽니다. 두 사본 모두에서 동일한 페이지와 동일한 메모입니다. 그런 다음 Back to Graph을(를) 사용하여 반환하세요.
8. 두 그래프를 비교한 다음 결과를 선택하기 전에 어떤 규칙이 이 분기에 대한 선택을 결정하는지 말해보세요. 두 사본을 모두 그대로 유지하십시오.

과정의 모든 일반적인 커밋에 대해: Summary는 명시된 주제이고, Description는 비어 있으며, 옵션 Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit 및 Allow Empty Commit는 꺼져 있습니다. 이 강의에서는 일반적인 커밋을 수행하지 않습니다.

18과 결과(앱에서 수행한 작업, 기본 명령으로 작성된 작업)의 별도의 깨끗한 복사본에서 분기를 구축합니다.

git switch --create feature/signup-form

전체 가입 페이지를 index.html로 저장한 후 다음을 수행하세요.

git add -- index.html
git commit --quiet -m "feat: add the local signup demonstration"
git branch rescue/signup-before-rebase
BASE_SHA="$(git rev-parse HEAD~1)"
git switch --quiet --create updated-main "$BASE_SHA"

updated-main에 전체 DOC_MERGE 메모를 docs/integration-note.md로 저장한 후 다음을 수행합니다.

git add -- docs/integration-note.md
git commit --quiet -m "docs: add the integration review"
git switch --quiet feature/signup-form

BASE_SHA은 두 줄이 모두 성장하는 커밋 M입니다. 이제 이 정확한 상태(cd .. && cp -R gittree-features gittree-merge && cp -R gittree-features gittree-rebase)에서 두 개의 독립적인 복사본을 만듭니다. 병합 사본에서:

git merge --quiet --no-ff --no-edit updated-main
git rev-list --parents -n 1 HEAD
git rev-parse 'HEAD^{tree}'
git status --short

손대지 않은 리베이스 복사본에서:

git rebase --quiet --no-autostash --no-update-refs --no-autosquash updated-main
git rev-list --parents -n 1 HEAD
git rev-parse 'HEAD^{tree}'
git status --short

git rev-list --parents -n 1 HEAD는 커밋의 ID와 그 상위 항목(병합 복사본의 ID 3개, 리베이스 복사본의 ID 2개)을 인쇄합니다. 두 개의 HEAD^{tree} 줄은 동일한 ID이고 git status --short는 둘 다 아무것도 인쇄하지 않습니다. 두 개의 HEAD 커밋 ID가 다릅니다. 귀하의 ID는 다른 사람의 ID와 다릅니다. 이 페이지가 아닌 서로 비교하십시오.

주제에 자체 커밋이 없고 updated-main이 단순히 그보다 앞에 있는 경우 git merge는 기본적으로 빨리 감기하고 병합 커밋을 생성하지 않습니다. 그것은 다른 입력과 다른 결과입니다. 의도적으로 선택하고 두 부모 병합을 위조하지 마십시오.

Where you end: 병합 복사본에는 상위 S 및 N이 있는 새로운 커밋 K가 있습니다. 리베이스 복사본에는 상위 N과 함께 S'가 있고 이전 S는 복구 분기에 의해 유지됩니다. 파일 트리는 동일하고 두 상태 모두 깨끗하며 원래 기본, M 및 서버는 그대로 유지됩니다.

• 직선 그래프를 가정하면 이전 커밋 ID가 살아 남았음을 의미합니다. 리베이스는 항상 새로운 커밋을 생성합니다.
• 병합 결과에서 리베이스를 시작합니다. 이는 다른 실험이며 재생에는 병합 커밋이 포함될 수 있습니다.
• 두 개의 HEAD ID를 비교하고 일치할 것으로 예상합니다. 대신 나무를 비교해 보세요.
• 이미 완료된 후에 병합 또는 리베이스를 반복합니다.

결과를 강제로 일치시키기 위해 결과를 삭제하지 마십시오. 트리가 다른 경우 시작 참조, 충돌 해결 및 추가 커밋을 비교한 다음 저장된 분기에서 다시 시작합니다. 구조 지점은 커밋된 기록만 보관합니다. 커밋되지 않은 파일은 보관되지 않습니다.

각 질문에 답한 후 그 이유를 읽어보세요. '필수'라고 표시된 질문은 수업 완료에 반영됩니다.

1. 질문 1/6

   질문 1/6

   동일한 시작부터 하나의 복사본에서 updated-main을 feature/signup-form로 병합하고 다른 복사본에서는 feature/signup-form를 updated-main로 리베이스합니다. 해당 주제의 새 팁 커밋에는 각 복사본에 몇 개의 상위 항목이 있습니까?

   답을 하나 선택하세요.

   두 사본 모두: 2개.

   두 사본 모두: 하나.

   병합 사본: 2개. 리베이스 복사본: 1개.

   병합 사본: 1개. 리베이스 복사본: 2개.

   답변 확인
2. 질문 2/6

   질문 2/6

   병합과 리베이스가 충돌 없이 완료된 후 두 복사본에서 동일한 것은 무엇입니까?

   해당하는 답을 모두 선택하세요.

   주제 브랜치가 시작된 커밋

   팁 커밋의 파일 트리

   팁 커밋의 ID

   docs/integration-note.md의 내용

   답변 확인
3. 질문 3/6

   질문 3/6필수

   리베이스 후에 원래 주제 커밋 S는 어떻게 되었나요?

   답을 하나 선택하세요.

   새로운 ID를 가진 새로운 커밋 S'가 생성되었습니다. 이전 S는 구조 분기를 통해서만 접근할 수 있습니다.

   S는 ID를 유지하고 부모만 변경했습니다.

   S는 즉시 저장소에서 삭제되었습니다.

   S가 서버로 푸시되었습니다.

   답변 확인
4. 질문 4/6

   질문 4/6

   입력을 변경하세요. 주제에 자체 커밋이 없으며 updated-main이(가) 단순히 그보다 앞서 있습니다. 기본 모드인 "가능하면 빨리 감기, 그렇지 않으면 병합 커밋"으로 병합합니다. 무슨 일이 일어나나요?

   답을 하나 선택하세요.

   Git은 분기가 분기되지 않았기 때문에 거부합니다.

   두 상위 요소가 포함된 병합 커밋은 항상 생성됩니다.

   분기 레이블이 앞으로 이동하고 병합 커밋이 생성되지 않습니다.

   모든 커밋은 새 ID로 다시 작성됩니다.

   답변 확인
5. 질문 5/6

   질문 5/6필수

   동료가 이미 feature/signup-form을(를) 가져와 이를 기반으로 구축 중입니다. main 기록을 깔끔하게 유지하고 싶습니다. 안전한 선택은 무엇입니까?

   답을 하나 선택하세요.

   직선 그래프가 더 깔끔하기 때문에 리베이스하고 강제 푸시하세요.

   해당 브랜치를 삭제하고 같은 이름으로 다시 생성하세요.

   updated-main을(를) 브랜치에 병합하면 커밋에서 ID가 유지됩니다.

   분기를 updated-main으로 재설정합니다.

   답변 확인
6. 질문 6/6

   질문 6/6필수

   어떤 판독 결과가 비교가 공정했고 어떻게 끝났는지 보여주나요?

   해당하는 답을 모두 선택하세요.

   시작하기 전에 두 사본의 S와 N이 동일했습니다.

   git rev-parse HEAD^{tree}는 두 복사본 모두에서 동일한 ID를 인쇄합니다.

   git rev-list --parents -n 1 HEAD는 병합 복사본에 대한 3개의 ID와 리베이스 복사본에 대한 2개의 ID를 인쇄합니다.

   git rev-parse HEAD는 두 복사본 모두에서 동일한 ID를 인쇄합니다.

   답변 확인

두 개의 상위 목록, 두 개의 HEAD ID 및 두 개의 트리 ID를 보고합니다. 서로 다른 HEAD ID 옆에 동일한 트리 ID가 예상되는 결과인 이유를 설명하세요. 그런 다음 이를 수행하지 않고 주제에 자체 커밋이 없을 때 기본 병합이 수행하는 작업을 예측합니다.

• 같은 시작, 다른 역사.
• 평등한 나무가 평등한 역사를 의미하는 것은 아니다.
• 다른 사람이 커밋을 하면 병합하세요. 비공개 항목만 리베이스하세요.

• 분기된 기록이 있는 분기 병합(18과)
• 빨리 감기 병합 이해(강의 19)
• 미출판 저작물을 새 기반으로 리베이스함(강의 20)
• GUI의 대화형 리베이스
• GitTree 다운로드

리베이스 - إعادة تاسيس; 재생 - إعادة تصبيق; 구조 지점 — froع حبظ.