git commit하기

1이라는 내용을 가진 work1파일을 생성한다.

아래 사진의 1번 2번을 차례로 클릭한다.

아래 사진과 같이 커밋메세지와 커밋버튼이 생긴다. 2번 메세지칸에 work1을 적고 3번 커밋 버튼을 누른다.

yes를 누른다.

그럼 커밋이 완료된다.

커밋을 누를 경우 위와 같은 화면이 뜨지 않고 Make sure you configure your 'user.name' and 'user.email' in git 가 뜰 경우 이곳에 들어가 2. vscode와 git 연동을 따라 로그인을 하면 된다.

좌측 하단에 보면 Git Graph가 있다. 이것을 클릭하면 현재 폴더의 Git Graph를 볼 수 있다. Graph에는 커밋 제목과 커밋 Id등이 나와있다.
아래 그림을 보면 커밋한 내용이 기록된 것을 볼 수 있다. work1이라는 제목으로 커밋을 했고, 커밋 아이디는 우측의 Commit에 적혀있는 89944288이라는 것을 알 수 있다.(원래는 더 길지만 짧게만 보여준다.)

깃의 저장

깃에는 3가지 저장공간이 있다.

• Working Directory : 유저가 파일을 수정하는 작업공간을 말한다. visual studio에서 연 폴더라고 생각하면 된다.
• Stage Area(.git의 index파일) : 유저가 만들고 수정한 작업 중 Repoitory(git)에 올릴 작업을 의미한다. 유저가 파일을 수정했더라도 Stage Area에 올리지 않으면 커밋되지 않는다.
• Repository(.git) : 버전관리를 위한 저장소이다. 우리가 흔히 생각하는 git을 의미한다.

example

여태까지 한 작업에 따르면 work1(내용 : 1)파일과 work1 커밋이 있다.
여기서 work2(내용 : 2), work3(내용 : 3)를 만들어보자.

git status 명령어는 현재 깃의 상태를 알 수 있다. working Directory에서 수정한 파일은 빨간색으로, 그 중 Stage Area에서 올라간 파일은 초록색으로 보인다. 커밋한 파일은 보이지 않는다.

파일을 만들고 터미널에 git status를 입력하면 아래와 같이 work2, work3가 빨간색으로 표시된 것을 볼 수 있다.

git add "파일명"으로 파일을 Stage Area에 올릴 수 있다.
이제 git add work2로 work2파일을 Stage Area에 올려보자.

git status에서 Stage Area에 있는 work2는 초록색으로 뜨지만 Working Directory에만 있는 work3는 빨간색으로 보인다.
또한 visual studio에서 source contorl(아래 그림에 동그라미 친 부분)을 눌러보면 Stage Changes에 work2가 있고 Changes에 work3가 있다. Changes는 커밋 이후 수정된 파일들이 있고, 이 중 Stage Area로 보낸 파일들이 Staged Changes로 이동한다.

vscode에서도 Stage Area로 보내거나 취소할 수 있다. work3 옆의 + 표시를 누르면 Staged Changes로 이동하고, work2 옆의 - 표시를 누르면 Changes로 돌아간다.(Stage Area에서 지워진다.)

work2만 Stage Area에 있는 상태에서 git commit -m "커밋 메세지"로 커밋을 할 수 있다.
터미널에 git commit -m working2 입력해보자.
그럼 아래와 같이 work2는 커밋되어 사라진 것을 볼 수 있고, Stage Area에 있지 않던 work3는 그대로 남아 있는 것을 볼 수 있다.

이 글 초반 부분에서 visual studio code를 통해 commit을 할 때 아래와 같은 메세지가 떴다.

There are no staged changes to commit.
Would you lige to stage all your changes and commit them directly?

이때 Stage Area에 work1을 올리는 작업 없이 바로 commit을 눌렀기 때문에, 커밋할 내용이 없으니 changes의 모든 내용을 커밋하겠냐는 질문이 나온 것이다.

git status에서 수정한 파일들만 나오기 때문에 Stage Area에는 수정하고 add한 파일(work2)만 있을거라 생각할 수 있다. 하지만 Stage Area에는 기존의 파일과 add한 파일이 올라간다.
위의 사진 속 Stage Area에는 work1, work2가 존재한다.
커밋 이후에도 마찬가지로 Stage Area에는 work1, work2가 존재한다.

커밋 이동하기

주요 용어 3가지

• 1번 head : 지금 작업 중인 시점이다. head가 master에 붙어있는 것을 볼 수 있는데 master 브런치 위에서 작업중이라고 생각하면 된다. head가 가리키는 시점에서 새로운 commit이 이뤄진다.

• 2번 master : 브런치를 의미한다. 깃은 브런치를 여러개 생성하여 git을 관리한다.
  프로그램의 버전이라고 생각하면 편하다. python 1.0 버전과 python 2.0버전이 있다고 하자. git을 사용하지 않는다면 python 1.0과 python 2.0을 아예 따로 작성해야하지만, git에서는 python 1.0 브런치와 python 2.0 브런치를 생성하여 관리할 수 있다.

• 3번 commit : 저장 시점을 의미한다. head와 브런치는 커밋을 기준으로 움직일 수 있다. master 브런치가 working2에 있는 것을 볼 수 있다. 이 말은 master 브런치가 working2 commit 시점을 가리키고 있는 것이다.

아래와 같이 head는 master를 master는 working2를 가리키고 있다고 생각하면 된다.

