Hacker News 의견
  • 브랜치는 커밋을 가리키는 포인터이며, 새로운 커밋이 생성될 때마다 이 포인터가 갱신됨. 브랜치는 태그처럼 떠돌아다니는 이름이라고 볼 수 있음. 커밋 자체가 부모 커밋을 가리키기 때문에 브랜치라는 것은 관련 커밋들의 연쇄로, 명명된 진입점을 가짐. 브랜치를 삭제하면 더 이상 명명된 레이블이 없어져서, 단순히 관련 커밋들의 연쇄로만 남게 됨.
  • 커밋의 계보를 '앞으로'가 아닌 '뒤로' 가리키는 포인터로 생각하면 이해하기 쉬움. 브랜치는 커밋 ID이므로 부모 링크를 거슬러 올라가면 해당 브랜치의 전체 역사를 찾을 수 있음. '브랜치 포인트'는 두 커밋 체인이 만나는 지점이며, 병합 커밋은 특별한데, 이는 두 역사가 하나로 합쳐졌음을 나타냄.
  • 개인적인 프로젝트에서 git reset --hardgit stash를 사용하여 변경 사항과 브랜치 포인터를 조작하는 것을 친구들이 보면 화를 내곤 함. 잘못된 병합을 취소하려면 git reset --hard <병합 전 마지막 커밋>을 사용하고, 로컬 브랜치의 작은 수정 사항을 메인 브랜치에 적용하려면 git stash를 사용한 후 메인 브랜치로 체크아웃하여 git stash apply를 사용함.
  • Git에는 'main이 특별하다'는 개념이 없지만, Gitlab과 같은 도구들은 보호된 브랜치 기능을 제공하여 실수를 줄일 수 있음. '부모'와 '자식' 브랜치 개념이 실제로 흥미로울 수 있으며, 장기 지원 브랜치를 위해 여러 '부모' 브랜치를 지원해야 함.
  • 병합, 리베이스, 풀 리퀘스트를 할 때 다른 브랜치를 명시적으로 지정해야 함. Git은 사용자가 기반으로 생각하는 브랜치를 알지 못하기 때문임. 때로는 기능 브랜치를 다른 기능 브랜치에 병합하고 싶을 수 있으므로, 어떤 브랜치를 다른 브랜치에 병합할지 명확히 지정해야 함.
  • 사람들이 가지고 있는 직관이 기술적으로 부분적으로 틀릴 수 있어도, 그들이 그런 직관을 가진 데는 타당한 이유가 있음.
  • git addgit commit 사용법을 아는 사람들을 대상으로 한 동적인 튜토리얼이 있음. 이 튜토리얼은 브랜치를 시각화하며 읽을 수 있도록 도와줌.
  • Git 명령어를 수행할 때 '항상' 현재 브랜치를 수정한다는 것을 기억하면 Git의 문법을 '쉽게' 이해할 수 있음. 예를 들어, git merge my-branch는 현재 브랜치에 my-branch를 병합하고, git rebase my-branch는 현재 브랜치를 my-branch 위에 리베이스함.
  • 브랜치(헤드)가 해당 브랜치가 시작된 기저 커밋을 가리키는 '꼬리'를 가지는 것이 좋을 것 같음. 브랜치가 자주 리베이스되기 때문에 어디서 시작하는지 생각해야 할 때가 있음. Git이 기저 커밋이 main에 속한다고 알려주면 더 편리함.
  • 메일링 리스트에 '패치'를 보낼 때 기저 커밋을 선택적으로 포함할 수 있음. 이는 변경 사항이 최신 릴리스, 메인 개발 브랜치, 또는 통합 브랜치 중 어디에 기반하는지 명확하지 않을 수 있기 때문임. git range-diff를 사용할 때도 기저를 염두에 두어야 함. 이 도구는 main..previousmain..current와 같은 두 범위를 비교함.
  • 브랜치에 대한 개인적인 견해를 다시 읽고 잊었던 몇 가지를 다시 배움.