[Git] 사용법 Alone workflow

Alone workflow

전체 과정

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

깃허브 우측 상단의 Fork 버튼을 누르면 다음 화면이 뜨는 것을 확인하실 수 있습니다. 나의 유저 네임을 클릭하면 Fork 작업이 완료됩니다. GitHub.com의 내 계정에 Fork해서 들어온 kimcoding / git-project는 나의 Remote Repository (원격 저장소)입니다.

김코딩이 git-project를 Fork한 시점부터 이 git-project는 김코딩의 Repository에 복사본으로 저장된 것입니다.

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

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

git clone

이제 Remote Repository에 있는 파일을 작업하기 위해서는 내 컴퓨터로 복사해오는 작업이 필요합니다.

이 때 사용할 수 있는 명령어가 바로 clone입니다. git clone 명령어 뒤에 Repository 주소를 입력하면 해당 Repository를 내 컴퓨터(Local Repository)로 가져와서 작업할 수 있습니다.

 

git status

git-project를 Fork해서 마이페이지 기능을 구현했다고 가정해 봅시다.

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

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

터미널 창을 꼼꼼히 읽어 보면 힌트를 다 주고 있습니다!

현재 어떤 파일이 어떤 상황에 있는지 표시하고 있습니다.

untracked files (git의 트래킹 되고 있지 않은 파일들) 목록에는 mypage라는 파일이 있고 이 파일을 Commit 하기 위해서는 git add 명령어를 통해서 commit 할 수 있다고 나오고 있습니다.

mypage.js 파일은 '변경된 상태'(modified)네요. 그런데, changes not staged, 즉 staging area에는 들어가지 않았어요. 이 시점에서 우리가 선택할 수 있는 행동을 안내하고 있습니다.

 

[add] : add는 파일을 commit 할 수 있는 상태로 만들어 줍니다.

[restore] : 변경사항을 폐기(discard changes) 하는 명령어예요. 이처럼 git status 를 통해 어떤 파일이 어떤 상태에 있는지, 그리고 해당 파일에 대해 어떤 행동을 할 수 있는지 알 수 있습니다.

 

git restore

기존에 있던 코드들을 훑어 보니 코드 작성 방식이 나와 달라서 통일성을 해치기 때문에 작업한 코드를 싹 다 밀어 버리고 새로 작업해야 할 때 처음 Clone을 받았던 상태로 되돌리는 방법이 있습니다.

명령어가 바로 restore입니다.

commit되지 않은 Local Repository의 변경 사항을 폐기할 수 있어요. git restore mypage.js 명령어를 통해 Work space의 변경 사항을 폐기하고 다시 처음으로 clone 받아 왔던 상태가 되었습니다.

 

 

 

 

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

staging area에 들어 오지 않은 파일은 unstaged 혹은 untracked file

들어 있는 파일들은 staged 된 파일

 

git add

마이페이지 구현을 하고, 문제 없이 잘 작동이 되는 것 같으니 드디어 commit을 하면 됩니다.

commit을 하기 위해서는 먼저 Git의 관리 하에 있는 영역으로 파일들을 옮겨 줘야 하는데요. 관리 영역이 staging area입니다.

git add 명령어는 다음과 같습니다. git의 트래킹이 되고 있지 않은 파일들에서 git의 관리 하에 있는 staging area 로 파일들을 추가하는 명령어는 git add <파일이름> 입니다. 

git add 를 했을 때 터미널 창에는 변화가 없습니다. 종종 add 해야 할 파일이 너무 많은 경우도 발생하게 될 텐데요. 그렇다면 이 파일들을 하나하나 다 적어야 할까요? 아닙니다. git add . 명령어로 staging area에 unstaged 상태인 모든 파일을 한번에 추가할 수 있습니다.

but 이 명령어를 사용할 때는 올리지 말아야 할 파일까지 모두 add될 수 있기 때문에 주의하셔야 합니다.

 

- git add <파일이름>

내 Local의 untracked file을 Git의 관리 하인 staging area로 추가할 수 있습니다.

- git add .

Staging area에 모든 파일을 한번에 추가할 수 있습니다.

 

Staging area

 

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 상태로 만들어야 합니다.

 

아까 활용했던 restore 명령어에 대한 설명도 확인할 수 있습니다. 이는 discard changes 변경사항을 폐기하는 명령어입니다.

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

 

 

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

파일이 staging area에 올라간 상태이기 때문에 commit이 가능한 파일이 되었습니다. 변경 사항을 저장하기 위해서는 commit을 활용합니다. 어떤 사항이 변경됐는지 간단한 메모를 통해서 버전의 변경 기록들을 관리할 수 있습니다.

commit 메시지를 작성하기 위해서는 -m 옵션을 통해 코멘트를 작성할 수 있습니다. (git commit -m ‘mypage 구현’ 이라는 메시지)

 ※ commit 메시지 작성 방법에 대해서는 굉장히 다양한 기준과 컨벤션이 있기 때문에 좋은 commit 메시지를 작성하기 위한 기준을 구글링해 보시는 것을 추천합니다. 추천 링크 : https://chris.beams.io/posts/git-commit/

Git commit -m ‘메시지’ 명령어를 입력했을 때 나타나는 터미널 화면은 다음과 같습니다.

Commit 기록은 위의 그림처럼 날짜, commit한 사람, commit 메시지가 모두 기록됩니다.

 

 

git reset 

방금 commit한 기록을 취소하고 에러를 수정하려 할 때에

아직 Remote Repository에 업로드 되지 않고 Local Repository에만 commit 해 놓은 기록이라면

reset 명령어를 통해서 commit 을 취소할 수 있습니다

git reset 를 했을 때 터미널 창에는 변화가 없습니다. git reset HEAD^ 이라는 명령어로 가장 최신의 commit 을 취소할 수 있습니다.

올린 하나의 commit 만 취소하면 git reset HEAD^ 명령어가 적합합니다.

HEAD는 연속된 ^의 shortcut 입니다. 예를 들어 HEAD3은 HEAD^^^와 같습니다. 즉 이 상황에서는 HEAD~1 명령어도 가능합니다. 추가적으로 hard, soft 옵션도 있는데 reset 에 대해서 더 공부하고 싶으시다면 git reset --hard vs --soft 등의 검색어로 구글링 한 후 실습해 보시는 것을 추천드립니다.

 

 

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

git push

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 push origin master 명령어를 입력했을 때 나타나는 터미널 화면은 다음과 같습니다.

git log 

git log 라는 명령어를 터미널에 입력하면 현재까지 commit 된 로그들을 터미널 창에서 확인할 수 있습니다.

이 터미널 창을 종료하는 방법은 q 를 입력하시면 됩니다.

 

 

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

 

Pull Request

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

 

 

 

 

 

 

 

<Git의 세 가지 영역 및 상태>

 

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 상태의 파일이며,

Changeds not staged for commit 라고 적혀 있는 빨간색 파일은 Modified 상태의 파일입니다.

 

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

 

솔직히 정리를 해도 감이 안잡혀서 역시 해보는게 제일 좋은듯 하다.