git checkout "커밋id"로 head는 커밋 사이를 자유롭게 움직일 수 있다.
커밋 id는 git graph의 우측에 표시된다.
터미널에서 커밋 id는 git log 또는 git log --oneline (--all)로도 볼 수 있다.

• git log & git graph commit id
  

• git log --oneline
  

• git log --oneline --all
  

git checkout 89944288을 입력하여 head를 work1으로 움직여보자.
master는 working에 있지만 head는 work1으로 움직인 것을 알수 있다.

아직 커밋하지 않은 work3는 head가 있는 시점에서 수정된 파일로 취급한다. 그렇기 때문에 wokring2에서 이어지는 것이 아닌 work1에서 uncommitted Changes가 생긴다.

Head

head는 꼭 Master를 가리키지는 않는다. head가 Master를 가리킬 때는 Master가 이동하면 head도 이동하지만 head가 Master가 아닌 commit 시점을 직접 가리키면 head는 master와 따로 떨어져서 작업이 진행된다.

head가 마스터를 가리키고 있으면 아래와 같이 gitGraph에서는 master가 굵게 표시도니다. 터미널에서는 (master)라고 파랗게 표시된다.

git checkout 95af3c02로 head가 working2를 바로 가리키게 만들어보자

head가 master를 가리키고 있지 않기 때문에 master의 글씨는 얇아진다. 또한 터미널에서는 (master)가 (커밋아이디)로 바뀐다.

처음 work1을 commit한 후 head는 master를 가리키고 있다. 그래서 working2를 커밋하면 head와 master 모두 working2로 이동한다.
하지만 head가 커밋을 직접 가리키면 master의 이동 없이 커밋 시점에서 새로운 커밋이 가능하다.

working2 시점에서 바로 work3를 커밋해보자.

master는 working2에 그대로 있지만, head는 새 커밋 working3로 움직인 것을 알 수 있다.

git add .로 changes 내의 파일을 모두 staged Changes로 옮길 수 있다.

git checkout master로 head가 다시 master를 가리키게 해보자.

head가 다시 master를 가리키면서 working3가 사라진 것을 볼 수 있다.

깃은 모든 변경사항을 기록하고 있기에 실제로 working3가 사라진 것은 아니다.

터미널에 git reflog를 입력하면 그동안 했던 작업들을 볼 수 있다.
ffb8ba7 HEAD@{1}: commit: working3 이라고 적힌 부분이 지금 봐야할 부분이다.
ffb8ba7이 working3를 커밋한 commit id이다.

git checkout ffb8ba7을 입력해보자.

working3 커밋이 다시 보이는 것을 알 수 있다.

Branch

git에서 브런치를 만들 수 있다.

커밋명에서 우클릭을 하면 두번째에 create branch가 있다. create branch를 누르고 branch명을 입력하면 branch를 생성할 수 있다.

git checkout master로 마스터 브런치로 돌아간 다음 work1에 5라는 내용을추가하고 working4 이름으로 커밋해보자.

아래와 같이 exp브런치와 master브런치가 서로 분리된 것을 알 수 있다.

matser 브런치가 배포할 메인 내용을 가지고 있다고 가정하자. master에 바로 코드를 수정하여 배포하는 것은 오류의 위험이 크다. 그렇기 때문에 exp라는 브런치를 만들어 코드를 수정하고 테스트할 수 있다.
exp 브런치가 working2에서 갈라져 나온 것을 볼 수 있다. 이건은 working2까지는 같은 내용을 가지고 있다는 것을 의미한다. working2 이후 exp는 working3라는 작업을 하고 master는 working4 작업을 하는 것이다.

브런치 병합

브런치는 head가 없는 브런치를 head가 가리키는 브런치로 병합할 수 있다.
브런치는 어디서 어디로 병합하는냐에 따라 큰 차이를 보인다. master로 exp를 병합할 수도 있고 exp로 master를 병합할 수 있다.

master가 main이고, exp가 실험적으로 만든 코드라고 하자.

• exp로 master를 병합하는 것은 실험에 master의 업데이트 내용을 반영하는 것이다.
  git checkout exp로 head를 이동시키자.
  master브런치에서 우클릭, merge into current branch로 master를 exp로 병합할 수 있다.
  아래와 같이 master가 exp로 들어간 것을 볼 수 있다.
  
  파일을 보면 exp의 내용과 master의 내용이 모두 적용된 것을 알 수 있다.
  

exp에서 work1에 5라7이라는 내용을 추가하여 커밋하고, master에서 work4라는 파일을 만들어보자.
아래와 같이 병합 이후에도 master와 exp는 각각 진행하는 것이 가능하다.

실험을 끝냈고 main 코드인 master에 실험한 내용을 추가한다고 하자.

• master로 exp를 병합하는 것은 master에 exp코드를 반영하는 것이다.
  head를 master로 옮겨서 exp를 master에 병합시켜보자.
  아래와 같이 exp가 master로 들어간 것을 볼 수 있다.
  
  파일에도 exp와 master의 수정사항 모두 반영되어있다.
  

병합을 취소하고 싶다면 취소하고 싶은 커밋에서 우클릭 Reset current branch to this Commit을 누르면 된다.

병합할 때 아래와 같은 메세지가 뜬다. Create a new commit even if fast-forward is possible이 기본으로 체크되어있고 merge를 하면 merge에 대한 새로운 커밋이 생긴다.

Reset으로 병합을 취소하면 병합했을 때의 내용(exp에서 master로 추가된 내용)이 commit 형태로 남아있다.