git workflow 이해하기 (commit 하는 법)

git에는 세가지 작업 환경이 나눠져있다.

첫번째는 working directory로, 프로젝트의 파일을 수정하고 작업하는 환경이다.

두번째는 staging area로, 버전 히스토리에 저장할 준비가 되어있는 파일을 옮겨두는 곳이다.

세번째는 .git directory로, 버전 히스토리를 가지고 있으며 git repository라고 불리기도 한다.

프로젝트 폴더에서 수정이 완료된 파일들은 add 명령어에 의해 staging area로 옮겨진 후 commit 명령어를 사용하여 git 버전 히스토리에 저장된다(.git director).

이렇게 .git directory에 저장된 버전들은 checkout이라는 명령어를 사용하여 언제든지 원하는 버전으로 돌아갈 수 있다! 

 

working directory는 세부적으로 untracked와 tracked로 나눌 수 있다. git이 이미 tracking하고 있는 파일이라면 tracked 카테고리에 들어가고, 새로 만들어진 파일이거나 기존에 존재하는 프로젝트에서 git을 초기화하면 파일에 대한 정보가 아직 없으므로 untracked이라고 할 수 있다. tracked에서도 수정 유무에 따라 unmodified와 modified로 나뉜다. 이때, modified에 있는 파일만 staging area로 옮겨갈 수 있다.

 

저장된 git history는 내 컴퓨터에만 보관되어있기 때문에 컴퓨터가 망가지면.. 슬퍼진다

따라서 git directory를 깃허브와 같은 서버에 push 명령어를 사용하여 업로드하는게 좋다.

서버에서 로컬로 다시 다운받고 싶을때는 pull 명령어를 사용한다. 

 

각 commit에는 고유한 해시코드가 있는데, 이걸 이용해서 버전 정보를 참조할 수 있다. commit에는 버전에 관련된 메세지와 작성한 사람, 날짜 시간 등의 정보도 포함되어있다.

 

위에서 설명한 git workflow가 이해되는가?

이게 뭔소리지?? 싶으면 명령어를 직접 써보면서 익히자. 

echo 명령어를 사용하여 a라는 txt 파일에 ji라고 작성했다. window 환경에서 echo 명령어를 쓸때는 꼭 문자열에 큰따옴표나 작은 따옴표를 붙여줘야한다. 큰따옴표와 작은 따옴표의 차이는 치환이 되냐 안 되냐 인데.. 당장은 필요 없으니 설명을 패스한다. 

ls -al을 치니 a.txt파일이 잘 생성된걸 확인할 수 있었다. 육안으로 한번 더 확인해보자.

 

start . 를 치면 a라는 텍스트 파일이 있는걸 볼 수 있다. a를 열어보면 ji라고 써있다.

이제 동일한 내용의 b, c 파일을 만들어보자. git status 명령어를 쓰면 현재 파일들의 상태를 보여준다. 

On branch master: 마스터 브랜치에서 작업중이라는 뜻

a, b, c 파일은 모두 untracked file이며 아직 commit할게 없지만 untracked file이 존재하므로 git add를 이용해서 tracking할 수 있다. 이게 무슨 말이냐면.. 세 파일이 현재까지는 working directory의 untracked로 분류되어 있고 만약commit할 준비가 된 놈이 생기면 git add 파일이름 명령어를 통해 staging area로 옮기라는 소리다. 한번 해보자!

 

 

중간에 까만 공백은 내가 실수한거라.. 보는 사람이 헷갈릴까봐 지운거니 신경쓰지 않아도 된다.

a 텍스트 파일을 staging area로 보내고 싶다. 그런데 여기서 CRLF 어쩌구 오류가 떠버린다. 이 오류가 뜨는 사람은 내가 전에 쓴 글을 보고오지 않은 사람이다. 근데 아마 이 오류뜬건 나밖에 없을 것이다. 꼭 설정해야된다고 써놓고 까먹고 안 했다^^ 아무튼 무사히 a를 staging area로 옮겼다.

https://ggubbanglovesherlife.tistory.com/33?category=977406 참고ㅎㅎ

이때 autocrlf를 true로 바꿔주는 작업을 하면서 --global을 다는것과 안 다는 것의 차이점이 궁금해져서 알아봤다. global을 쓰면 특정 저장소가 아닌 모든 저장소에 저장된다고 한다.

 

 

