git & github

오늘은 개발자들이 협업하면서 사용하는 git과 github에 대해서 알아보겠다

---

git

git(깃)은 분산 버전 관리 시스템이다

 

소스 코드의 변경 이력(commit)을 저장하고, 버전을 관리하고 손쉽게 복구하는 것을 목표로 한다

특징

1. 분산 버전 관리

git은 모든 개발자가 전체 저장소를 각자의 환경에 저장한다

 

즉 인터넷이 없는 환경에서도 중앙 서버에 의존하지 않고 소스코드의 변경이력을 비교하고 불러오고 저장할 수 있다

 

2. 레포지토리 & 브랜치

먼저 레포지토리에 관해서 설명하겠다

 

레포지토리란 git에서 소스코드와 이력, 정보 등을 저장하는 공간이다

 

보통 하나의 프로젝트 단위로 생상하며 git init이라는 명령어로 local 환경에서 생성 가능하다

 

로컬 환경에서 이력과 정보를 저장하는 방법은 먼저 변경사항이 있는 파일을 git add <파일명> 명령어로 Staging Area에 올려야 합니다.

 

이렇게 하면 해당 파일이 레포지토리에 저장될 준비 상태가 됩니다.

 

그다음, git commit -m "커밋 메시지" 명령어를 사용하면 Staging Area에 있는 변경사항들을 저장한다

 

브랜치란 작업의 흐름을 나누는 갈래다

 

여러 개발자가 협업할 때, 동시에 여러 기능을 개발해야 할 경우 주로 사용합니다.

 

보통 가장 기본이 되는 브랜치는 main 혹은 master 브랜치가 있으며,
여기서 새로운 작업을 위해 git branch 브랜치명 명령어로 새로운 브랜치를 생성할 수 있다

 

또한 git checkout 브랜치명을 통해 해당 브랜치로 이동할 수 있다

 

브랜치는 코드의 독립된 공간으로서, 서로 다른 브랜치에서 진행한 변경사항은 다른 브랜치에 영향을 주지 않는다

 

예를 들어, main 브랜치에서 만들어진 A라는 브랜치에서 새로운 기능을 추가하거나 소스코드를 변경해도,
main 브랜치의 내용에는 전혀 영향을 미치지 않는다

 

그럼 A 브랜치에서 추가된 기능이나 변경된 소스코드를 어떻게 main에 반영할까?

 

브랜치의 변경사항을 다른 브랜치에 반영할 때에는 git merge라는 명령어를 사용하면 된다

 

내가 변경사항을 반영할 브랜치로 이동한 후에 git merge 브랜치명을 사용하면 변경사항이 해당 브랜치에 반영된다

 

여기서 생각을 한번 해보자

 

우리가 협업을 할때 git을 사용한다고 했다.

예를 들어 master에서 생성된 브랜치 A와 B가 있다고 가정해 보자

 

A와 B 각각의 브랜치에서 변경사항을 만든 후에 각자 역할이 끝나 main에 merge 했다

 

그런데 2개의 브랜치에서 add라는 파일에 변경사항이 있었다

//main 브랜치
function add (a, b) {
  return a + b;
};

//A 브랜치
function add(a, b) {
  return a + b + b;
};

//B 브랜치
fuinction add(a, b){
  return a * b;
};

A 브랜치에서는 b를 두 번 더해서 return을 하도록 바꾸고

B 브랜치에서는 a와 b를 곱해서  return을 하도록 바꿨다

 

이때 main에 A의 변경사항과 B의 변경사항이 merge 된다면 

git에서는 A와 B에서 추가된 변경사항이 다르므로 어떤 변경사항을 반영할지 알 수 없다

 

위와 같은 현상을 conflict(충돌)이라고 한다

 

3. 충돌 관리

git에서는 위 상황처럼 같은 부분의 변경사항을 하나의 브랜치에 병합을 시도할 경우

A와 B 브랜치의 변경사항 중 어느 것을 반영할지 몰라 충돌 상태가 되고 사용자가 직접 수정해야 한다

 

이때는 log에서 충돌이 난 파일을 에러로 출력하고 그 위치를 표시한다

오른쪽에 현재라고 되어있는 부분은 먼저 병합이 진행된 A브랜치의 변경사항이고

왼쪽에 수신이라고 되어있는 부분은 B 브랜치에서 수신되어 온 변경사항이다

 

밑에 나와있는 결과는 충돌난 변경사항을 무시하고 기존에 작성된 소스코드를 보여준다

 

