회고록 블로그
[공부필기] 생활코딩 '지옥에서 온 Git' 강의 필기 (1) 본문
코딩을 누구나 금전적 제한없이 배울 수 있도록 만들어 주신 이고잉님은 정말 대단하신 분 같다.
강의를 준비하고, 가르치고, 어떻게 더 쉽게 알려줄 수 있을까 고민하는 그 노력들을 금전적 보상 없이 하시는 것이니까 말이다.
마침 초등학생의 소프트웨어 교육이 의무화 되면서 프로그래밍적 사고의 중요성도 알고 있겠다,
이고잉님께서 '교육 발전에 이바지'하고 있는 것에 대해 교육부 장관표창이라도 받을 수 있다면 좋을텐데..
슬슬 더 많고 유용한 정보를 얻고, 함께 공유하기 위해서 git에 대해서 공부를 해야겠다는 생각이 들었다.
그래서 오늘도 생활코딩 강의를 보며 한 단계 진화(?) 해보려고 한다.
※ 본 글은 추후 필자가 복습하기 위해서 필기해놓은 글입니다.
오리엔테이션
* git? 버전관리시스템
* 파일의 이름을 더럽히지 않고(과제_final.xls -> 과제_final_final.xls -> 과제_final_final_real+final.xls 등으로 더럽히지 않음)
변경사항들만 컴퓨터가 관리하도록 하는 것이 버전관리시스템
* 용도?
(1) 백업하기 위해 사용
(2) (지금 상태가 마음에 안들어서) 이전 상태로 돌아가고 싶을 때 사용하기도 함
(3) 협업을 할 때 사용할 수도 있음 (엑셀을 공동 작업하는 느낌이려나)
* git은 정말...정말정말정말 어려움
- 따라서, 필요한 시점이 오면 배우기를 권장함
설치
* git bash : linux 명령어를 사용하는 콘솔(터미널창인 듯)
git init
* 먼저, 자신의 프로젝트에 사용되는 파일들을 관리/모아둘 폴더 하나 만들기
* git bash에서 "cd [폴더경로]" 입력 후 이동
- 대충 폴더 이름을 "git-folder"로 정했다고 가정
* 이제 가장 먼저 할 일은 깃(git)에게 버전관리를 할 파일들이 어떤 것인지 알려주여야 함
- git 명령어 사용법
- git init : '현재 디렉터리에 버전 관리 작업을 진행하겠습니다'라고 git에게 알려주는 명령어
# ".git"이라는 디렉터리가 생기는데, git과 관련된 정보들이 들어있음
# 만약 이 디렉터리를 지우게 되면 git이 관리하고 있던 버전 정보(예전 소스코드들)가 날아감
git add
* 대충 우리가 지금 아주 여러개의 복잡한 파일을 관리하고 있다고 상상할 것
* 일단 상상은 그렇다고 치고, 실습을 하려면 내용(코드)이 적혀있는 파일을 만들어야 함
* 이제 버전관리를 해야하는데, 버전 관리를 하기 전에 먼저 "status"를 알아두어야 함
- git status : 현재 git 상태를 확인함
# 만들었던 "file1.html"은 "Untracked files(추적하지 않는 파일)" 상태임
# 즉, "Untracked files"는
버전 관리가 되고 있는 폴더 안에 있지만(폴더 안에 ".git"이라는 폴더가 있으면 버전관리가 되고 있는 폴더임)
git에게 "버전관리를 시작해주세요"라고 명령을 내리지 않아서
버전 관리가 되고 있지 않는 파일을 말함 (명령을 내리기 전까지 git은 이 파일을 무시하고 있음)
# 관리하고 싶다면 명령을 내려야함
- git add file1.html : "file1.html"이라는 파일의 버전 관리를 시작해달라는 명령어
# 이 명령어를 입력하고 나면 파일은 인덱스(staging area)에 올라감 (=스테이징함)
# git add 명령을 하고 나면 아래와 같이 상태가 변경됨
버전 만들기(commit)
* 버전은 의미있는 변화를 말함
어떠한 작업이 있으면, 그 작업이 완결된 상태가 '버전'임
* 사실, git을 처음 쓸 때에는 가장 먼저 딱 한번 해야하는 작업이 있음
- git config --global user.name [닉네임]
- git config --global user.email [이메일주소]
(마치 카페에 처음 회원가입 할 때 닉네임과 이메일주소를 쓰는 것과 비슷한 듯함)
- git commit : 인덱스에 있는 변경 사항들을 저장소에 기록해서 버전을 만드는 명령어(=커밋하는 명령어)
# "메시지"를 꼭 적어야 함
- git log : 누가(닉네임, 이메일주소) 어떤 버전(commit 고유번호)을 만들었는지 확인할 수 있는 명령어
※ 스스로 정리하기 1
1. 깃(git)은 저장소(repository)에 따라서 분류될 수 있는데
* 원격 저장소 vs 지역 저장소
* 평소에는 개인 PC에서 git을 관리하다가 필요하면 원격 저장소에 업로드해서 타인과 공유할 수도 있고
원격 저장소에 있는 것을 개인의 PC로 다운로드할 수도 있음
2. 깃(git)에는 "커밋"이라는 것이 있는데
* 파일이나 폴더에서 변경되는 사항들(추가, 삭제 등)을 저장소에 기록하는 작업을 말함
* '커밋(commit)'이라는 버튼을 누르면(혹은 커밋이라는 명령어를 입력하면)
"이전에 커밋했던 그 상태"에서 변경된 사항들만 기록해서 커밋이 만들어짐
* 커밋 할때에는 "메시지"를 입력하도록 되어 있음 (보통 변경된 내용을 요약해서 적고, 변경한 이유를 적어놓음)
3. 깃(git)에는 "작업 트리"라는 것이 있는데
* 우리가 흔히 말하는 '폴더'를 의미한다고 볼 수 있음
* 아까 위에서 하고 있던 실습에서 보면 'git-folder'가 작업 트리(또는 작업 공간)가 될 것임
4. 깃(git)에는 "인덱스"라는 것이 있는데
* 작업 트리와 저장소 사이에 있는 공간이라고 볼 수 있음
* 이 공간이 존재하는 이유는 많은 파일 중에서 딱히 버전을 관리하고 싶지 않은 파일이 존재할 수 있기 때문임
* 그렇기 때문에 파일이 작업 트리 -----> 저장소로 바로 이동하는게 아니라 작업 트리 ----> 인덱스 ----> 저장소로 움직임
# 만약 작업 트리 -----> 저장소로 바로 저장을 하는 상황이었다면?
# 코딩을 할 때 이미지가 잠깐 필요해서 대충 컴퓨터에 돌아다니는 아무거나 이미지 파일을 '작업 트리'로 가져왔다고 가정함.
# 해당 이미지 파일은 완성품에 필요한 파일도 아니기 때문에 굳이 기록을 남길 필요가 없는데,
# 무조건 '작업트리' ----> '저장소'로 저장을 해야만 하는 상황이라면, 이 쓸데 없는 이미지 파일의 변경사항까지 기록을 하게 됨.
# 그래서 이런 쓸모없는(?) 행위(?)를 없애기 위해서 중간에 '인덱스'라는 공간이 있음
* 저장소에 변경사항을 기록(=커밋)하고 싶을 때에는 반드시 '인덱스'에 존재해야함
# 명령어를 통해서 인덱스에 먼저 보내고, 그 다음에 커밋 명령어로 저장소에 기록을 하는 순서임
* 인덱스에 기록하는 것을 '스테이징 한다'라고 표현하기도 함
참고자료 : https://backlog.com/git-tutorial/kr/intro/intro1_1.html
누구나 쉽게 이해할 수 있는 Git 입문~버전 관리를 완벽하게 이용해보자~ | Backlog
누구나 쉽게 알 수 있는 Git에 입문하신 것을 환영합니다. Git을 사용해 버전 관리를 할 수 있도록 함께 공부해봅시다!
backlog.com
※ 스스로 정리하기 2
1. 깃을 처음 사용해본다면?
- 프로젝트의 파일들을 관리하는 디렉터리를 만들고, 그 디렉터리를 git이 추적/관리할 수 있도록 명령 내리기 (git init)
2. 1의 디렉터리 안에서 파일을 만들었다면?
- git에게 해당 파일의 버전을 관리해달라고 명령하지 않으면 git은 파일을 추적/관리하지 않음
- 버전을 기록해야하는 파일인지 생각하고
- 버전 관리를 해야하는 파일이라면 git에게 추적해달라고 명령 + 인덱스로 올리기 (git add)
- 버전 관리가 필요 없다면 (임시 파일 등) 그대로 둠
3. 2의 작업을 하다가 파일을 변경했다면?
- 버전 관리를 하고 있던 파일이라면, git이 변경사항들을 관리하고 있었을 것임
- 해당 파일의 변경된 내용들을 인덱스로 올리기만 하면 됨 (git add)
4. 여러 파일을 변경하면서 작업을 완료했다. 이때 이 작업을 저장소에 저장하고 싶다면?
- 작업을 마무리해서 저장소에 저장하고 싶다면 먼저 3번에서 처럼 파일의 변경된 내용들을 인덱스로 스테이징 해야 함 (git add)
- 그리고 그 인덱스에 있는 변경사항들을 커밋하면 저장소에 기록됨 (git commit)
※git add (인덱스)를 사용하는 것에 대한 또 다른 이유
- 보통 소스코드가 방대해지고, 많은 소스코드를 수정하다보면 커밋 해야할 시기를 놓칠 때가 있음
(이고잉님 曰 : 거의 매일 그렇다고...)
- 문제는 커밋 하나에는 하나의 작업만이 담겨져 있는 것이 이상적인데
커밋 시기를 놓치면 여러 작업을 하나의 커밋에 뭉쳐서 기록하게 될 수 있다는 것.
- 이때 git add(인덱스)가 큰 힘을 발휘함
- 만약 인덱스가 없다면,
커밋 시기를 놓침(이미 많은 파일들이 변경되어 있음) -> 어쩔 수 없이 하나의 커밋에 모든 변경사항을 때려박고(?) 기록함
- 인덱스가 있다면,
커밋 시기를 놓침(이미 많은 파일들이 변경되어 있음) -> A파일만 작업트리에서 인덱스로 가져옴
-> 인덱스(A파일만 있음)에 있는 변경 사항을 커밋함(나머지 B, C, D파일은 커밋되지 않음. 작업트리에 있기 때문)
-> B파일만 인덱스로 스테이징해서 커밋함(A는 이미 커밋했고 C,D파일은 작업트리에 있기 때문에 커밋되지 않음)
-> C파일도 동일하게 -> D파일도 동일하게 커밋함
- 이렇게 인덱스를 활용 하면 커밋 시기를 놓쳐도 하나의 커밋에 하나의 작업만 기록할 수 있음
변경 사항 확인하기 (log & diff)
* git log -p : 각각의 커밋과 커밋 사이의 차이점을 알 수 있음
- 아래 그림에서 마이너스 3개는 /dev/null로 되어 있는데 이전 버전이 없다는 의미
(즉, file2.html은 이전에 커밋한 적이 없음, 이전에는 없었던 파일임)
- 플러스 3개는 b/file2.html로 되어 있는데 현재 버전을 의미함
- 아래 그림에서 마이너스 3개는 "a/file2.html"으로 되어 있는데
이전 버전의 "file2.html"을 의미함 (즉, 이전에 file2.html을 커밋했고 그 버전을 가리킴)
- 플러스 3개는 "b/file2.html"으로 되어 있는데 현재 커밋한 버전의 "file2.html"을 의미함
- 즉, 이전 커밋과 현재 커밋의 버전 차이를 확인하는 것임
- 위의 로그는 결국 "현재 버전에는 이전 버전에 있던 'source ID: 1'이라는 내용이 지워지고
'source ID: 2'라는 내용이 추가되었다'는 의미
(개발자는 file2.html 이라는 파일 안에 적혀있던 'source ID: 1' 이라는 문장을 'source ID: 2'로 수정했었음)
* git log [커밋 고유번호] : 해당 고유번호의 커밋을 기준으로 그 이전의 커밋만 보여짐
- 커밋에는 고유한 번호가 있음 (16진수로 이루어져 있음)
커밋 메시지가 가리키는 버전의 고유한 주소임
* git diff [커밋 고유번호1]..[커밋 고유번호2] : 커밋 고유번호1과 고유번호2의 사이에 있는 버전과 버전의 차이점 볼 수 있음
* 작업트리에서 하나의 파일을 수정하고 git diff 를 입력하면, 변경된 사항을 볼 수 있음
- 여기에서 중요한 점은 "파일을 수정하고 커밋을 한 후" 이전 커밋과 현재 커밋의 차이점을 보는게 아니라,
"파일을 수정하고 커밋을 하기 전"인 상황에서 이전 커밋과의 차이점을 비교해준다는 것임
- 즉, 개발자가 커밋을 하기 전에 마지막으로 수정한 코드를 검토/리뷰할 수 있는 기회를 준다는 점임
