Git 잘 쓰는 개발자 되Git

처음으로 친구들과 함께 협업을 하게 된 나는 Git과 GitHub를 사용하여 협업을 하려 했지만, add, commit, push 같은 기본적인 것들 말고는 아는 것이 없었고, 어떻게 효율적으로 협업을 할 수 있는지도 정확히 알지 못했다. 팀에 프론트엔드가 나 혼자였다면 크게 문제가 되지 않았겠지만, 프론트엔드가 나를 포함해 두 명이었기에 협업 방법을 배워야 했고, 그 결과로 지금 이 글을 쓰고 있다.

아, 참고로 친구를 탓하는 것은 아니다. 오히려 협업에 대해 공부하고 직접 경험해볼 수 있는 기회를 주어 고마운 마음이다. Shout Out xy-jxn

Git? GitHub? 똑같은거 아님?

내가 Git과 GitHub를 처음 써볼 때 했던 생각이다. "그냥 깃허브를 줄여서 깃이라고 부르는 건가?"라는 단순한 생각과 초기 설정도 제대로 안하고 레포지토리 연결도 못했었다. 하지만 이제는 친구가 물어봤을 때 완벽하진 못해도 대답은 해줄 수 있기에 확실하게 구분해서 정리해보겠다.

Git

Git은 버전 관리 시스템(VCS, Version Control System)이다. 소스 코드와 파일의 변경 이력을 관리하고 추적하는 도구로, 다음과 같은 기능을 제공한다.

1. 버전 관리: 소스 코드의 변경 이력을 기록하고 관리한다. 각 변경 사항(커밋/commit)을 추적할 수 있다.

   • commit: 파일의 변경 사항을 저장하고 기록하는 작업을 의미한다.

2. 브랜치와 머지: 브랜치(branch)를 생성하여 독립적으로 작업할 수 있으며, 완료된 작업을 다른 브랜치에 병합(머지/merge)할 수 있다.

   • branch: 프로젝트의 독립적인 작업 흐름을 생성하고 관리할 수 있는 기능이다.

   • merge: 한 브랜치의 변경 사항을 다른 브랜치에 통합하는 작업입니다

3. 분산형: Git은 분산형 버전 관리 시스템으로, 각 개발자는 로컬 저장소를 가지며 중앙 서버와 연결되지 않아도 작업할 수 있습니다.

   • 로컬 저장소: Git을 사용하는 로컬 컴퓨터에 있는 저장소를 말한다.

Git은 로컬에서만 사용할 수 있지만, 여러 명이 협업하기 위해 원격 저장소와 연결할 수 있다.

GitHub

GitHub은 Git을 기반으로 한 웹 기반 호스팅 서비스다. GitHub는 Git 저장소를 호스팅하고 다양한 협업 도구를 제공한다. GitHub의 주요 기능은 다음과 같다.

1. 원격 저장소: Git 저장소를 클라우드에 호스팅하여 인터넷을 통해 접근할 수 있다.

2. 협업 도구: Pull Request, 코드 리뷰, 이슈 트래킹, 프로젝트 관리 도구 등을 제공한다. 팀원 간의 협업을 원활하게 지원한다.

   • Pull Request(PR): 협업 개발에서 코드 변경을 제안하고 검토하는 데 사용되는 기능이다.

3. GitHub Actions: CI/CD(지속적 통합 및 배포) 파이프라인을 설정하여 자동화된 빌드, 테스트, 배포 작업을 수행할 수 있다.

4. GitHub Pages: 웹 페이지를 호스팅하고 배포할 수 있는 기능을 제공한다.

요약

결국 Git은 코드 관리의 핵심 도구이고, GitHub은 그 도구를 온라인에서 사용할 수 있게 해주는 플랫폼이다.

명령어가 왜 이렇게 많아...

Git에는 용도에 따른 정말 다양한 명령어들이 있다. 하지만 하나하나 설명하기엔 너무 많으니 자주 사용되는 명령어만 정리 해보겠다.

용도	명령어	설명
저장소 초기화 및 복제	$ git init	새로운 로컬 Git 저장소를 초기화할 때 사용.
	$ git clone [repository URL]	원격 저장소를 로컬에 복제할 때 사용.
변경 사항 추적 및 확인	$ git status	현재 저장소의 상태 (추적, 스테이징, 커밋되지 않은 파일)를 확인할 때 사용.
	$ git diff	파일의 변경 사항을 비교할 때 사용.