이때 사용자는 둘 중 어떤 변경사항이 main에 적용될지 선택하고 병합을 마무리하면 된다

 

이처럼 git에서는 충돌이 일어났을 때 자동으로 병합하지 않고, 충돌 위치를 명확히 표시해 줌으로써 개발자가 직접 판단하고 수정할 수 있도록 돕는다

 

또한 충돌된 파일과 위치를 git status나 병합 도구를 통해 시각적으로 확인할 수 있어, 코드의 손실 없이 안정적으로 병합을 마무리할 수 있는 환경을 제공한다

 

이러한 충돌 처리 방식은 단순한 자동 병합보다 더 정확하고 유연한 협업을 가능하게 해 주며, 여러 명이 동시에 같은 프로젝트를 작업할 때 의도치 않은 덮어쓰기나 오류를 방지해 주는 중요한 안전장치 역할을 한다.

 

github

GitHub는 Git을 기반으로 만든 클라우드 플랫폼이다.

 

앞서 설명했던 것처럼 Git은 로컬(Local) 환경에서 레포지토리와 브랜치를 통해 작업할 수 있다.

그러나 이는 말 그대로 레포지토리가 내 컴퓨터 안에 존재하는 것이기 때문에 실시간으로 협업하기에는 어려움이 있다.

 

이러한 문제를 해결하기 위해 등장한 것이 바로 GitHub이다.

 

GitHub를 사용하면 로컬에 있는 레포지토리를 원격 저장소(Remote Repository)에 업로드할 수 있다.

이를 통해 다른 사람과 실시간으로 변경 사항을 공유하고 브랜치를 병합할 수 있다.

또한 git push 명령어를 통해 로컬에서의 커밋을 서버로 전송하여 실시간으로 관리할 수 있다.

방법

로컬 레포지토리와 원격 저장소에 업로드하는 방법은 git remote add origin <github 레포지토리 주소>이란

명령어를 사용해 주면 위에서 작성한 레포지토리 주소에 로컬 레포지토리의 내용이 원격 저장소에 연결이 된다

 

이때  git push명령어로 기존에 있던 내용을 원격저장소로 업로드하는데,

업로드되는 내용은 프로젝트 내 파일들과 연결 이전에 진행했던 commit들 까지 전부 업로드된다

 

즉, 단순히 현재 코드만 올리는 것이 아니라, 개발 과정 전체의 기록까지 함께 공유되는 것이다.

 

그리고 변경사항을 올리는 과정은 git명령어와 크게 다르지 않다

 

그냥 commit을 하고 git push 명령어를 사용해서 원격 저장소로 commit들을 보내고, 

브랜치를 만들고 난 후에도 git push명령어를 사용해서 원격 저장소로 이 "브랜치 만들어졌어요"라고 보내면

원격 저장소에서는 해당 브랜치를 표시한다

 

또한 git pull이라는 명령어도 존재하는데,

git pull 명령어는 원격저장소의 변경사항을 local로 가져오는 명령어다

 

만약 협업을 하면서 다른 팀원이 main브랜치에 팀원의 브랜치를 merge 시켰다고 가정해 보자

 

그러면 그 변경사항은 아직 나의 local에는 반영되지 않아서 나중에 나의 브랜치를 merge 시킬 때 충돌을 일으킬 가능성이 있다

 

그래서 git pull이란 명령어로 원격 저장소에 있는 내용을 나의 local로 가져와서

일어날 수 있는 충돌을 방지할 수 있고, 다른 팀원이 merge 한 코드를 가져와서 사용할 수 있다

장점

1. GUI기반의 편리한 사용자 경험

아무리 Git 명령어에 익숙하더라도, 커멘드에 명령어만 사용하다 보면
가끔은 실수하거나 헷갈릴 수 있다

 

하지만 GitHub는 웹 기반 GUI(그래픽 사용자 인터페이스)를 제공하기 때문에,
커밋 내역 확인, 브랜치 비교, 병합 등의 작업을 직관적이고 시각적으로 수행할 수 있다

 

복잡한 명령어를 몰라도 클릭 몇 번으로 주요 작업을 처리할 수 있어
초보자에게도 진입장벽이 낮고, 팀 단위 협업 시에도 훨씬 편리하다

 

2. Pull Request를 통한 안전한 협업

pull request는 merge 하기 전에 "A브랜치를 main브랜치로 merge 하겠습니다"하고 알려주는 역할을 한다

 

