[Git] Solo WorkFlow : git의 버전 관리 기능 활용하기

 

 

Github workflow overview

 

 

 

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로 내가 수정한 코드를 업로드 가능

 

 

 

 

 

---

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

 

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

 

 

 

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

 

• git-project를 Fork해서 어느 기능을 구현했다고 가정했을 때, commit으로 변경 사항의 저장 기록을 남겨두는 것이 좋음
• commit을 하기 전에 먼저 현재 Local Repository에 변경된 파일들이 어떤 것이 있는지 확인해 보자
• git status 명령어를 통해 staging area와 untracked files 세부 목록 파악 가능

 

 

TIP : 예시)

터미널 창, untracked files (git의 트래킹 되고 있지 않은 파일들) 목록에 A라는 파일이 있을 경우

터미널에서 이 파일을 Commit 하기 위해서는 git add 명령어를 통해서 commit 할 수 있다고 알려주고 있음.

A.js 파일은 '변경된 상태'(modified)인데 changes not staged, 즉 staging area에는 들어가지 않았을 경우,

이 시점에서 우리가 선택할 수 있는 행동 또한 터미널을 통해 파악 가능 (git add, git restore)

 

 

 

 

git add <file> 
untracked files를 staging area로 추가해서 git의 관리하에 둠

 

• untracked files를 staging area로 추가해 git의 관리하에 둠
• 따라서 add는 파일을 commit 할 수 있는 상태로 만듦
• git add 를 했을 때 터미널 창에 변화 없음

 

+)

git add . 명령어로 staging area에 unstaged 상태인 모든 파일을 한번에 추가 가능.

하지만 올리지 말아야 할 파일까지 모두 add될 수 있기 때문에 주의.

 

 

 

git restore <file>
commit 또는 staged 되지 않은 Local Repository의 변경 사항을 폐기

 

 

 

 

git commit -m ‘메시지’
수정 작업이 끝났을 때 변경 사항 저장

 

• 파일이 staging area에 올라간 후 commit이 가능한 파일이 되었을 때 사용
• 어떤 사항이 변경됐는지 간단한 메모를 통해서 버전의 변경 기록들을 관리할 수 있음( 언제, 누가, 어떻게)
•  -m 옵션을 통해 commit 메시지를 작성 가능
• Commit 기록은 위의 그림처럼 날짜, commit한 사람, commit 메시지가 모두 기록

 

 

 

git reset HEAD^
Local 에서 commit한 내용을 취소할 때 : 아직 remote repository 에 올라가지 않은 commit만 가능

 

• 아직 Remote Repository에 업로드 되지 않고, Local Repository에만 commit 해 놓은 기록이라면, reset 명령어를 통해서 commit 취소 가능 (에러 발생시 유용)
• git reset 사용 시 터미널 창에는 변화 없음
• git reset HEAD^ 이라는 명령어로 가장 최신의 commit 을 취소 가능
• HEAD는 연속된 ^의 shortcut으로 예를 들어 HEAD3은 HEAD^^^으로 표현 가능

 

+)

추가적으로 hard, soft 옵션도 존재

나중에 git reset --hard vs --soft 등의 검색어로 구글링 해보기

 

 

 

 

git push <origin> <branch>
local에서 변경, commit된 사항을  remots repository에 업로드

 

• commit 기록을 남기기를 완료 후, 파일들을 contribute 하기 위해서 Pull Request 를 날려야함
• Pull Request를 날리기 위해서 현재 Local Repository에 저장되어 있는 commit 기록들을 내 Remote Repository 에 업로드 해야함
• 내 Local Repository의 commit 기록들을 Remote Repository로 업로드 할 때 git push origin branch 명령어 사용
• git push origin main, git push pair dev 등 git push 뒤에 따라오는 명령어는 상황에 따라 변경 가능

 

 

 

 

git log
현재까지 commit된 내역을 터미널에서 확인

 

• 남긴 commit들이 잘 기록되었는지 확인해 보고 싶을 때 사용
• 현재까지 commit 된 로그들을 터미널 창에서 확인 가능
• 터미널 창을 종료하는 방법 :  q 입력

 

 

 

---

Staging area

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

이삿짐을 정리할 경우, 같은 용도의 물건들을 한 박스에 넣는 것이 좋다. 물건들을 박스에 모두 담았다면 밀봉 후 라벨링을 해서 각각의 용도를 적는다면, 이후 짐을 정리하기 쉬울 것이다.

 

여기서, 이 무빙 박스가 바로 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의 세 가지 영역 및 상태

 

git의 Local Repository에는 다음과 같은 영역이 존재

 

1. Untracked area는 Git이 관리하고 있지 않은 영역.

2. Tracked area에 들어온 파일들만 Git의 관리를 받을 수 있으며, Tracked area 내부에서도 세 가지 상태로 구별됨.

 

   1) Unmodified : 기존에 Commit했던 파일을 수정하지 않은 상태

   2) Modified : 기존에 Commit했던 파일을 수정한 상태

   3) Staged : commit이 가능한 상태