파일 스테이징 및 커밋	$ git add [file]	변경된 파일을 스테이징할 때 사용.
	$ git commit -m "message"	스테이징된 변경 사항을 커밋할 때 사용.
브랜치 관리	$ git branch	브랜치를 생성하거나 목록을 확인할 때 사용.
	$ git checkout [branch-name]	브랜치를 전환하거나 특정 커밋을 체크아웃할 때 사용.
	$ git merge [branch-name]	다른 브랜치를 현재 브랜치로 병합할 때 사용.
원격 저장소와의 상호작용	$ git remote	원격 저장소를 관리할 때 사용.
	$ git pull	원격 저장소의 변경 사항을 가져와 현재 브랜치와 병합할 때 사용.
	$ git push	로컬 커밋을 원격 저장소에 업로드할 때 사용.
커밋 히스토리 관리	$ git log	커밋 히스토리를 확인할 때 사용.
	$ git reset [commit]	특정 커밋으로 돌아가서 변경 사항을 취소할 때 사용.
작업 임시 저장 및 복구	$ git stash	작업 중인 변경 사항을 임시로 저장하거나 나중에 복구할 때 사용.

등등이 있는데..
위 표에 있는 것들도 가장 기본적인 명령어들만 가져온 거고, 실제로 하나하나 다 뜯어보면 명령어가 셀 수도 없이 엄청나게 많다.

협업할거면 Git Flow도 알아야 Git지?

Git Flow에서 Flow는 직역하면 흐름이라는 의미다. Git Flow는 Git을 활용한 브랜치 관리 전략 중 하나로, 대규모 프로젝트나 복잡한 워크플로우에서 코드베이스를 효율적으로 관리할 수 있도록 도와줍니다. Git Flow는 크게 두 가지 주요 브랜치와 몇 가지 보조 브랜치로 구성된다.

주요 브랜치

1. main 브랜치

   • 항상 배포 가능한 상태의 코드를 유지하는 브랜치이다.
   • 릴리즈된 버전이 이 브랜치에 기록된다.

2. develop 브랜치

   • 개발 중인 기능이 통합되는 브랜치이다.
   • 개발 작업의 중심이 되는 브랜치로, 기능 개발이 완료되면 이 브랜치로 병합된다.

보조 브랜치

1. feature 브랜치

   • 새로운 기능을 개발하기 위해 사용되는 브랜치이다.
   • develop 브랜치에서 분기하여, 개발이 완료되면 다시 develop 브랜치로 병합된다.
   • 브랜치 명명 규칙: feature/기능명

2. release 브랜치

   • 릴리즈 준비를 위한 브랜치이다.
   • develop 브랜치에서 분기하며, 최종 테스트와 버그 수정이 완료되면 main과 develop 브랜치에 병합됩니다.
   • 브랜치 명명 규칙: release/버전번호

3. hotfix 브랜치

   • main 브랜치에서 발견된 긴급한 버그를 수정하기 위한 브랜치입니다.
   • main 브랜치에서 분기하며, 수정이 완료되면 main와 develop 브랜치에 병합됩니다.
   • 브랜치 명명 규칙: hotfix/버그명 또는 hotfix/버전번호

그래서 왜 쓰는데

직접 안써보고 글만 봐도 벌써부터 머리가 어지러워 지는데, 그럼에도 사람들이 Git Flow를 사용하는 확실한 이유가 있다.

1. 명확한 브랜치 구조

   • 각 브랜치가 명확한 목적을 가지고 있어, 개발 과정에서의 혼란을 줄이고 코드 관리가 용이합니다.

2. 안정성과 품질 보장

   • release와 hotfix 브랜치를 통해 배포 전에 충분한 테스트를 진행하고, 긴급한 버그를 빠르게 수정하여 안정적이고 품질 높은 제품을 배포할 수 있습니다.

3. 협업의 용이성

   • 명확한 브랜치 전략을 통해 팀 내 역할 분담이 명확해져, 개발자 간의 협업이 원활하게 이루어집니다.

마무리..

오늘은 내가 수많은 브랜치와 레포지토리 삭제를 해가며 얻어낸 Git을 이용한 협업 방법을 정리해보았다. 내 경험도 어느 정도 포함시켜서 써보고 싶었지만 설명만 하다가 쓰지 못한 게 좀 아쉬운 것 같다. 마지막으로 한 번더 샤라웃 해준다음 xy-jxn, 집에서 혼자 모든 것을 개발해서 서비스까지 하는 미친 개발자가 아니라면 이 글이 큰 도움이 되어 좋은 개발자(일단 나부터)가 되었으면 좋겠다.