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


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

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

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

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

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

//Test Code 입력 후 커밋(test branch의 첫 변경 이력)

네비게이터의 우측 U는 로컬의 변경 사항이 아직 Remote에 반영되지 않았다는 의미
즉 Push를 통해 올려줘야 한다.

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

rebase의 강력함을 이해하기 위해서는 브랜치를 약간 엉망?으로 만들 필요가 있다.
사실, 브랜치에서 작업 중 Main에 다른 동료가 Push → Merge한 케이스는 협업에서 매우 흔하다.
현재 Push를 안 해서 원격 저장소에 반영이 안 된 것을 알 수 있다. → Push 진행

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


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



Fork(GUI)에서 그래프 확인

cc1b7fb와 96dcea0의 Snapshot에 차이가 발생했고 이를 Conflict라고 한다.Conflict는 겁먹을 필요는 없고, merge 또는 rabase를 통해서 Main으로 Conflict를 해결하고 병합해주면 된다.merge 시 커밋 그래프 확인
우선 바로 merge 시켜 보겠다.
지금은 브랜치의 숫자가 적어서 지저분해 보이지 않으나…

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

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

이후 Test 브랜치를 삭제하면 깔끔하게 Main 브랜치의 커밋 히스토리를 관리할 수 있다.
Commit 찍는 용도로 사용한다.Checkout, Pull, Push 등의 기능은 Fork(GUI)를 활용한다.
Rebase한다는 의미는 B의 마지막 커밋을 Base로 한 후 브랜치를 병합하는 것이다.