(1-2) Git 혼자 작업 Workflow

 

[그림] Git으로 혼자 작업할 때의 전체적인 흐름을 그려낸 표

 

 

1. Remote에 있는 다른 Repository에서 Fork를 해서 Remote에 있는 내 Repository에 가져온다.

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

3. 이제 내 컴퓨터의 작업공간(work space) 에서 작업이 들어간 파일들을 git의 관리 하에 있는 상태로 올려줄 수 있는데, 이 영역을 staging area라고 한다. 

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

5. push를 완료한 후 remote의 원래 repositary 에 pull request 를 보내면 Remote Repository 로 내가 수정한 코드를 업로드할 수 있다.

 

 

 

Fork 

다른 계정의 Remote Repository 를 내 계정으로 가지고 올 때

 

 

우측 상단의 Fork 버튼을 누른 뒤 나의 유저 네임을 클릭하면 Fork 작업이 완료된다.
Github.com 의 내 계정에 Fork해서 들어온 username / git-project는 나의 Remote Repository (원격 저장소) 이다.
내가 git-project를 Fork한 시점부터 이 git-project는 나의 Repository에 복사본으로 저장된 것이다.

(Fork가 완료된 상태는 내 Remote Repository에 username/ git-project라는 이름의 Repository가 들어 있는 상태이다.)

 

 

 

git clone

원격 Repository를 내 로컬에서 이용할 수 있도록 복사

 

 

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

git clone <Repository 주소>

[커맨드] git clone 명령어 뒤에 Repository 주소를 붙여서 명령을 실행할 수 있다.

 

 

git status

내 로컬로 복사해 온 디렉토리의 commit 되기 전 상태를 표시

 

 

git-project를 Fork 해서 마이페이지 기능을 구현했다고 가정해보자. commit으로 변경 사항의 저장 기록이 남겨두는 것이 좋을 것이다. commit을 하기 위해서 먼저 현재 Local Repository에 변경된 파일들이 어떤 것이 있는지 확인해 보려고 한다. git status 명령어를 통해 staging area와 untracked files 목록에 어떤 것들이 있는지 확인할 수 있다.

git status

[커맨드] 내 로컬의 staging area, untracked files 목록을 확인할 수 있다.

 

 

Staging area 란?

Commit 하기 전에 내용을 기록하는 장소

 

 

staging area에 있는 파일만 commit이 가능하다고 하는데 도대체 staging area가 무엇일까?
우리가 이사를 가기 위해서 물건을 무빙 박스에 담아야하는 상황을 가정해보자. 무빙박스에는 물건을 넣을 수도 있고 꺼낼 수도 있다. 주방, 거실, 침실의 물건들을 같은 상자에 섞으면 나중에 꺼내어 볼 때 불편할 것이다. 같은 용도의 물건들을 한박스에 넣는 것이 좋을 것이다. 물건들을 박스에 모두 담았다면 밀봉 후 라벨링을 해서 각각의 용도를 적어 주면 나중에 박스를 열어볼 때 편할 것이다.

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

만약에 git add 명령어로 staging area 에 올려 놓은 상태인데 파일을 또 수정한다면 어떻게 될까?

 

 

터미널에 보이는 것처럼 파일이 staged 이면서 modified 인 상태가 된다.
이 시점에서 터미널은 우리가 선택할 수 있는 행동을 안내하고 있다. 즉 git add 명령을 실행하면 Git 은 파일을 바로 Staged 상태로 만든다. 지금 이 시점에서 commit을 하면 git add 명령을 실행해서 staged 되어 있는 파일만 commit 된다. 그러므로 git add 명령을 실행한 후에 또 파일을 수정한다면 git add 명령을 다시 실행해서 최신 버전을 Staged 상태로 만들어야 한다.

git status 를 통해 어떤 파일이 어떤 상태에 있는지, 그리고 해당 파일에 대해 어떤 행동을 할 수 있는지 알 수 있다.

 

 

Git 의 세 가지 영역 및 상태란?

Committed, Modified, Staged

 

 

git의 Local Repository 에는 다음 영역들이 있다. Untracked area 는 Git 이 관리하고 있지 않은 영역이다. Tracked area 에 들어온 파일들만 Git의 관리를 받을 수 있으며, Tracked area 내부에서도 세 가지 상태로 나누어진다.

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

• Unmodified : 기존에 Commit 했던 파일을 수정하지 않은 상태이다.
• Modified : 기존에 Commit 했던 파일을 수정한 상태이다.
• Staged : commit 이 가능한 상태이다. 수정한 파일을 commit 하기 위해서는 staged area에 add 하는 작업이 필요하다.

 

