[iOS 사전캠프] Git: Branching

DoyleHWorks·2024년 10월 16일
0

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개의 댓글