(4) Git의 커밋(commit) 해보기

git을 사용하여 계산기 프로그램을 만드는 프로젝트 실습

이전 글에서 프로젝트 디렉토리를 만들었고 그 안에서 레포지토리를 생성하였다.

다시 MathTool 프로젝트 디렉토리에 들어와서 커밋을 진행 해보자

 

더하기 빼기 함수를 제공하는 디렉토리 생성

vs code나 파이썬을 사용하여 아래의 코드를 작성 후 저장한다. (calculator.py)

def add(a, b):
  return a+b
def subtract(a, b):
  return a-b

※ 해당 코드는 파이썬 언어로 작성된 코드이다. 

 

 

▼ 이 calculator 파일을 홈디렉토리에서 MathTool 디렉토리에 저장한다.

 

▼ 프로젝트의 결과물의 라이센스를 무료라는 정보를 넣기위해 Free 작성하여 파일로 저장 후 (License)

마찬가지로 MathTool 디렉토리에 저장한다.

 

▼ 파일이 잘 저장 되었는지 터미널에서 확인 ' ls -al '

 

▷ 해당 상태를 MathTool 디렉토리의 첫 번째 버전으로 남긴다.(commit)

단 커밋전에 해야 하는 것이 하나 있다.

바로 git에게 본인이 누구인지 알려주는 것.

 

Commit 전에 해야할일!

▼ git에게 commit한 사람 알려주기

커밋을 할 때에는 그 커밋을 누가 했는지 반드시 함께 기록해야한다.

그래야 협업자와 일할때 나중에 누가 커밋했는지 알 수가 있다.

혼자 프로젝트 할 때는 필수는 아니다. 하지만 git은 해당 기록을 강제하며 무조건적으로 해줘야 한다.

 

▼ 내가 누구인지 알려주기위해 이름과 이메일주소 설정

git config user.name "SeopE"
git config user.email "pplo23@naver.com" 

이제부터 커밋을 하면 그 커밋에는 내 정보와 함께 저장된다.

▼ 커밋 해보기

git commit

 

여기서 바로 엔터 누르면 안되며, 몇가지 더 넣어야하는 상황이있다.

이름과 이메일등 본인 정보 뿐만아니라 커밋에 대한 정보도 넣어줘야 한다.

어떤 변동 사항이 생겨서 이러한 커밋을 했는지 그런 정보를 추가해줘야 한다 = commit message

 

커밋 메시지를 남기려면 옵션이 필요하다.

 

▼ MathTool 디렉토리 안에 파일 두개 (calculator.py, License)를 생성 하였다는것을 메시지를 남긴다

git commit -m "create caculator.py and license"

 

▷ 하지만 에러메시지가 출력이 되었는데 커밋을 하기위해서 add 된게 하나도 없고 

untracked 상태인 파일들이 존재한다는 문구가 보인다. (untracked - 추척 되지 않은 - 깃에 의해 아직 추적되지 않고 있다.)

아직 git으로 뭔가를 해준적이 없어서 파일이 버전 관리 대상이 아닐 때 untracked 라고한다.

 

▷  그러므로 우리는 커밋할 파일을 미리 지정해줘야한다.

즉 파일을 새로 생성하거나 원래 있던 파일의 내용들을 수정하고 나면

그 파일들은 그 새로운 모습으로 커밋에 포함될 거라고 지정을 하는 것이다.

이 작업을 해야 그 이후에 커밋을 진행 할 수있다. 이런 사전 작업을 add라고 한다.

 

▷ add는 어떤 파일의 수정된 모습을 커밋에 반영하기 위함으로 지정하기 위해

이 다음에 수정된 모습을 커밋에 반영하고 싶은 그 파일의 이름을 적으면 된다.

git add calculator.py

이제 커밋에 반영 될 파일로 지정이 된다.

▷  license 파일도 똑같이 지정

 

▼ 이제 커밋을 다시 진행

이 출력 결과는 커밋이 되었고 그 결과를 보여준다는 뜻이다.

 

▷ 출력 내용중 root-commit은 이 커밋이 프로젝트의 첫 번째 커밋이라는 뜻

▷ 그 옆에는 본인이 작성한 커밋 메시지가 적혀있는 것을 확인

▷ 2 files changed는 파일 2개를 추가한 작업을 뜻함

▷ 5 insertions는 5줄이 추가됐다는 것을 뜻함 (calculator.py와 License 내용의 줄을 합친 것)

 

 

commit에 관한 주의사항 정리

1. 처음으로 커밋을 하기 전 사용자의 이름과 이메일 주소 설정

