Git, 왜 쓰는거야?

유시온·2023년 3월 23일

git

원본 내용은 여기서 확인 가능합니다. 틀린 내용이나 이상한 부분이 있다면 피드백 주세요!

🤨 Git 사용하고 있긴 한데..

Git 사용하고 있긴 한데.. 어떤 것인지, 왜 쓰는 것인지 생각해보신 적 있나요??

“남들이 다 사용해서요” “기업 요구사항에 있어서요” 아직도 그렇게 대답하실 건가요?? 이제부터 git이 어떤 것이고, 왜 쓰는지 알아봅시다!

Git 이란?

git은 컴퓨터 파일의 변경 사항을 추적하고 여려 명의 사용자 간에 해당 파일들의 작업을 조율하기 위한 스냅샷 스트림 기반의 분산 버전 관리 시스템이다. 라고 위키 백과에 나와 있는데요. 간단하게 말하자면 버전 관리 시스템이라고 생각하시면 됩니다.

왜 Git을 쓰나요?

만약, TodoList 프로젝트를 제작하고 있다고 가정해 봅시다. 투두 삭제 기능을 추가하려다가 로직이 꼬여 다시 원래대로 돌아가려고 합니다. 그런데요, 어떻게 돌아가시게요? ctrl + Z 계속 누르면서 돌아갈 건가요?? 아니죠. 이럴 때 Git을 사용하는 겁니다.

Git은 프로젝트의 각각 버전을 관리하며, 여러 명이 동시에 한 코드를 가지고 작업하는 병렬적인 작업이 가능하기 때문에 개인 프로젝트이던 팀 프로젝트든 구별하지 않고 사용하는 거예요!

Git에서 중요한 개념 - commit

commit이란 변경 사항을 기록하는 것입니다. 내 프로젝트에서 변화를 기록해 버전을 기록하는 행위라고 생각하시면 됩니다. 프로젝트 완성에 점점 다가가며 기억해두는 것, 즉 발자국으로 비유할 수 있겠네요.

Git에서 중요한 개념 - branch, conflict

commit을 발자국으로 비유했다면, branch는 git에서 좁은 길이라고 생각하면 됩니다.

만약에 제가 TODO 추가 기능 부분을 제작하고 있었는데, 옆에 친구가 갑자기 TODO 삭제 기능을 제작하고 싶다고 합니다. 이렇게 둘이 같은 좁은 길에서 걷다보면 언젠가는 부딪혀 충돌하게 될 것입니다.
이러한 개념을 git에선 conflict 라고 합니다.

conflict는 각각 기능을 개발하다가 변경 사항이 충돌한 것입니다.

이런 상황에서는 어떻게 하면 될까요? 간단하게 생각하자면 한 명이 다른 길로 가면 되겠죠?
그래서 branch라는 개념이 있는 겁니다. 이렇게 다른 길로 각자 걸어가면 충돌 날 일이 줄어들기 때문에 branch를 사용합니다. 즉, conflict를 줄이기 위해 Git-flow, Github-flow 전략을 사용하는 겁니다.

Git에서 중요한 개념 - merge

각자 좁은 길을 평생 혼자 걸어갈 수는 없을 겁니다. 가끔 문제가 생기면 만나서 의논하고 서로 도와줘야죠. 각자 길에서 잠깐 만나서 합치는 과정을 merge라고 합니다.

만약 제가 A라는 길에 있고 친구는 B에 있습니다. A에서 걷고 있는데 갑자기 비가 옵니다.
하지만 우산은 친구한테 있습니다. 이럴때 A에서 B로 가든 B에서 A로 가든 서로를 돕는 것이 merge 입니다.

😓 Github 계정만 있고 잘 쓰진 않아요

Git은 뭔지 아는데 Github은 잘 사용하진 않아요…

Github란?

깃을 지원하는 웹 호스팅 서비스 중 한 종류입니다. 그 외에도 GitLab, BitBucket 등이 있지만 주로 Github을 많이 사용합니다!

Git !== Github

Git이랑 Github 차이점이 뭔지 아시나요??

Git은 Git! Github는 Git + Hub라고 생각하세요. Git은 내 프로젝트를 버전별로 관리해주는 시스템이고 Github는 내 Git들이 관리해준 버전을 웹으로 모아둔 호스팅 서비스입니다! 쉽게 말해 Git을 웹에서 더 편하게 쓸 수 있도록 만든 저장소이죠.

Github에서 중요한 개념 - repository

repository란 말 그대로 저장소 즉 파일이나 폴더를 저장해두는 곳입니다. 우리 커밋하고 브랜치 나누고 그런 걸 레포지토리라는 공간 안에서 하는 거로 생각하시면 됩니다.
ex ) https://github.com/yoosion030/codingtest

Github에서 중요한 개념 - 브랜치 전략, git-flow