다시 git status하면 무언가의 변화가 생겼다고 알려준다. commit할 준비가 되어있는 새 파일이 있다.

이때 살짝 꿀팁을 알려주자면 txt로 끝나는 모든 파일을 staging으로 넘기고 싶을때는 git add *.txt 를 사용하면 된다.

 

 

이제 세 파일은 모두 staging area로 옮겨졌다. 만약 여기서 파일을 수정하면 어떻게 될까??

a에 hello~라는 문자열을 덧붙여봤다. a가 modified 됐다고 뜬다. 이때 a는 staging area에도 있고 tracked의 modified에도 있는 것이다. staging의 a와 modified의 a는 같은 파일일까?? 아니다. staging area에 있는 a는 수정전, 즉 "ji" 만 쓰여진 파일이고 modified에 있는 a는 "ji hello~" 가 쓰여져 있다. 저장할 당시의 상태를 그대로 갖고 있는 것이다.

 

 

a를 다시 add해주고 상태를 보니 modified에 있는 a가 없어졌다. staging area에 업데이트 된 것이다.

음 그런데 use "git rm ~" 이라고 써있는건 뭘까?? 

git rm --cached <file> 명령어를 이용하면 파일을 staging area에서 working directory로 옮겨갈 수 있다는 뜻이다.

정말 친절하다

git rm --cached를 써서 모든 파일을 staging area에서 working directory로 옮긴 모습

 

 

 

여기서 a를 삭제하고 모든 파일을 staging area로 옮기면 어떻게 될까?

두가지 방법이 있는데, 첫번째는 git add *을 쓰는 것이고 두번째는 git add . 를 쓰는 것이다.

git add *를 썼을 경우: 삭제된 a 파일은 디렉토리에 없기 때문에 staging area에 추가되지 않는다.

git add .를 썼을 경우: 모든 파일이 staging area에 추가된다.

 

이렇게 수정을 거쳐 파일을 완성하였다면 버전을 만들 준비가 된 것이다. commit을 통해 git directory로 파일을 넘겨보자. 현재 상태는 이렇다. 모든 파일을 staging area로 옮겨주자.

 

옮겨졌다.

 

 

이제 git commit -m 명령어를 통해 git directory로 넘겨보자. 여기서 first commit은 커밋 메세지이다. 쓰고 싶은 메세지를 쓰면 된다. 협업을 할때에는 다른 팀원들에게 이번 commit에서 어떤 부분이 달라졌는지 알리는 역할을 하기도 한다. 자세한건 커밋 메세지 작성법을 검색해보길. 잘 commit 되었는지 확인해보자. git log를 통해 커밋 히스토리를 조회해보면 전체 해시코드, commit한 사람의 정보, 날짜와 시간이 나온다. first commit이 잘 commit된걸 알 수 있다.

 

working directory에 있는 파일을 staging area로 옮기지 않아도 commit할 수 있는 방법이 있다. git commit -am 명령어를 사용하면 된다. 그러면 working directory와 staging area에 있는 모든 파일이 commit된다. 하지만 한번도 add된적 없는 파일에는 이 명령어를 쓰지 못한다.

c 파일을 수정했기 때문에 현재 modified에 있는 상태이다.

 

메세지에 third commit을 써서 commit해봤다. git log를 보니 잘 commit된걸 알 수 있다. 이 글에서 왜 second commit이 생략됐냐면... second commit은 중간에 오류가 나서 사소한 삽질(?)을 한 결과물이기 때문이다. 못본척 해주면 된다.

 

 

이해하기 쉽게 commit 메세지를 first, second, third 로 썼지만 실제 프로젝트를 commit할 때에는 의미있는 이름으로 써줘야한다. 또한, 큰 프로젝트를 한 파일로 넣는것 보다는 의미있는 단위로 세분화 하여 commit하는게 좋다. 이 '의미있는 단위'는 협업을 자주 해보면 감이 잡힌다고 한다. 나도 아직 학생이라 모른다ㅎㅎ

 

드디어 commit하는 방법을 배웠다. 이제서야 뭔가 좀 아는것 같아서 뿌듯하지만 갈 길이 멀다... 이 글을 읽는 예비 개발자들 모두 화이팅...!