Git_2. 워크플로우 (solo)

기본 구성

git의 워크플로우를 살펴보기에 앞서서 구성 요소를 보면 다음과 같다.

• Remote: 원격 저장소로 최종적인 작업물이 업로드되어있는 서버 저장소
• Local: 로컬 저장소로 내 PC에서의 작업
  1) work space: 실제 작업이 진행되는 공간으로 작업 후에 add(staging area로 이동), 혹은 restore(변경사항 폐기) 진행
  2) staging area: work space에서 add를 통해 추가된 내용을 commit 가능한 상태로 담는 공간
  3) stash: 아직 마무리하지 않은 작업을 저장하는 공간으로 커밋을 할 수는 없는 상태지만, 브랜치 전환을 하거나 커밋 변경을 해야 할 때 임시로 저장할 수 있는 스택

이를 토대로 git 사용의 기본적인 구조를 보면
1. Remote 저장소에서 필요한 내용을 clone 하여 내 Local 저장소로 불러온 후,
2. 작업한 내용을 add(to staging area), commit(to repo) 하여
3. 최종적으로 다시 push(to remote repo) 해주는 과정으로 구성된다.

작업은 다시 혼자 작업하는 경우와 페어와 함께 remote 저장소를 공유하는 경우로 나누어 볼 수 있다.

혼자 작업하는 경우

혼자서 작업하는 경우의 워크플로우는 다음과 같이 이루어진다.

1. Fork / Repo 생성

먼저 나의 Remote 저장소에 작업할 repo를 생성해야 한다. 만약 다른 사람의 작업물을 가져오는 경우엔 Fork를 통해서 나의 Remote 저장소로 복사해올 수 있다. 이는 다음과 같이 Github 저장소에서 Fork 버튼을 통해 할 수 있다.

혹은 단순히 나의 Github repositories 페이지 안에서 New 버튼을 통해 새로운 저장소를 생성할 수도 있다.

또한 로컬 환경에서 작업중인 내용을 git init을 통해 git의 관리하에 두고, add, commit을 통해 Local 저장소를 생성하는 방법도 있다.

$ git init
$ git add .
$ git commit -m 'initial project version'

2. Clone

이제 작업을 위해 Remote 저장소의 내용을 나의 Local 저장소로 clone 해주어야 한다. 이는 다음 CLI 명령어를 통해 복사할 수 있다.

$ git clone <repository 주소>
$ git clone https://github.com/myUsername/practice.git

이를 통해 다음과 같이 Local 저장소에도 같은 내용이 복사되었다.

3. Add

저장소 설정이 완료되면 work space에서 작업을 시작한다. 이는 실제로 vscode 등을 이용해 코드를 작성하는 과정으로, 완료된 작업은 다음과 같은 add 명령어를 통해 staging area로 올려준다.

$ git add <add 할 파일명>
$ git add index.js

$ git add .

add 명령어는 뒤에 추가할 파일명을 써주거나, 단순히 .으로 현재 디렉토리 내의 모든 변경사항을 추가할 수도 있다.

혹은 다음과 같이 -p를 이용하면 각 변경사항을 하나하나 확인하여 staging area로 넘겨줄 수 있다.

$ git add -P

이러한 동작이 제대로 이루어졌는지 확인하기 위해 status를 사용할 수 있다. 만약 변경된 사항이 아직 add 되지 않은 상황에서 다음과 같이 status 명령을 입력하면

$ git status

changes not staged for commit:
...
modified: index.js

위와 같이 변경되었지만 add 되지 않은 파일을 알려준다.

만약 변경사항을 추가하지 않고 폐기하고 싶다면 다음과 같이 restore를 이용할 수 있다.

$ git restore index.js

4. Commit

staging area에 커밋을 위한 변경사항의 묶음이 모이면 이를 Local 저장소에 다음과 같이 Commit 해준다.

$ git commit -m `커밋 메세지`

여기서 주의할 점은, 커밋은 각각의 변경 시점을 기록하는 것이기 때문에 이를 구분하기 위한 메세지를 반드시 함께 첨부해야 한다. 커밋은 작성 방법에 대한 수 많은 컨벤션이 존재하며, 반드시 작업을 함께하는 팀과 일관성을 유지하도록 작성하여야 한다. 일반적으로 커밋 메시지는 직관적으로 변경사항을 표시할 수 있도록 과거형 등이 아닌 동사 형태로 (ex) Fix typo in introduction) 작성한다. 커밋 컨벤션에 대해 정리한 글을 등을 참고하면 추가적인 도움이 될 수 있다.

만약 commit 내용을 취소하고 싶다면 다음과 같이 reset 명령을 사용할 수 있다.

$ git reset HEAD~^

reset 뒤에는 HEAD와 제거할 커밋의 수를 나타내는 ^로 이루어진다. ^는 ~1과 같이 작성할 수 있으며, ^ 하나는 1을 나타낸다. 따라서 앞의 3개 커밋까지 취소하고 싶다면 HEAD^^^, 혹은 HEAD~3과 같이 작성할 수 있다.

5. Push

이제 Local 저장소에서 작업한 내용을 최종적으로 Remote 저장소로 합쳐주어야 한다. 이는 다음과 같이 Push를 이용한다.

$ git push <저장소> <브랜치>
$ git push origin main

push 뒤에는 추가할 저장소와 브랜치를 입력하며, 기본적으로는 origin 레포의 main(혹은 master) 브랜치로 설정되어 있다. 만약 정확한 저장소 명을 알고 싶다면 다음과 같이 remote 명령어를 사용할 수 있다.

$ git remote
origin

이를 통해 최종적으로 Local 저장소의 내용을 Remote 저장소와 일치시켰다.

만약 최초 Remote 저장소를 Fork를 통해 가져온 경우라면 원 작성자의 저장소에 pull request(pr)를 보내 변경사항을 merge 할지를 물어볼 수 있다. 만약 pr이 성공하면 최종적으로 나의 Remote 저장소와 상대방의 Remote 저장소의 파일이 같아지게 된다.

페어와 함께 작업하는 경우는 다음 글을 통해 이어서 설명하려 한다.

참고
Engineering Blog by Dale Seo - Git
CHRIS BEAMS - How to Write a Git Commit Message