[Git]Rebase를 통한 커밋 이력 관리 + Xcode

GUI 다운로드

• Fork 다운로드 링크

Xcode 프로젝트에 Repo 생성 후 Github에 연결

1. Xcode에서 샘플 프로젝트 생성 후 Integrate → New Git Repository → Create

2. 좌측 상단에 Source Control navigator 클릭 → Remote → New “{프로젝트 명}” Remote..
• 프로젝트에 생성된 Git Repo을 Remote 환경(Github)에 올리는 작업
• Git Repo는 프로젝트의 변경 사항을 기록(Commit)하고 프로젝트의 현재 상태를 관리하는 저장소
• 결국 관리를 위해서 기록이 필요하고 이를 Commit이라는 명령어가 실행
• Commit은 Snapshot 방식으로 변경 내역만 저장하고(전체 파일 저장 X), Head라는 포인터가 현재 프로젝트에서 보여지는 Commit을 알려준다.

Branch 생성 후 커밋 기록

1. Main을 기준으로 New Branch from “Main” 클릭

2. feature/ {브랜치명} 입력
• 이때 브랜치명에는 관례적으로 소문자, - 만 사용한다.
• ‘feature/’ 는 feature라는 디렉토리를 생성해 브랜치 들을 묶어서 관리하기 위함이다.

• 이후 자동으로 switch(브랜치 이동)되어 생성한 브랜치로 이동했다.

• main: 기본 브랜치, feature/test-set-project : 생성한 브랜치

 
1. //Test Code 입력 후 커밋(test branch의 첫 변경 이력)
• 네비게이터의 우측 U는 로컬의 변경 사항이 아직 Remote에 반영되지 않았다는 의미
• 즉 Push를 통해 올려줘야 한다.

• 커밋을 2개 정도 더 찍어준다

 

Main branch에 커밋 추가

• rebase의 강력함을 이해하기 위해서는 브랜치를 약간 엉망?으로 만들 필요가 있다.

• 사실, 브랜치에서 작업 중 Main에 다른 동료가 Push → Merge한 케이스는 협업에서 매우 흔하다.

• 현재 Push를 안 해서 원격 저장소에 반영이 안 된 것을 알 수 있다. → Push 진행

• Push 후 고양이가 올라간 것을 확인 → Remote가 local의 변경 사항을 반영했다는 의미

1. 본격 브랜치 망치기 시작, Main으로 switch 후 커밋 추가(2개 정도 진행)







 

2. Fork(GUI)에서 그래프 확인



• Main 브랜치에서 커밋을 진행하기 전, 하나의 그래프로 기록되었던 그래프가 나뉜 것을 확인 할 수 있다.
• 이는 Main 브랜치의 내용에 변경 사항이 생기면서 cc1b7fb와 96dcea0의 Snapshot에 차이가 발생했고 이를 Conflict라고 한다.
• Conflict는 겁먹을 필요는 없고, merge 또는 rabase를 통해서 Main으로 Conflict를 해결하고 병합해주면 된다.
 
1. merge 시 커밋 그래프 확인
• 우선 바로 merge 시켜 보겠다.
• 지금은 브랜치의 숫자가 적어서 지저분해 보이지 않으나…

• 나중에는 이렇게 된다. ?@?

• 따라서, 커밋 이력을 말끔하게 정리하기 위해 rebase를 이용한다.
• rebase란 ‘branch의 base를 main으로 다시 다시 조정한다는 의미’이다.
• 이를 통해 선형적인 commit history를 관리할 수 있다.
 
1. rebase 실행
• Test branch의 커밋 이력이 Main의 커밋 히스토리(ef30c31)로 base를 잡은 것을 알 수 있다.

• 이후 Test 브랜치를 삭제하면 깔끔하게 Main 브랜치의 커밋 히스토리를 관리할 수 있다.

---

요약

• Xcode는 간단하게 Commit 찍는 용도로 사용한다.
• 히스토리 확인, Checkout, Pull, Push 등의 기능은 Fork(GUI)를 활용한다.
• Xcode의 경우 그래프를 확인할 수 없으며, 변경 사항에 대한 히스토리 업데이트 또한 즉각적이지 않다.(예를 들어, 방금 찍은 Commit을 확인하기 위해 히스토리를 보아도 방금 찍은 커밋은 없고 껐켰 한번 해야지 반영된다.)
• A를 B에 Rebase한다는 의미는 B의 마지막 커밋을 Base로 한 후 브랜치를 병합하는 것이다.
• 커밋 히스토리를 선형적으로 깔끔하게 관리하는데 그 목적이 있다.