본문 바로가기
TIL/git

Git 고급 사용법과 협업: 실무에서 꼭 알아야 할 핵심 개념

adeliae.p 2025. 1. 20. 13:35

 

지난 글에서는 Git의 기본적인 사용법과 로컬 저장소에서의 기초적인 작업 흐름에 대해 다뤘습니다. 이번 글에서는 GitHub를 통한 협업 방법, Git의 강력한 기능인 revert와 reset, 그리고 지난 번에 다루지 못했던 커밋 메시지 작성 규칙과 SHA-1 해시와 관련된 보안 이슈를 다뤄보겠습니다. 이 내용들은 실무에서 효율적인 Git 사용과 협업을 위해 꼭 필요한 내용들입니다.

GitHub 원격 저장소 생성 및 로컬 연결 방법

먼저, 협업을 위해서는 원격 저장소와 로컬 저장소를 연결 해야겠죠!

아래는 GitHub에서 원격 저장소를 만들고 이를 로컬 저장소와 연결하는 방법입니다.

GitHub 원격 저장소 생성 및 로컬 연결

  1. GitHub에서 원격 저장소 생성
    • GitHub에 접속해 로그인합니다.
    • 오른쪽 상단의 + 버튼을 클릭하고 New repository를 선택합니다.
    • 저장소 이름과 설명을 입력하고 Public 또는 Private 옵션을 선택한 후, Create repository를 클릭합니다.
  2. 로컬 저장소와 원격 저장소 연결
    • 로컬에서 Git 저장소를 초기화한 후, 생성한 GitHub 원격 저장소와 연결합니다:
      git init git remote add origin <저장소 URL>
       
      <저장소 URL>은 GitHub에서 제공하는 저장소의 HTTPS URL 또는 SSH URL입니다.
      저장소 URL 예시: https://github.com/username/repository.git
  3. 변경 사항 푸시(Push)
    • 로컬에서 작업한 내용을 원격 저장소로 업로드합니다:
      git add . git commit -m "커밋 메시지"
      git push origin main
       
  4. 결과 확인
    • GitHub 저장소 페이지에 접속하여 로컬에서 업로드한 파일들이 제대로 반영되었는지 확인합니다.

 


아마, 위 과정들을 잘 진행하셨다면 로컬 저장소와 원격 저장소가 잘 연결된 것을 확인하실 수 있을겁니다.

그렇다면 이제 이 원격 저장소를 어떻게 팀과 함께 협업에서 잘 사용할 수 있는지 알아보겠습니다.

 

GitHub를 통한 협업 방법

GitHub를 활용한 협업은 팀 프로젝트에서 필수적입니다. 아래는 협업을 위해 알아야 할 기본적인 작업 흐름입니다.

Fork와 Pull Request

  • Fork: 프로젝트를 복사해 내 계정에서 독립적으로 작업할 수 있도록 만듭니다.
  • Pull Request(PR): 수정한 내용을 원래 프로젝트에 반영 요청하는 작업입니다.
    • PR은 내가 작성한 코드를 검토받고 원래 프로젝트에 반영되도록 요청하는 과정입니다. 따라서 요청 시, 작업한 내용을 설명하고 변경 이유를 작성해야 하겠죠!

브랜치를 활용한 작업

  • 협업에서는 브랜치 단위로 작업을 진행합니다. 
  • 브랜치는 다음과 같은 명령어로 생성할 수 있습니다.
    다음 명령어는 feature/branch-name의 이름으로 새 브랜치를 생성하는 코드입니다. 
git checkout -b feature/branch-name

위 코드를 작성하고 나면 다음과 같이 (master)가 branch 이름으로 바뀌는 것을 확인할 수 있습니다.

user@user /Desktop (feature/branch-name) $

브랜치? 그게 뭐야?

브랜치(Branch)는 Git에서 독립적인 작업 공간을 의미합니다. 일반적으로 독립적인 작업 단위로 프로젝트를 분리 하고 이를 브랜치를 이용해 관리함으로써 여러 사람이 동시에 서로 다른 작업을 진행하거나, 새로운 기능을 실험적으로 추가하고 있습니다.

브랜치의 기본 개념

  • 메인 브랜치(Main Branch)
    일반적으로 main 또는 master 브랜치는 프로젝트의 안정적인 버전을 유지하고, 실제 배포되는 코드가 담겨 있습니다.
  • 기능 브랜치(Feature Branch)
    새로운 기능이나 수정 작업은 메인 브랜치에서 바로 진행하지 않고, 별도의 브랜치를 만들어 작업합니다. 작업이 완료되면 메인 브랜치에 병합(Merge)합니다.

