코드 형상 관리

혼자 혹은 다수의 개발자가 개발을 진행하면, 코드를 한두줄 쓰고 끝나는 것은 아니다. 이에, 코드가 언제 어떻게 바뀌었는지 알아야 코드에 대한 관리가 쉬워진다. 이를 돕는 여러 툴 중 GIT 에 대해 알아보고자 한다.

Git

GIT 은 위에 이야기 했듯 코드 형상 관리를 도와준다.

설치 목록

• GIT
• GIT Desktop; 있으면 편하다.

용어

• Repository: 저장소. 말 그대로 코드나 출품물에 대해 저장하는 공간.

  • Local/Remote Reposity: 각각 내 PC 내 저장소와 인터넷상 저장소.

• Clone: 원격 저장소를 내 로컬 환경에 복사해 오는 기능.

• Commit: 저장소 내 코드 및 기타 출품물에 대한 변경 사항에 대해 적용하는 기능.

  • Message:
    커밋 메시지는 개발 내용에 대한 간략한 메시지를 남길 수 있는 기능.
    따라서 개발 내용에 대해 제대로된 메시지를 담지 않으면 그다지 좋지 않다.
    - 커밋 메시지 가이드를
    참고만 하자.

• HEAD: Commit 시 해당 Commit 에는 Hash 값(고유 ID)이 존재하게 됨.
  해당 Hash 값으로 checkout 혹은 reset을 통해 옮겨갈 수 있음.

• Push: 내 로컬 저장소에 변경된 내용을 원격 저장소에 적용하는 기능.

• Fetch: 내 로컬 저장소와 원격 로컬 저장소의 "형상"을 동기화.

• Pull: 원격 저장소에 변경된 내용을 내 로컬 저장소에 Update 하는 기능.

• Checkout: 특정 Commit 으로 돌아갈 수 있는 기능. 단, 옵션에 따라 여러 행위 가능

  • b: branch 를 생성하며 해당 branch 로 옮김
  • t: Origin Branch 를 Pull 받으며 해당 Branch 로 옮김.

• Git Ignore: Repository 내에 불필요한 파일에 대한 Remote 로의 Upload 를 막는 기능.
  주로 .gitignore파일로 관리된다.

• Branch: 말 그대로 가지이다. 일반적으로 기능추가, 버그수정등에 대해 새로운 branch 를 만들어 해당 branch 에서 작업을 하는 것이 보통이다. 그렇게 작업된 Branch는 지정된 branch로 merge를 하게 된다.

• Merge: 작업된 Branch에서 타겟이 되는 Branch로 코드를 병합하는 작업이다. 보통은 Local 에서 Merge하는 경우는 많이 없으며, 특히 협업시 주로 Pull Request를 많이 활용한다.

• Pull Request: Pull Request는 특정 Branch에서 작업한 내용을 주 Branch로의 Merge를 검토 요청하기 위한 문서이다.

  • 코드 리뷰: 주로 개발자들이 이야기하는 코드 리뷰는 Pull Request(통칭 PR)의 내용을 리뷰하는 것이다. Pull Request에서 쓰는 내용에 대해서는 다른 항목에서 다루기로 한다.

• Reset: (⚠️주의) 해당 Commit 으로 돌리는 기능. 로컬 저장소에서 진행. reset시 되돌린 시점 이후 commit은 모두 삭제됨.

  • 되도록 사용하는 상황이 없어야 한다.

• Revert: (⚠️주의) 되돌린 commit을 이후 추가적인 역순의 commit을 통해 복구하는 기능.

  • 되도록 사용하는 상황이 없어야 한다.

Pull Request

협업시 주 branch 에 자신이 혹은 멤버가 개발한 branch를 병합하기 위해 같이 프로젝트를 진행하는 멤버에게 코드 리뷰를 부탁하는 리포트로 보면 된다.

작성 요령

해당 Branch에서 작업한 내용에 대한 되도록 자세한 정리를 적어 놓는 편이 좋다. 코드와 주석으로만은 설명이 어려운 내용도 많다. 그렇다고 지나치게 많은 내용을 적으면 아래와 같은 코드 리뷰에 시간이 오래 걸리기 때문에 그 적당한 분량에 대한 것은 많은 PR을 적어보며 익히는 것이 좋다.

코드 리뷰

협업시 자신이 혹은 멤버가 PR을 올린 것에 대한 리뷰를 하는 행위이다. 코드에 대한 내용이나 알고리즘, 설계등에 대한 내용에 대해 이해가지 않은 내용이나 문제점에 대해 논의 할 수 있다. 별다른 추가 내용이 없다면 Approve를 통해 해당 PR에 대한 병합 동의라는 의견을 낼 수 있게 된다.
보통 리뷰어가 모두 Approve를 해야 (혹은 정해진 인원수 이상, 필수 리뷰어 등 옵션이 많음) 원격 저장소에서 병합을 할 수 있게 된다.

Git Flow

Git 에서 제공하는 Branch 를 이용한 업무 Flow 에 대한 내용이다. master 혹은 main 은 말 그대로 메인이 되는 branch 이다. 해당 branch 로의 직접적인 Push를 하는 것을 일반적으로는 지양하고 있다.
작업자들이 보통 Merge하는 Target Branch는 dev 혹은 develop이라 하는 개발 브랜치다.
위 그림은 각 업무 성격에 맞춰 병합하는 내용에 대해 잘 나와있으니 한번 참고하기로 하자.