[iOS 사전캠프] Git: Branching

DoyleHWorks·2024년 10월 16일

iOS 문법을 공부하는 것도 좋은데, 그보다도 먼저 Git에 익숙해지고 싶다.
iOS 문법은 문제를 해결하며 공부해도 좋지만 Git은 당장 팀원들과의 협업을 위해 중요하겠다는 생각 때문이다.
구글링을 해보니 https://learngitbranching.js.org/ 라는 사이트를 발견했다. 인터랙티브한 공부를 할 수 있는 사이트 같아서 당장 해보았다. 우측 하단의 언어 버튼을 누르면 한글도 지원되지만 놓치는 게 있을까봐 일단 영어로 공부했다.

아래 내용은 사이트에서 다음 레벨에 해당하는 내용이다.

  • Introduction Sequence (1~4) level intro<num>
    • Introduction to Git commits
    • Branching in Git
    • Merging in Git
    • Rebase Introduction
  • Ramping Up (1~3) level rampup<num>
    • Detach yo' HEAD
    • Relative Refs #1 (^)
    • Relative Refs #2 (~)

Git Branching

Introduction to Git Commits

  • git commit -m "커밋 메시지"
    • 현재 작업 디렉토리에서 스테이징된 파일들의 변경 사항을 커밋한다.
    • 커밋 전에 git add를 통해 수정된 파일들을 스테이징해야 한다.
  • git branch {branch name} {ref}
    • 새로운 브랜치를 만든다. 다만 그 브랜치로 이동하지는 않는다.
    • {ref} 없으면 제자리에 만듦
    • 브랜치를 생성 후 동시에 그 브랜치로 이동하려면 아래 명령어를 사용한다.
      • git checkout -b {branch name}
      • git switch -c {branch name}
    • git branch -f {branch name} {relative ref}
      • 지정한 브랜치를 {relative ref} 위치에 강제로 재할당한다.
      • 예) git branch -f main HEAD~3: HEAD 위로 세번째 부모인 커밋에 main 브랜치를 강제로 이동함 (실제 git 환경에서는 git branch -f command는 현재 브랜치에서 불가능함)
  • git checkout {branch name}
    • 지정한 브랜치로 전환한다. 해당 브랜치에 있는 파일들로 작업 디렉토리가 바뀐다.
    • Git 2.23 이상부터는 git switch {brtanch name}으로도 전환 가능하다.
  • git merge {branch name}
    • 현재 브랜치에 {branch name}의 변경 사항을 병합한다.
    • 현재 브랜치는 보통 병합하려는 대상 브랜치가 된다.
    • 병합 시 충돌(conflict)이 발생할 수 있으며, 이를 수동으로 해결해야 한다.
  • git rebase {branch name}
    • 현재 브랜치의 커밋 기록을 지정한 {branch name}으로 두고 재정렬한다.
    • 커밋 히스토리가 깔끔해지는 효과가 있다.
    • rebase는 기존의 커밋 기록을 수정할 수 있기 때문에, 공개된 브랜치에서는 신중하게 사용해야 한다. 특히 협업 중에는 충돌 해결이 더 복잡해질 수 있다.

HEAD, Relative Refs

  • HEAD
    • 현재 작업 중인 브랜치를 가리키는 포인터
    • HEAD가 가리키는 위치는 이동할 수 있다. 다른 브랜치로 이동하거나 특정 커밋으로 체크아웃하면 HEAD도 그 위치로 이동한다.
    • Detached HEAD: 특정 커밋이나 태그로 이동할 때 HEAD가 특정 브랜치가 아닌 커밋 그 자체를 가리킨다. 이 상태를 Detached HEAD라 한다. 이 상태에서는 새로운 커밋을 만들어도 기존 브랜치에 연결되지 않으며, 브랜치를 새로 만들지 않으면 작업이 저장되지 않을 수 있다.
  • git log
    • 커밋 히스토리를 확인하는 명령어
    • 프로젝트의 커밋 내역을 확인할 수 있음
    • 각 커밋의 메타 정보(커밋 해시, 작성자, 날짜, 커밋 메시지 등)도 함께 볼 수 있음
    • git log --oneline: 커밋 해시의 앞부분과 커밋 메시지만 간단하게 출력
    • git log --graph: 커밋 히스토리를 트리 형태로 시각화하여 브랜치 병합이나 분기를 볼 수 있음
    • git log --author="이름"특정 작성자의 커밋만 필터링해 볼 수 있음
    • git log --since="2024-01-01" --until"2024-10-16": 특정 기간 내의 커밋만 보여줌
    • git log --stat: 각 커밋에서 변경된 파일과 수정된 라인의 수를 함께 보여줌
    • git log -p: 각 커밋에서 실재로 어떤 코드가 변경되었는지 보여줌 (패치 형식)
  • 커밋 해시 형태
    • fed2da64c0efc5293610bdd892f82a58e8cbc5d8와 같이 복잡하지만, fed2만 쳐도 잘 인식함
  • Relative Refs
    • 특정 커밋을 해쉬로 찾는 것은 쉽지 않으니, relative refs라는 개념을 사용한다.
    • Caret(^) 연산자로 한 커밋씩 위로 올라갈 수 있다. (e.g. main^, main^^, HEAD^)
      • ^<num>을 붙이면 부모가 여러 커밋일 때 (특히 병합 커밋) 몇 번째 부모를 선택할지 고를 수 있다.
    • Tilde(~<num>) 연산자로 일정 수 만큼 위로 올라갈 수 있다. (e.g. HEAD~4)
profile
Reciprocity lies in knowing enough

0개의 댓글