[되짚기] 초보를 위한 Git 다루기 / 풀리퀘하기

 

 

프롤로그

처음 Git을 알게 됐을 때 든 생각은 이거였죠.

"이렇게 좋은 걸 왜 아무도 안 알려준 거야ㅠㅠㅠㅠ"

과거로 돌아가면 제 자신한테 "야야 이거 먼저 써 봐!!!"라고 말해주고 싶을 정도....

 

하지만 저는 웹 퍼블리싱 파트만 따로 작업하는 경우가 많아 다른 팀과 함께 쓸 일이 잘 없었습니다.

저 혼자 브랜치 만들어서 북치고 장구치고 작업하는 게 대부분이었죠 허허허 (외롭...)

 

그래도 개발자와의 협업을 위해 한 번 짚고 넘어가면 좋을 것 같아 포스팅을 시작합니다.

저(왕초보)를 기준으로 쓴 글이라 깊은 내용까지는 다루지 않았습니다.

 

히어뤼고! 🤘

 

 

 

 

 

Git 시작하기

 

Git 다운로드

git-scm.com 에 접속하여 다운로드 합니다. (참 쉽죠?)

git --version이란 명령어에 반응이 있으면 잘 설치된 것입니다.

 

 

 

Git 저장소 가입

Git의 저장소는 크게 두 가지입니다. 로컬 저장소와 원격 저장소죠.

원격 저장소는 쉽게 말하면... 클라우드에 저장해놓고 너도나도 다운로드 받아 작업할 수 있게 하는 거라고 볼 수 있습니다.

 

GitHub, GitLab, Bitbucket 등 여러 저장소 서비스 중 마음에 드는 걸 골라 PICK 해주세요.

잘 알려져 있고 많이 쓰는 건 아마 GitHub일 거라 생각하지만 개인의 취향(그리고 프로젝트의 성향)껏 선택하면 됩니다.

 

 

 

Git 초기화

자, 그럼 버전 관리를 시작할 폴더 안으로 들어가서 깃을 시작해 봅니다.

"지금부터 깃 시작한다!!!"고 큰 소리로 외치...면 좋겠지만, `git init`라고 명령을 내리면 알아듣습니다 ;)

 

그러면 .git 이라는 숨겨진 폴더가 만들어지는데요, 이게 바로 로컬 저장소입니다.

이제 우린 여기에 열심히 버전을 기록하고 원격 저장소에 올리는 작업을 할 거에요. 

 

 

 

 

Git 저장소 사용하기

 

파일 스테이지에 올리기

열심히 뚝딱뚝딱 만든 index.html의 버전을 저장해보겠습니다.

우선 git status를 입력해 봅니다. 그럼 Untracked files라면서 버전이 저장되지 않은 파일들 목록이 나옵니다.

이것을을 저장하려면 인덱스에 추가하는 작업이 필요한데요, 이 과정을 '스테이지에 올린다'고도 말합니다.

 

git add <파일 이름>또는 git add .으로 일부(전체) 파일을 인덱스에 추가합니다.

 

어이쿠 파일을 잘못 올렸네! 싶을 때는 git reset 또는 git reset <파일 이름>으로 취소(reset) 할 수 있습니다.

 

 

 

파일 커밋하기

스테이지에 올리기만 해선 버전이 저장되지 않으므로, "커밋"이라는 작업을 해줘야 합니다.

말하자면... 요리를 내놓기 전에 카운터에 일단 올려놓은 다음, 이상이 없는지 살펴보고 "오케이! 이거 나가도 돼!"하는 느낌이죠.

 

그런데 그냥 커밋하면 나중에 '이걸 왜 커밋했지..?' 싶을 때가 오겠죠.

그래서 이런저런 내용을 수정했고, 뭐가 추가되고 삭제됐다~ 이런 내용들을 함께 적어주는 것이 좋습니다.

제일 쉽고 간편하게 커밋하려면, git commit -m "<이 확정 버전에 대한 설명>"이라고 쓰면 됩니다. 

커밋 메시지는 "영어로 / 대문자로 시작 / 동사 원형으로 / 짧게" 작성하면 좋습니다.

 

커밋을 취소하려면 git reset HEAD^로 커밋을 하나만큼 되돌릴 수 있습니다.

 

 

 

원격 저장소에 넣어주기

이제 파일은 로컬 저장소의 HEAD란 곳에 있습니다.

이것들을 원격 저장소에도 넣는 작업, 즉 'PUSH(푸쉬)'를 진행해 보겠습니다.

 

우선 git remote add origin <원격 서버 주소>로 원격 저장소의 위치를 알려줍니다.

여기서 origin은 원격 저장소의 이름에 해당합니다.

 

그런 다음 git push origin master로 원격 저장소에 밀어넣어 줍니다.

 

 

 

브랜치 만들기

처음 Git을 만든 상태라면 기본적으로 master라는 브랜치를 갖습니다.

