GIT

GIT을 사용하는 이유

하나의 폴더 내에서 코드의 변경점을 기록하기 위해 사용

1. 기능을 개발하면서 코드 변경점을 "기록"할 수 있다.
2. 문제가 생겼을 때 특정 지점으로 되돌아 가는 것이 쉽다.
3. 내 코드를 온라인 저장소에 백업을 할 수 있고, 협업 시 코드를 공유하여 함께 작업이 가능하다.

프로젝트 복사본 만들고 코드 변경 후 저장하기

기존 코드에 영양을 주지 않도록 코드의 복사본을 만드는데, 이것을 브랜치(branch)라고 한다.

브랜치 만들기

git branch <브랜치명>

브랜치 생성 확인 -> 키보드 q를 입력하여 빠져나오면 된다.

git branch

브랜치 이동하기(둘 중 하나만 사용)

git switch <브랜치명> // 최근에 나옴
git checkout <브랜치명>

브랜치를 만드는 동시에 이동하기(둘 중 하나만 사용)

git switch -c <브랜치명> // -c 는 create의 약자
git checkout -b <브랜치명> // -b는 branch의 약자

브랜치에서 코드 변경 후 코드 저장

git add .
git commit -m "수정사항 작성"

main에 저장한 코드 확인(둘 중 하나만 사용)

git switch main
git checkout main

main에 가서 확인해도 브랜치에만 저장했기 때문에 main에는 코드가 수정되어 있지 않음
-> 브랜치에 있는 코드를 메인으로 합쳐야함

코드 합치기(순서 절대 바뀌면 안됨!)

git switch main // 원본 브랜치(main)로 이동을 먼저 해준다
git merge <브랜치명> // 새롭게 기능을 개발한 <브랜치명>을 merge를 써서 코드를 합쳐준다.

협업을 위한 pull request

실제 협업 시 git merge 명령어로 바로 합치는 경우는 거의 없고 github에서 합친다.
그 이유는 merge 전에 코드리뷰가 가능하고 충돌 여부 확인 및 테스트 자동화 등 다양한 이점이 있기 때문이다.

Pull request의 의미는 코드를 “기본 브랜치(main)로 당겨와 합치는 것(Pull)을 요청(Request)한다” 라는 뜻이다. 쉽게 말해 코드를 합쳐도 되는지 팀원들에게 물어보는 것이다.

1. 브랜치 생성 및 브랜치 이동

git switch -c <브랜치명>
git checkout -b <브랜치명>

2. 코드 수정 후 코드 변경 저장

git add .
git commit -m "수정사항 작성"

3. github에 코드 업로드

git push origin <브랜치명>

4. github 홈페이지에서 Compare & pull request 버튼 클릭

• Compare & pull request 알림이 안생기거나 사라졌다면 Pull requests 탭 클릭 후 New pull request를 누르면 됨

5. Create pull request 클릭

최종 브랜치(main) <- 기능 브랜치(새롭게 기능을 개발한 브랜치명)

6. pull request 생성 결과

Files changed 메뉴에서 코드 변경점 확인 가능

7. merge 하기

Merge pull request 버튼 클릭 -> Confirm merge 버튼 클릭

8. 내 로컬 컴퓨터에서 다시 기본 브랜치(main)으로 이동

Your branch is behind ‘origin/main’ by 2 commits, and can be fast-forwarded.
(use “git pull” to update your local branch)
→ “github repository보다 뒤쳐져있으니 git pull 명령어로 똑같이 맞추세요” 라는 뜻

9. git pull 명령어로 온라인 저장소(github repository)의 코드와 내 로컬 저장소의 코드를 똑같이 맞추기

git pull origin <브랜치명>

10. 그림으로 살펴보기

협업 시 참고사항

• 큰 프로젝트일 경우

1. 코드를 분리해서 만들기
   모든 기능이 한 파일에 종속되어 있는 것보다 기능 중심으로 잘게 쪼개서 만드는 것이 좋다.
2. 모듈화
   똑같은 기능을 두 사람이 만들어버리는 불필요한 상황을 피하기 위해 한 사람이 만들고 그 것을 가져와서 쓰는 것이 좋다.
3. 브랜치명은 기능명으로
   브랜치명만 보고도 기능을 알아볼 수 있도록 기능명으로 설정해두면 좋다.
4. 코드 리뷰 정하기
   코드 리뷰를 언제 어떻게 할지 미리 정해놓는 것이 좋다.
5. commit 메세지 정하기
   팀원이 서로 알아볼 수 있도록 최대한 상세하게 적는 것이 좋다.
6. 기능 중심으로 분업화
   한 페이지 안에서 기능 위주로 나눠서 두 사람 이상이 작업 후 브랜치를 합칠 수도 있다.
7. 코드 스타일 정하기
   변수 스타일이나 들여쓰기 등 사소하지만 협업 시 신경쓰이는 부분을 미리 정해두는 것이 좋다.

느낀 점

미니 프로젝트에서는 git을 전혀 사용하지 못해서 이번 팀프로젝트에서 처음으로 사용해봤는데, 너무 어려웠다. 팀원들의 도움을 받아 git clone하고 브랜치를 만들고 git pull 등 여러가지를 해봤는데 사실 명령어는 둘째치고 충돌하거나 내 코드가 팀원들의 잘 짜여진 코드에 똥망진창으로 흩뿌려질까봐 너무 걱정이 됐다. 비교하면 안 되는데 코드 작성 속도도 느리고 내가 들인 시간만큼 원하는대로 결과물이 나오지 않아 많이 속상했다. 그래도 팀원분들이 많이 토닥여주셔서 눈물 닦고 코드를 하나씩 작성해나가는 중인데 내일은 조금 더 만족스러운 결과물을 만들어내고 싶다.