브랜치를 사용하는 이유

  • 독립적인 작업 공간
    브랜치를 사용하면 다른 작업에 영향을 주지 않고 특정 작업을 독립적으로 진행할 수 있습니다. 이렇게 작업을 나누면 서로 다른 작업이 동일한 공간에서 일어나서 복잡한 저장소가 되는것을 막을 수 있겠네요!
    예시: 로그인 기능 작업을 feature/add-login 브랜치에서, 버그 수정 작업을 bugfix/fix 브랜치에서 독립적으로 수행.
  • 협업 효율성
    팀원들이 각자 브랜치에서 작업한 후, 최종적으로 메인 브랜치에 병합하면 충돌을 최소화하며 효율적인 협업이 가능합니다.
    Git은 변경사항(커밋)을 추적하기 때문에 서로 다른 변경사항이 동일한 저장소에서 작성된다면 어떤 것을 추적할지 충돌이 생기게 됩니다. 이런 충돌의 생성과 해결은 git 작업의 필수 불가결한 부분이지만 최대한 충돌을 줄이는 방법이 바로 브랜치를 적절하게 관리하는 것입니다.
  • 안정성 확보
    메인 브랜치에는 검증된 코드만 병합하므로 프로젝트의 안정성을 유지할 수 있습니다.
    브랜치에 병합될 코드는 PR을 통해 코드 리뷰와 검증이 이루어져, 버그가 포함될 가능성을 줄일 수 있습니다.

브랜치의 기본 흐름 및 명령어

  1. 브랜치 생성 및 전환
    아래 명령어는 새로운 브랜치를 생성하고 해당 브랜치로 이동합니다.
    git checkout -b feature/branch-name
  2. 작업 후 변경 사항 커밋
    브랜치에서 작업한 내용을 커밋합니다.
    git add . git commit -m "커밋 메시지"
  3. 메인 브랜치로 병합 
    # master(main) branch로 이동
git checkout master

     

    # 현재 branch(master)에 feature/branch-name branch를 병합(merge)
git merge feature/branch-name
    작업이 완료되면 메인 브랜치로 이동한 후, 작업한 브랜치를 병합합니다.

 실제 활용 예시

만약, 어떤 프로젝트에 로그인 기능을 추가하는 작업을 진행한다고 가정해 본다면,

  1. feature/add-login 브랜치를 생성하여 로그인 기능 구현 작업을 합니다.
  2. 작업을 완료한 후, 변경 사항을 커밋합니다.
  3. 브랜치를 메인 브랜치에 병합하여 최종적으로 프로젝트에 반영합니다.

다만, 일반적인 경우 master branch에 바로 merge를 진행하지 않고 반드시 PR(Pull Request)를 통해서 master branch에 병합하는 과정을 거치게 됩니다.

 

 Revert와 Reset 기능 소개

커밋이 한번에 완벽하게 끝나면 좋겠지만, 커밋메시지를 제대로 작성하지 않고 커밋하거나 실수로 다른 branch에서 커밋을 진행하는 등의 실수는 빈번하게 일어나는 편입니다. 이러한 경우 Git은 실수로 발생한 변경 사항을 되돌리기 위한 강력한 도구를 제공합니다.

Revert

  • 특정 커밋의 변경 사항을 "되돌리는" 새로운 커밋을 생성합니다. 
    git revert <커밋 해시>
    커밋 해시: git log로 확인할 수 있고, 해시를 전부 작성하지 않고 앞의 4~5자만 작성해도 제대로 작동합니다.
  • Revert는 히스토리를 유지하며 변경을 되돌릴 수 있어, 협업 환경에서 주로 사용됩니다.
  • 완전히 변경사항이 사라지는 것이 아니라 변경사항을 되돌리는 새로운 변경사항을 생성하는 것이 특이한 점입니다.

Reset

  • 특정 커밋으로 되돌아가 작업 내역을 수정하는 방법으로, 원하는 커밋의 상태로 돌아갈 수 있는 타임머신 입니다.
    총 3가지의 방법이 있고, Soft / Mixed / Hard 로 나누어집니다. 방법에 따라 현재 변경사항이 어떻게 처리될 지가 결정됩니다.
    • Soft Reset: 변경 사항을 Staging Area에 유지. 
      git reset --soft <커밋 해시>
    • Mixed Reset: 변경 사항을 Unstaged 상태로 이동. 
      git reset --mixed <커밋 해시>
    • Hard Reset: 변경 사항을 모두 삭제. 
      git reset --hard <커밋 해시>

그렇다면 각각 어떤 경우에 쓰면 좋을지 생각해 볼까요?

 

Soft Reset: 변경 사항은 그대로 Staging Area에 유지되면서 커밋을 되돌리는 기능이기 때문에, 커밋 메세지를 안적고 커밋을 했거나, 직전 커밋에 간단한 변경사항이 있는 경우에 사용한다면 간단하게 변경사항만 수정하여 다시 커밋을 하면 되니까 편리하겠네요!