위 그림을 통해 위 터미널 내용을 다시 복습해 보자. Changes to be committed 라고 적혀 있는 초록색 파일은 staged 상태의 파일이며 Changes not staged for commit 이라고 적혀 있는 빨간색 파일은 Modified 상태의 파일이다.
그래서 add 명령어를 통해 tracked area에 들어간 파일을 수정하게 되면 다시 modified 상태가 되기 때문에 다시 add 하는 작업을 통해 다시 파일을 staged 해주는 작업이 필요하다.

 

 

 

 

git restore

Commit 혹은 staged 되지 않은 변경 사항을 폐기

 

 

기존에 있던 코드들을 훑어보니 코드 작성 방식이 나와 달라서 통일성을 해칠 것 같다. 내가 작업한 코드를 싹 다 밀어버리고 새로 작업해야 할 것 같은데 처음 Clone을 받았던 상태로 되돌리는 방법이 있을까?

이 때 사용할 수 있는 명령어가 restore 이다. commit 되지 않은 Local Repository 의 변경 사항을 폐기할 수 있다.

git restore <파일명>

[커맨드] commit 되지 않은 Local Repository 의 변경사항을 취소할 수 있다.

 

 

git add

Untracked files 를 Staging area로 추가해서 Git의 관리하에 둠

 

 

commit을 하기 위해서는 먼저 Git의 관리 하에 있는 영역으로 파일들을 옮겨줘야 한다. 이 영역의 이름은 바로 staging area이다.
git의 트래킹이 되지 않고 있는 파일들에서 git의 관리 하에 있는 staging area 로 파일들을 추가하는 명령어는 git add <파일이름> 이다. git add 를 했을 때 터미널 창에는 변화가 없다.

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

 

 

git add <파일명>

[커맨드] 내 Local 의 untracked file을 Git의 관리 하인 staging area로 추가할 수 있다.

 

git add.

[커맨드] Staging area에 모든 파일을 한번에 추가할 수 있다.

 

 

git commit

수정 작업이 끝났을 때 변경 사항을 저장

 

 

변경사항을 저장하기 위해서는 commit을 활용한다. 어떤 사항이 변경됐는지 간단한 메모를 통해서 버전의 변경 기록들을 관리할 수 있다. commit 메시지를 작성하기 위해서는 -m 옵션을 통해 코멘트를 작성할 수 있다.

git commit -m '커밋 메시지'

[커맨드] -m 옵션을 통해 커밋할 내용의 코멘트를 작성할 수 있다.

 

 

git reset

Local 에서 commit 한 내용을 취소할 때

 

 

아직 Remote Repository에 업로드 되지 않고 Local Repository에만 commit 해 놓은 기록이라면 reset 명령어를 통해서 commit을 취소할 수 있다. git reset 를 했을 때 터미널 창에는 변화가 없다. git reset HEAD^ 라는 명령어로 가장 최신의 commit 을 취소할 수 있다. 방금 올린 하나의 commit 만 취소하면 되기 떄문에 git reset HEAD^ 명령어를 입력하는 것이 가장 적절할 것이다.

git reset HEAD^

[커맨드] 아직 Remote Repository 에 올라가지 않은 commit 이면 reset 명령어로 취소할 수 있다.

 

추가적으로 hard, soft, 옵션도 있는데 reset 에 대해 더 공부하고 싶다면 git --hard vs --soft 등의 검색어로 구글링 한 후 실습해보는 것을 추천한다.

 

 

git push

Local 에서 변경 , commit 된 사항을 Remote Repository에 업로드

 

 

commit 기록을 남기기를 완료했다. 이제 이 파일들을 contribute 하기 위해서는 Pull Request 라는 것을 날려줘야 한다.
Pull Request 를 날리기 위해서는 현재 Local Repository 에 저장되어 있는 commit 기록들을 내 Remote Repository 에 업로드해 주어야한다.

git push <origin> <branch>

[커맨드] 리모트에 있는 origin의 master 브랜치에 Local Repository 의 변경 사항을 업로드하기 위해서는
git push origin master 라고 입력하자.

 

git log

현재까지 commit 된 내역들을 터미널 창에서 확인할 수 있다.

git log

[커맨드] 현재까지 commit 된 로그들을 터미널창에서 확인할 수 있다. 이 창을 종료하는 방법은 q를 입력하면 된다.

 

 

Pull Request

내가 Push한 변경 사항에 대해서 다른 사람들에게 알리는 것

 

 

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

 

 

내 Remote Repository 에 Push 를 했더니 GitHub 웹사이트 상의 해당 Remote Repository 에 Compare & pull request 라는 버튼이 뜬다. 이 버튼을 클릭 해보자.

 

 

해당 화면에 작업해서 Push 해놓은 내용을 간단하게 요약해서 알려줌으로서 동료등리 코드를 보지 않고도 어떤 내용인지 쉽게 파악할 수 있도록 만들어 주자. 이렇게 Pull Request를 날려놓으면 여러 동료들의 리뷰도 받을 수 이쏘 내가 올린 작업을 기존 코드에 병합할 수도 있다.