GitHub에서 협업의 핵심 도구 중 하나는 바로 Pull Request(PR)이다

Pull Request는 A 브랜치의 변경 내용을 메인 브랜치(main 등)에 병합하기 전에
그 내용을 다른 팀원들과 공유하고, 리뷰 및 승인을 받는 절차이다

 

예를 들어, 기능 개발을 위해 feature/login이라는 브랜치에서 작업한 후,
그 결과물을 main 브랜치에 반영하려 한다면, 단순히 merge 하는 것이 아니라
먼저 GitHub에서 PR을 생성하게 된다

 

PR을 만들면 다음과 코드리뷰, 의견 공유, approve과 같은 절차를 수행할 수 있다

 

코드리뷰는 merge 할 브랜치의 변경사항을 팀원들과 공유하고 팀원들이 확인하면서

그 과정에서 오류를 찾거나 더 나은 코드와 의견을 제시하고 토론할 수 있다

 

approve는 merge를 해도 되는지 팀원의 결정을 받는 과정이다

 

내가 한 작업물에서 더 이상 코드리뷰나 발견된 에러가 없다면 팀원들은 "이제 merge해도 됩니다"라는 의미로 approve라는 것을 남길 수 있다

 

보통 프로젝트에서는 PR에 대해 하나 이상의 Approve를 받은 후에만 병합할 수 있도록 규칙을 설정해 두는 경우가 많다

이렇게 하면 검증되지 않은 코드가 무분별하게 main 브랜치에 반영되는 것을 방지할 수 있고 조금 더 확실하게 짚고 넘어갈 수 있다

 

3. 협업과 개발의 편의성

내가 위에서도 말했던 내용이지만 github를 사용하면 협업과 개발이 굉장히 쉽고 간단해진다

 

위에서 말했던 PR이라던지 원격저장소, git push, git pull 이런 것들을 제외하고도 여러 기능이 존재한다

 

여러 명의 개발자(팀원)를 한 곳에 묶어서 함께 프로젝트를 관리할 수 있는 계정 단위인 organizations(조직)이 존재하는데, 

개인 계정과 달리, 조직 계정은 여러 팀원이 소속되어 있고, 팀 단위로 권한을 관리하거나 저장소(repository)를 공동 소유할 수 있다

 

이를 통해 각 팀원에게 적절한 접근 권한을 부여하거나, 팀별로 역할을 분담해 업무를 명확히 할 수 있어, 프로젝트 관리가 훨씬 수월해진다

 

또한, 조직 단위로 보안 정책을 통합 관리하거나, 비용 청구를 한 번에 처리하는 등 협업과 개발에 필요한 여러 요소들이 간편해져 전체적인 작업 효율성이 크게 향상된다

 

이슈는 프로젝트 내에서 버그, 기능 개선, 작업할 일 등을 기록하고 관리하는 도구이다

 

개발자들이나 팀원들, 아니면 실 사용자가 프로젝트 진행 중에 발생하는 문제점이나 아이디어를 등록할 수 있게 해주는 기능인데,

개발하면서 발견된 오류들이나 이슈, 사용자가 프젝트를 사용하면서 느낀 불편한 점 & 개선할 점 같은 걸 적을 수 있다

 

사실 이슈를 많이 사용한 적은 없어서 잘 모르겠지만 github의 오픈소스를 확인해 보면 이슈가 몇백 개씩, 많이 있는 모습을 봐서 여기에도 적어봤다

react의 레포지토리의 이슈

 

결론

사실 내가 개발을 처음 할 때에는 git은 뭐고, github도 뭔지 모르고 사용했었다

그 후에 github를 통해 협업을 많이 진행하고, 프로젝트를 많이 수행하다 보니까 자연스럽게 알게 되었다

 

처음부터 모든 걸 알 필요는 없지만, git과 github가 어떤 역할을 하는지 정도는 알고 사용하면 훨씬 수월하다

 

브랜치나 커밋, PR 같은 개념을 알고 있으면 협업할 때 실수가 줄고, 프로젝트를 체계적으로 관리할 수 있고,
무작정 사용하는 것보다는, 최소한의 개념만이라도 이해하고 쓰는 게 정말 많은 도움이 된다는 것을 느꼈다

 

앞으로도 git과 github는 개발할 때 계속 함께할 도구들이니,
알고 사용하면 분명 더 편하고 효율적으로 프로젝트를 수행할 수 있을 것이다