아까 위에서 설명했듯이 git-flow는 conflict를 줄이기 위한 브랜치 전략입니다. 충돌하지 않게 각자 좁은 길을 걸어가다 무슨 일이 생겼을 때 중간에 잠깐 만나 이야기하고, 다시 각자 좁은 길을 걸어가는 방식입니다.

git-flow에는 5가지 종류의 브랜치가 존재합니다.

master(main) : 제품으로 출시되는 브랜치
develop : 다음 출시 버전을 ‘개발’하는 브랜치
feature : 기능을 개발하는 브랜치
release : 이번 출시 버전을 준비하는 브랜치
hotfix : 출시 버전에서 발생한 이슈를 수정하는 브랜치

이렇게 각각의 길에서 본인의 역할을 수행하기 때문에 충돌이 잘 발생하지 않아 협업할 때 자주 사용합니다.

Github에서 중요한 개념 - Pull Request

위에서 merge에 대해 설명했죠?? Github에서는 다른 브랜치에서 또 다른 브랜치로 merge하기 위해서는 Pull Request라는 과정이 필요합니다.

제가 A라는 길에서 걷고 있다가 친구가 있는 B 길에서 쉬고 싶은 겁니다. 하지만 저는 A라는 길에서 commit이라는 짐이 있습니다. 그렇기 때문에 친구한테 내 짐을 가지고 B에서 쉬어도 되냐고 물어보는 과정이 Pull Request입니다.

예를 들어 feature/sion 브랜치에 있는 코드를 develop 으로 합치고 싶다면,

github repository에 있는 Pull Request 탭에 들어갑니다.
그러고 new pull request 버튼을 클릭합니다.
어느 브랜치에서 어느 브랜치로 브랜치로 이동할 것인지 선택합니다. (거꾸로 되지 않게 신중히 선택)

이렇게 branch를 선택해주면 아래와 같이 코멘트를 적을 칸이 있을 겁니다.

이 코멘트에는 내가 어떤 것들을 변경해주었는지 작성해주면 PR 과정이 끝난 것입니다! 아래 Merge pull request 버튼을 누르게 되면 feature/sion 에서의 변경 사항이 develop 으로 이동이 된 겁니다!

Github에서 중요한 개념 - Code Review

협업의 꽃이자 프로젝트 할 때 가장 중요한 부분입니다.

아까 A라는 길에서 B라는 길로 이동하려고 요청하는 과정을 PR이라고 했죠? 그럼, 요청 후에는 어떻게 진행될까요? 무작정 요청하는 사람을 다 받아줄 수는 없으니 PR 과정 후에 코멘트와 변경 사항을 검토하는 과정을 코드 리뷰라고 합니다! 이 과정에서는 각 커밋의 내용과 전체 변경 사항을 확인할 수 있습니다.

PR에 들어가 Files changed 탭에 들어갑니다.

해당 탭에서 변경 사항들을 확인할 수 있습니다.
Review changes 버튼을 누릅니다.

그러면 이렇게 코멘트 박스가 나옵니다.
- Comment : 해당 PR에 대한 의견
- Approve : 해당 PR을 승인
- Request changes : 해당 PR을 거절 ( 변경 사항을 제안 )

특정 코드에 대해 자세한 리뷰를 할 수 있습니다.

마무리

git은 프로젝트를 각각 분기마다 저장하는 버전 관리 시스템이다.
커밋은 변경사항을 기록하는 것이다. 프로젝트 완성이라는 목표를 위해 기록해 두는 것, 발자국
브랜치는 분기, 발자국을 남기는 좁은 길이다. 좁을 길이라 같이 걸어가면 충돌이 일어나기 때문에 각자 길을 걸어간다. 이것을 브랜치 전략이라고 하며 예시로는 git-flow, github-flow가 있다.
각자 걸어가다 서로 도와주는 것, 발자국(커밋)을 합치는 것을 merge라고 한다.
github는 git을 더욱 더 편하게 사용하게 제공해주는 웹 호스팅 서비스이다.
repository는 저장소이다. 발자국과 좁은 길이 남겨지는 곳이다.
pull request는 merge과정 전에 요청하는 것이다.
code review는 pr을 검토하며 merge 해도 되는지 확인하는 과정이다.

우리는 왜 git을 사용하는 것일까?

다 우리들을 위해서이다. 버전을 관리하며 프로젝트 품질을 향상하고, 안정적으로 운영하기 위해 사용한다. 어떤 기술이든 왜 사용하는지 생각해보는 것이 중요하다. 다 개발자들을 위한 것이다. 왜 사용하는지 알아갈수록 더욱 깊이 개념을 알게 된다.

앞으로 자기 자신을 위해 언어든 프레임워크든 라이브러리든 왜 사용하는지 어떤 점이 좋은지 다시 한번 생각하고 이해하며 사용하자! 이해할 때는 자신이 이해한 대로 비유하면서 정리하는 습관도 들이면 좋을 것 같다 :)