오늘은 Git과 GitHub에 대해 배운 수업 내용을 정리해보려 한다.
자세한 내용은 지난번에 다뤘으나
잘못 알고 있었던 부분, 새롭게 알게된 부분에 대해 정리해 보겠다.
1. 새롭게 알게된 부분
[그림 1] 파일의 상태 변화, 커밋 방법
- 상단의 파일명 폰트 색, 옆의 알파벳을 통해 현재 파일의 상태를 확인할 수 있다.
git commit만 하면 vim 창이 뜬다.- 커밋까지 끝내면 파일명이 흰색으로 돌아온다.
[그림 2] HEAD 위치 확인, 상태 복원
git log: HEAD의 현재 위치를 확인할 수 있다.- 코드 수정 후 staging area로 안올리고
git restore 파일명을 하면 가장 최근 커밋 상태로 돌아간다
(수정했던 내용들 다 사라짐)
[그림 3] 추적하지 않을 파일 관리
- 공개되면 안되는 파일/폴더들은
.gitignore로 관리해야한다. (매우 중요!!!)
2. 브랜치 사용
[그림 4] 브랜치 관리 전략
main을 직접 건드리면,
새로 추가한 코드가 만약 문제가 있을 경우 서비스에 바로 타격이 간다.
해서 새로 작업하는 내용은 브랜치에서 따로 작업 후 문제가 없음이 확인되고 나서
main에도 그 내용을 반영하는 방향이 안전하다.
2.1. Fast-forward merge
[그림 5] 브랜치에서 작업 후 병합하는 방법
git branch 브랜치명: branch 생성git switch 브랜치명: branch로 이동 (main으로 이동이면 브랜치명 대신 main 입력)- branch에서 수정 작업 후 커밋
- 코드 리뷰
- 위치를 main으로 이동
git merge 브랜치명: 병합 진행(main 코드 상태 = branch 코드 상태)
2.2. 3-way merge
위의 경우는 main에서 branch가 하나만 뻗어나왔기 때문에
fast-forward 방식의 merge가 진행될 수 있었다.
그렇다면 main에서 동시에 두 개의 branch가 뻗어 나오고, 서로 다른 작업이 수행됬다면
어떤 식으로 돌아갈까?
[그림 6-1] main에서 뻗어 나온 branch 2개에서 서로 다른 작업을 한 모습(conflict 발생 x)
git log --all --graph: 왼쪽 이미지처럼 tree구조로 확인 가능하다
[그림 6-2] 3-way merge가 일어나는 모습
첫 branch를 병합할때는 바로 fast-forward 방식으로 merge가 진행되는 것을 확인할 수 있다.
하지만 이후 나머지 branch를 병합하려고 시도하자
커밋 메세지를 입력하라고 vim 창이 뜨는 것을 확인할 수 있다.
왜냐하면 지금 branch A에는 branch B에서 작업한 내용이 없기 때문에
임의로 새로운 커밋(그림 기준 commit 6)을 생성한 후
두 상태(그림 기준 commit 5, commit 5-1)를 병합해야 한다.
그 작업이 git merge feat/one을 하자마자 자동으로 일어났고,
커밋 메세지는 병합을 진행하는 사람이 직접 입력할 수 있게 해 준 것이다.
[그림 6-3] branch도 가장 최신 커밋 상태 반영하기
commit 6이 생기고 main이 branch들보다 한 커밋 앞서나가기 시작했다.
사용이 끝났으니 제거 후 나중에 다시 새로 branch를 만들어도 되지만, 재사용 하고 싶다면
브랜치로 이동 후 git merge main을 수행하면 된다.
2.3. conflict 발생
위의 경우는 서로 다른 두 작업이 서로 독립적으로 이루어졌기 때문에 문제가 발생하지 않았다.
하지만 만약 두 사람이 같은 코드를 서로 다르게 수정했다면 무슨 일이 벌어질까?
[그림 7] 같은 코드가 서로 다른 작업자에 의해 건드려진 상황
Branch A, B가 같은 코드(2번째 라인)를
서로 다르게 작업(하나는 !!!!, 하나는 @@@@ 추가)했다고 가정하자
[그림 7-1] conflict 발생한 상황
첫 branch가 병합될 때는 문제 없이 fast-forward 방식으로 병합이 수행되었으나
이후 나머지 branch를 병합하려고 시도하자 충돌이 발생하였다.
[그림 7-2] conflict 해결 과정
vs code로 작업하는 경우, 충돌 상황이 발생하면 위에 4가지 선택권을 준다.
( Accept Current Change | Accept Incoming Change | Accept Both Changes | Compare Changes )
이번 실습에서는 Accept Both Changes를 선택 후 코드를 수정하고,
변경된 코드 저장 후 커밋을 진행해 주었다.
그때 상황에 맞게 코드 리뷰를 마친 후 최종 코드를 작성해서 저장해주면 된다.
(절대 혼자 판단은 금물이다.)
3. GitHub 올바르게 사용하기
3.1. 원격 레포 올바르게 생성/연결하기
[그림 8-1] 로컬에서 작업 끝내고 GitHub 레포 만들 때
그동안 로컬에서 작업한 내용을 GitHub에 올릴 때 계속 충돌이 일어나서 애먹었다.
이번에 그 이유를 알게됬는데, 이미 로컬에 README, .gitignore가 있는데
레포 만들면서 또 README, .gitignore를 만들어서 그랬던 것...
이제 원인을 알았으니 올바르게 만들자ㅎㅎ
[그림 8-2] 정상적으로 로컬 레포와 원격 레포가 연결된 모습
이번 수업에서 fetch해 오는 레포와 push하는 레포가 다를 수 있다는 것을 배웠다.
[그림 8-3] GitHub에서 커밋 변경 내역 확인한 모습
정상적으로 push하고 나면 GitHub에서도 커밋의 변경 내역을 쉽게 확인할 수 있다.
3.2. GitHub로 협업하기
3.2.1. issue로 작업이 필요한 부분 공론화
[그림 9-1] Issue 발생시키는 방법
프로젝트를 관리하며 작업이 필요한 부분들을 issue로 만들어 공론화 시킬 수 있다.
작업이 필요한 내용에 대한 설명, 담당자 지정, 이슈의 성격 분류도 가능하다.
[그림 9-2] Issue가 만들어진 모습
3.2.2. 작업 수행 후 branch에 push하기
[그림 10] 작업 수행 후 branch에 push된 모습
새로 작업하는 내용들은 항상 branch에서 작업 후(로컬)
push할 때도 main이 아닌 branch로 보내는 습관이 되어 있어야 한다.
반드시 새로운 코드가 문제가 발생하지 않는 코드인지 꼼꼼히 확인되고 나서 main에 반영이 되어야 한다.
3.2.3. PR(Pull request)하기
[그림 11-1] PR 하는 방법
수정된 내용이 main에 반영될 수 있도록 PR을 요청해야 한다.
내용에는 어떤 이슈에 대한 작업 내용인지 연결시켜 주는 것이 좋다.
[그림 11-2] 코드 리뷰 과정
PR요청에서 Files changed tap으로 들어가면
코드 라인별로도 코멘트를 달 수 있고, 전체 수정 내용에 대한 코멘트도 달 수 있다.
작업자는 이렇게 달린 코멘트를 확인 후 이후 업무를 수행하면 된다.
[그림 11-3] 컨펌 후 merge되는 과정
최종 승인이 떨어지면 merge가 이루어 진다.
[그림 11-4] 정상적으로 main에 반영된 모습
4. 알아두면 좋은 명령어
git log --oneline: 커밋 정보를 간략하게 확인하고 싶을 때 사용 가능하다git show 커밋번호: 특정 커밋의 상세 정보를 알 수 있다git blame 파일명: 언제 누가 어떤 작업을 했는지 확인 가능하다