2. 커밋 메시지 남기 (옵션 -m)

3. 커밋할 파일을 git add로 지정해주기

 

이렇게 처음으로 커밋을 완료 하였다.

 

---

아까 공부한것들 중에 내용을 수정한 파일 중에서 커밋에 반영하고 싶은 파일은 git add를 해야한다고 했다.
그런데 이것과 관련해서 꼭 알아야할 사실이 하나 있는데
이 사실을 확실히 이해하고 암기해야 앞으로 깃을 사용할 때 어려움이 없다

 

Git은 내부적으로 크게 3가지 종류의 작업 영역을 두고 동작한다.
각 작업 영역의 이름은 working directory, staging area, repository이다.

- 첫 번째 작업 영역인 working directory는 작업을 하는 프로젝트 디렉토리를 말하며 

지금 실습 진행하는 상황에서는 MathTool 디렉토리가 working directory 이다.

- 두 번째 작업 영역인 staging area는 git add를 한 파일들이 존재하는 영역이다. 

커밋을 하게되면 staging area에 있는 파일들만 커밋에 반영된다.

- 세 번째 작업 영역인 repository는 working directory의 변경 이력들이 저장되어 있는 영역이다. 

 커밋들이 저장되는 영역이라는 뜻인데, 풀어서 설명하자면
working directory에서 뭔가 작업을 하고,
작업한 파일들을 git add 해주고,
커밋을 하면 staging area에 있던 파일들의 모습이 마치 영화의 한 장면, 

스냅샷(snapshot)처럼 이 repository에 저장되는 것이다.

그리고 레포지토리를 만든 것처럼 실제로는 MathTool 디렉토리 안에 숨겨져 있던 .git 디렉토리가 repository이다.

 

working directory에서 A.txt 파일과 B.txt 파일을 작성하고
git add A.txt와 git add B.txt를 실행해서 A.txt, B.txt 둘다 staging area에 올렸다.
그 다음 git commit -m "Ver_1"를 실행해서 staging area에 있는 파일들을 가져와 커밋으로 남겼다.
그러므로 Git에서 커밋을 할 때 어떤 식으로 일이 진행되는 것인지 감이 올 것이다.

작업을 좀 더 해보자면

 

 다음과 같은 작업을 추가적으로 했을때,

working directory에서 A.txt 파일 내용에 Python~이라는 단어를 추가,

 B.txt 파일 내용에 Morning!이라는 단어를 추가했다.

그런데 이번에는 git add B.txt만 실행해서 B.txt 파일만 staging area에 올리고

그 다음 git commit -m "Ver_2"로 두 번째 커밋을 했다.

이전 그림과 다른 점은 A.txt는 staging area에 올리지 않고, B.txt만 staging area에 올렸다는 점이다.

그랬더니 지금 repository에서 그 결과가  Ver_2 커밋을 보면 지금

A.txt는 staging area에 있던 모습, 그러니까 수정하기 이전의 모습이 Ver_2 커밋에 반영되었고
B.txt도 staging area에 있던 모습, 하지만 A.txt와는 달리 수정한 이후의 모습이 Ver_2 커밋에 반영되었다.
A.txt, B.txt 둘다 working directory에서 수정했다는 사실은 같지만, 

staging area에 올렸는지 여부에 따라 그 최신 모습이 커밋에 반영되는지가 달라지는 것.

바로 이 점이 Git을 사용할 때 잘 알고 기억해야하는 부분이다.

그런데 staging area가 굳이 왜 필요할까? working directory에서 작업을 하고

git add할 필요없이 바로 커밋해버리는 구조가 더 편할 것 같은데 라고 생각 할수있지만 꼭 그렇지는 않다.

 

방금처럼 A.txt와 B.txt 파일을 둘다 수정했더라도

두 파일 모두 그 최신 모습을 다음 커밋에 반영하고 싶지 않을 수도 있다.

방금처럼 B.txt의 최신 모습만 그 다음 커밋에 반영하고 싶을 수도 있는 것. 이런 상황은 실제로 꽤 자주 있다.

 

만약 staging area가 없다면 원하는 것들만 선별적으로 커밋에 반영할 수 없게 된다.

그럼 좀 더 세밀한 버전 관리를 할 수 없게 되는 거죠. 그렇기에 staging area가 필요한지 알 수 있을것이다.

아무튼 이 부분들을. 꼭 제대로 이해하고 넘어가야한다.

※ working directory는 working tree라고 하기도 하고, staging area는 index라고 할 때도 있다.

(작업영역이 똑같으므로 햇갈려하지 않기)