이름이 괜히 마스터가 아니므로, 작업자들은 뿔뿔이 흩어져서 각자의 브랜치에서 작업을 해줍니다.

그리고 개발이 완료되면 master 브랜치로 돌아와 병합(MERGE, 머지)해주면 됩니다.

 

git checkout -b <브랜치 이름>은 해당 브랜치를 만들고 그 브랜치로 갈아타는 명령입니다.

이 브랜치 저 브랜치 왔다갔다 하는 걸 checkout이라고 생각하면 됩니다.

이때 git checkout -b feature/userProfile 이런 식으로 카테고리 내 브랜치를 생성할 수도 있어요.

 

브랜치 삭제는 git branch -d <브랜치 이름>으로 가능합니다.

 

아까 push한 건 마스터 브랜치였으니, 새롭게 만든 브랜치에서도 push를 해줘야 합니다.

git push origin <브랜치 이름>을 해주면 됩니다.

 

 

 

원격 저장소의 내용 가져오기

이제 제가 작업한 내용을 공통 브랜치랑 합쳐보겠습니다.

하지만 합치기 전!!!에 반드시 누군가 변동사항을 올려놓지는 않았는지 확인해야 합니다.

git pull을 하면 원격 저장소의 변경 내용이 자동적으로 받아지고(fetch), 병합(merge) 됩니다.

 

'앗, 나는 확인만 하고 병합은 내가 하고 싶은데...' 싶을 땐 git fetch로 원격 저장소의 최신 이력을 확인할 수 있습니다.

 

 

 

원격 저장소와 결합하기

현재 브랜치에다 다른 브랜치의 내용을 머지(merge)하려면 git merge <브랜치 이름>을 실행합니다.

이따금 충돌이 발생하기도 하는데... 그럴 땐 심호흡을 하고 하나씩 해결해 나가야합니다^_ㅠ

 

 

 

풀 요청하기

 

 

풀 리퀘스트

대형 프로젝트의 경우 충돌을 최소화하기 위해 머지 전에 "이거 확인해주세요!"라고 요청하기도 합니다.

이후 담당자가 검토하고 머지하여 업데이트를 반영하게 됩니다. 

이걸 Pull Request(PR)이라고 합니다.

 

아, 하지만 저도 실은 써본 적이 없어서..... 여기서부터는 약간의 상상력(?)을 발휘해 써봅니다.

 

기본 흐름은 아래와 같습니다.

 

1. 한 사람이 개발하는 브랜치를 만듭니다. feat/개발 기능, fix/버그이름, hotfix/급한버그 이름 이런 식으로요.

2. 이후 공동 브랜치(dev 등)로 PR(풀리퀘)을 보냅니다.

3. 리뷰를 거쳐 작업한 내용이 공동 브랜치에 머지됩니다.

4. 여러 사람들의 작업 내용이 모두 머지되면 최신 버전 브랜치(release, latest 등)로 머지 후 배포합니다.

 

 

시험삼아 한 번 작업해보죠!

저는 이 저장소의 Collaborator입니다.

저장소를 clone 해서 살펴보니 브랜치 구조가 저렇게 되어 있네요.

 

저는 feature/userProfile 부분을 담당하기로 했습니다.

그래서 열심히 뚝딱뚝딱 만들어서 커밋하고 푸시까지 마쳤습니다.

 

 

 

 

 

 

 

 

 

 

그럼 nana-like 계정(저에요!)이 조금 전 userProfile을 푸쉬했다고 뜨는 걸 볼 수 있어요.

제 할 일은 다 끝난 거 같으니 dev 브랜치에 머지하면 될 거 같아요.

우측의 Compare & pull request 버튼을 눌러 PR을 요청할 수 있습니다.

 

 

 

dev 브랜치에 제가 만든 걸 머지해도 될까요? 라고 요청하는 거죠.

필요한 내용을 써서 Create pull request를 누르면...

 

 

풀 리퀘스트가 생성된 걸 볼 수 있습니다.

nana-like가 feature/userProfile에서 1커밋을 했고 그걸 dev에 합치고 싶어한대요~!! 라고 잘 알려주네요.

그럼 다른 작업자나 담당자가 해당 사항을 보고 머지할지 판단하겠죠?

 

 

 

담당자는 이 PR에 코멘트를 남기거나, 승인하거나, 수정을 요청할 수 있습니다.

시험삼아 한 번 빠꾸시켜 볼게요 :P

 

 

 

그랬더니 새롭게 업데이트를 해주었습니다. 

 

 

이번에는 요청사항을 다 해결했고 오류도 없기에 Approve를 해줍니다.

 

 

그럼 1 approval이 생긴 걸 볼 수 있습니다.

필요한 approval을 모두 받거나 머지해도 될 거 같으면 Merge pull request를 눌러줍니다.

 

 

이렇게 Merge 까지 마치면 풀리퀘가 closed됩니다. (짝짝짝)