Git의 버전 관리 기능 활용 (1)

Intro

git으로 관리하며 누구나 contribute 할 수 있게 허용해 놓은 오픈 소스 프로젝트가 있다면 어떻게 contribute를 할 수 있을까요?

우선 전체적인 청사진을 통해 Github의 workflow를 살펴봅시다!

1. Remote에 있는 다른 Repository에서 Fork를 해서 Remote에 있는 내 Repository에 가지고 옵니다.

2. 그리고 이 코드를 수정하기 위해서는 내 컴퓨터로 가져오는 작업이 또 필요합니다. 내 컴퓨터에서 작업을 하기 위해서 clone을 합니다.

3. 이제 내 컴퓨터의 작업 공간 (work space) 에서 작업에 들어간 파일들을 git의 관리 하에 있는 상태로 올려줄 수 있습니다. 이 영역을 staging area라고 합니다. 즉, staging area에 들어오지 않은 파일은 unstaged 혹은 untracked file이라고 말하며, staging area에 있는 파일들은 staged 된 파일이라고 말할 수 있죠.

4. staging area에 들어온 파일들은 commit이 가능합니다. commit을 하고 나면 내 remote repository에 push 해서 commit 기록을 remote 에도 남겨줄 수 있습니다.

5. push를 완료한 후 이제 remote의 원래 레파지토리에 pull request를 보내면 Remote Repository로 내가 수정한 코드를 업로드할 수 있습니다.

이제 각 단계들에서 구체적으로 어떤 일이 일어나는 지 알아봅시다.

Contribution Step

Fork

Git으로 관리되고 있는 igNIte-project 라는 프로젝트가 있다고 가정을 해봅시다.
이 Repository에 contribute를 싶다면, 먼저 내 계정으로 이 Remote Repository를 가지고 와야 합니다.

이 때 사용하는 기능이 Fork입니다. 포크로 집어서 복사해 온다는 의미라고 생각하시면 됩니다.

git clone

git clone <프로젝트명>
ex> git clone igNIte-project

이제 Remote Repository에 있는 파일을 작업하기 위해서는 내 컴퓨터로 복사해오는 작업이 필요합니다. 이 때 사용할 수 있는 명령어가 바로 clone입니다.
git clone 명령어 뒤에 Repository 주소를 입력하면 해당 Repository를 내 컴퓨터(Local Repository)로 가져와서 작업할 수 있습니다.

git status

igNIte-project를 Fork해서 기능을 구현했다고 가정해 봅시다. commit으로 변경 사항의 저장 기록을 남겨두는 것이 좋습니다. commit을 하기 위해서 먼저 현재 Local Repository에 변경된 파일들이 어떤 것이 있는지 확인해 보려고 합니다.

git status 명령어를 통해 staging area와 untracked files 목록에 어떤 것들이 있는지 확인할 수 있습니다.

git status <프로젝트명>
ex> git status igNIte-project

해당 명령어를 입력하면, 터미널은 우리에게 상황에 따라 사용할 수 있는 명령어를 안내합니다.

[add] : add는 파일을 commit 할 수 있는 상태로 만들어 줍니다. 이에 대한 자세한 내용은 뒤에서 봐보죠.
[restore] : 변경사항을 폐기(discard changes) 하는 명령어입니다. 이처럼 git status 를 통해 어떤 파일이 어떤 상태에 있는지, 그리고 해당 파일에 대해 어떤 행동을 할 수 있는지 알 수 있습니다.

그런데 갑자기 코드에 심각한 문제나 에러가 발견돼, 작업한 코드를 싹 다 밀어 버리고 새로 작업해야 할 것 같습니다. 처음 clone을 받았던 상태로 되돌리는 방법이 있을까요?

git restore

바로 위에서 안내됐던 git restore 명령어를 통해 commit되지 않은 Local Repository의 변경 사항을 폐기할 수 있습니다.

git restore <파일명>
ex> git restore igNIte_index.js

git add

문제없이 코드가 작동되는 것이 확인됐다면 드디어 commit을 할 차례입니다.

commit을 하기 위해서는 먼저 Git의 관리 하에 있는 영역인 staging area로 파일들을 옮겨줘야 합니다. 이 것을 실행시킬 수 있는 명령어가 바로 git add.

git의 트래킹이 되고 있지 않은 파일들에서 git의 관리 하에 있는 staging area 로 파일들을 추가하는 명령어는