Mixed Reset: 변경사항을 Unstaged 상태로 바꾸면서 커밋을 되돌리는 기능으로, 커밋에 자잘한 변경점이 있지만 이미 커밋이 너무 많이 쌓인 경우에 사용한다면 수정사항을 반영한 뒤에 다시 적절하게 staging area에 변경사항을 차근차근 커밋하는 것으로 사용하면 좋겠네요.

Hard Reset: 변경사항을 모두 삭제하고 커밋을 되돌리는 기능으로 진행된 커밋 자체를 모두 삭제시켜버리고 다시 작업하는 경우에 사용하면 좋겠네요. 현재 커밋 내용에 중요한 부분이 포함된 경우 Hard Reset을 진행하면 복구하기 힘들기 때문에 사용하기 전에는 백업을 진행하거나 현재 커밋의 해시를 기록해두면 문제가 생겼을 때 복구가 훨씬 쉽답니다.

 

Git SHA-1과 보안 관련

지난 글에서 다루지 못했던 SHA-1 해시 알고리즘 관련 토막 내용입니다.

Git에서 커밋은 고유한 SHA-1 해시를 통해 식별된다고 지난 글에서 말씀드렸었는데요, 사실 SHA-1 알고리즘은 보안 취약점이 발견되어 더 이상 안전하지 않다는 평가를 받았습니다.

  • SHA-1의 보안 취약점

충돌 가능성(Collision)이 발견되어 동일한 해시를 가진 서로 다른 데이터를 생성할 수 있습니다.
즉, 서로 다른 두 데이터가 동일한 해시를 가질 수 있고, 이는 데이터의 무결성을 해치는 중대한 위험이 될 수 있습니다.
이론적으로는 충돌 확률이 낮지만, 구글 연구에 따르면 실제로 충돌을 생성할 수 있음을 입증했습니다.

 

Marc Stevens, Elie Bursztein, Pierre Karpman, Ange Albertini, Yarik Markov. “The first collision for full SHA-1.” Google Research Blog, 23 February 2017. https://shattered.io/  

 

  • SHA-1의 대안 (SHA-256)
    • SHA-1의 보안 취약점이 발견됨에 따라, Git은 점진적으로 SHA-256 해시 알고리즘으로 전환하고 있습니다.
      SHA-256은       SHA-1보다 더 긴 해시 값(256비트)을 생성하며, 충돌 가능성을 현저히 낮춥니다.

즉, 해시 알고리즘의 복잡성을 올려서 동일한 해시 코드를 계산을 통해 만들 수 없도록 합니다. 이는 현재 컴퓨터의 계산 능력으로는 어렵다고 알려져 있지만 먼 미래에 컴퓨터의 계산능력이 비약적으로 개선된다면 다시 수정해야 할 수도 있겠네요.

커밋 메시지 작성 규칙

지난 글에서 일반적으로, 협업 시 커밋 메시지를 작성하는 규칙을 정해서 작성한다고 말씀드렸었는데요, 이는 서로의 작업 내용을 이해하기 쉽게 하는 중요한 작업입니다.

기본 형식

일반적으로 사용하는 커밋 메시지 템플릿을 소개해 드리겠습니다.

<타입>: <주제> <공백 줄> <본문> <공백 줄> <footer>

커밋 메시지 타입

  • feat: 새로운 기능 추가
  • fix: 버그 수정
  • docs: 문서 관련 작업
  • style: 코드 포맷팅, 세미콜론 누락 등
  • refactor: 코드 리팩토링
  • test: 테스트 코드 추가/수정

예시

feat: 사용자 로그인 기능 추가

- JWT를 사용해 인증 로직 구현
- 로그인 실패 시 에러 메시지 출력

Resolves: #123

footer는 Github에서 해당 작업을 올려놓은 issue의 태그와 맞춰서 사용하는 것이 일반적입니다. 즉, #123은 Github에 작성된 사용자 로그인 기능 추가에 관한 issue의 태그 번호겠네요!

 

마무리

이번 글에서는 GitHub를 활용한 협업 방법, revert와 reset의 기능과 차이점, SHA-1의 보안 문제, 그리고 커밋 메시지 작성 규칙에 대해 살펴보았습니다. 이 내용들을 실무에서 적절히 사용하셔서 유용하게 활용하시면 좋겠습니다.

Git을 활용하는 방법과 사용법들에 대해서는 훨씬 더 많은 방법들이 있으니 다양한 기능을 익히며 프로젝트에 적극 활용해 보세요.

이 글에서 다룬 내용 외에도 Git 사용과 관련해 궁금한 점이 있거나, 잘못된 부분이 있다면 댓글로 자유롭게 알려주세요. 여러분의 피드백은 글을 더 발전시키는 데 큰 도움이 됩니다! 😊

 
 
 
 
 

 

'TIL > git' 카테고리의 다른 글

Git 기초  (0) 2025.01.17

'TIL/git' Related Articles

티스토리툴바