git add <파일이름> 

입니다.

하지만 경우에 따라서 한꺼번에 많은 파일을 add해야하는 경우 또한 존재할 것입니다. 이럴 때는

git add .

명령어로 staging area에 unstaged 상태인 모든 파일을 한번에 추가할 수 있습니다. 하지만 이 명령어를 사용할 때는 올리지 말아야 할 파일까지 모두 add될 수 있기 때문에 주의해야 합니다.

git commit

이제 add를 통해 파일이 staging area에 올라간 상태이기 때문에 commit이 가능한 파일이 되었습니다.

git commit -m <commit_message>

commit 메시지 작성 방법에 대해서는 굉장히 다양한 기준과 컨벤션이 있기 때문에 좋은 commit 메시지를 작성하기 위한 많은 기준들을 찾아보면 좋습니다. 하단의 링크를 참조해주시기 바랍니다.

commit 메시지를 작성하기 위한 기준

여기서 staging area라는 영역에 대한 의문이 생길 수 있습니다. staging area에 있는 파일만 commit이 가능하다고 하였는데, 이를 간편한 예시를 통해 이해해보도록 합시다.

만약에 여러분이 이사를 가기 위해서 물건을 무빙 박스에 담아야하는 상황을 가정해 보겠습니다.

무빙 박스에는 물건을 넣을 수도 있고 꺼낼 수도 있습니다. 주방, 거실, 침실의 물건들을 같은 상자에 섞으면 나중에 꺼내어 볼 때 불편할 것이므로, 같은 용도의 물건들을 한 박스에 넣는 것이 좋을 겁니다. 물건들을 박스에 모두 담았다면 밀봉 후 라벨링을 해서 각각의 용도를 적어 주면 나중에 박스를 열어볼 때 편하겠죠.

여기서, 이 무빙 박스가 바로 commit 을 만들 수 있는 staging area이고 박스에 어떤 용도의 물건인지 간단한 코멘트를 적은 라벨링을 해 주는 것이 바로 commit 이라고 이해해 주시면 좋겠습니다.

git의 Local Repository에는 Git이 관리하고 있지 않은 Untracked area라는 영역, 관리하고 있는
Tracked area라는 영역이 있으며 그 Tracked area 내부에서도 세 가지 상태로 나누어집니다.


그 세 가지 상태가 바로 Unmodified, Modified, Staged입니다.

Unmodified : 기존에 Commit했던 파일을 수정하지 않은 상태입니다.

Modified : 기존에 Commit했던 파일을 수정한 상태입니다.

Staged : commit이 가능한 상태입니다. 수정한 파일을 commit 하기 위해서는 staged area에 add 하는 작업이 필요합니다.

그래서 add 명령어를 통해 tracked area에 들어간 파일을 수정하게 되면 다시 modified 상태가 되기 때문에 다시 add하는 작업을 통해 파일을 staged 해 주는 작업이 필요합니다.

git push

commit 기록을 남기기를 완료했으니, 이제 이 파일들을 contribute 하기 위해서는 Pull Request 라는 것을 시행해줘야 합니다.

Pull Request를 시행하기 위해서는 현재 Local Repository에 저장되어 있는 commit 기록들을 내 Remote Repository 에 업로드해 줘야 합니다. 내 Local Repository의 commit 기록들을 Remote Repository로 업로드하기 위해서는

git push <origin> <branch>

명령어를 사용할 수 있습니다.

Pull Request는 내가 Remote Repository에 Push 해 놓은 변경 사항에 대해서 함께 작업하는 다른 사람들에게 알리는 것을 뜻합니다. 현업에서는 줄여서 PR이라고 합니다.

Pull Request를 하고 나면 push 해 놓은 내용을 간단하게 요약해서 알려줌으로서 다른 개발자들이 코드를 보지 않고도 어떤 내용인지 쉽게 파악할 수 있게 도와줄 수 있습니다. 이를 통해 내가 올린 작업을 기존 코드에 병합할 수도 있고, 더 수월한 개발이 가능하도록 이끕니다.

Outro

이번 시간에는 git의 contribute 과정에 대해 알아보았습니다. 다음 포스팅에서는 여러 명이 함께 workflow를 진행할 때 어떤 차이가 있는지 살펴보도록 하죠. 또한 이번 시간에 다루지 않은 git의 명령어는 아주 많으므로, 누락된 부분은 차차 배워나가도록 해봅시다.