[Git 특강] 2. git & github으로 협업하는 법 (branch, switch, checkout, merge, stash, reset, revert, pull request)

 

 

 

 

 

1. 브랜치 활용하기

 

 

 

• 보통 수정은 하고 싶은데, 원래 파일은 그대로 놔두고 싶을 때 복사본을 만듦
  그러나 프로그래밍의 경우 프로젝트 하나 하나의 크기가 엄청 커질 수도 있어 현실에서 복사해서 쓸 수가 없음
• 복사본 == 브랜치
• 새로운 기능은 브랜치를 만들어서 진행하는 것이 필수

 

 

 

브랜치(복사본) 생성 : git branch

 

 

git branch 브랜치이름
ex) git branch cart

• 'git branch 브랜치이름' 으로 브랜치를 생성

 

git branch

• git branch를 입력하면 브랜치 확인 가능
• 별표가 있거나 색깔이 다르면 내가 위치해 있는 브랜치
• 흰색으로 떠 있으면 내가 만든 브랜치
• 혹시 END로 떠서 아무것도 입력 안 되면 키보드 Q 누르면 됨

 

 

 

현재 있는 브랜치 이동 : git switch 혹은 git checkout

 

git switch <브랜치명>
ex) git switch login

혹은

git checkout <브랜치명>
ex) git checkout login

 

• 위의 명령어로 이동 후, git branch로 확인해보면 지금 있는 브랜치 표시가 바뀐 걸 확인 가능
• 원래는 git checkout라는 명령어만 있었으나, checkout은 기능이 여러가지라 헷갈려서
  브랜치 이동만을 위한 git switch라는 명령어가 최근에 새로 생김
• 옛날 회사에서는 아직도 git checkout 쓰는 경우도 있음. 둘 중 하나만 쓰면 됨

 

 

 

브랜치 한 번에 생성 & 이동 : git switch -c 혹은 git checkout -b

git switch -c 브랜치 이름

혹은

git checkout -b 브랜치 이름

• 보통은 일하다보면 생성(branch)/이동(switch) 따로하기보다는 이것만 씀
• switch -c는 create의 약자
• checkout -b는 branch의 약자

 

 

 

새로운 브랜치에서 코드 수정

1. git switch 브랜치명으로 새로운 브랜치로 이동
2. git add .
3. git commit -m "저장메시지"
4. git switch 로 기존의 main 브랜치로 다시 이동하면 수정한 코드가 보이지 않음을 알 수 있음
   -> 원본은 변경하지 않고, 새로 만든 브랜치에서만 코드를 변경한 것 (복사본 수정)

 

 

 

코드 짠 브랜치를 main에 합치기 : git merge

git switch 최종브랜치이름(main) // 1. 원본 브랜치로 이동
git merge 합칠재료브랜치이름(login) // 2. 합칠 기능 브랜치를 입력

• 안전하게 다른 브랜치에서 기능을 개발하였으니, 원본 코드로 합쳐야 함 (협업 관점)
• main 브랜치로 먼저 이동한 후, 합칠 기능브랜치를 땡겨 옴

 

 

 

코드 임시저장 : git stash

git stash -u -m "어떤 기능 개발중이었는지 간단한 메시지"

• 코드 변경 후 저장(add, commit)을 하지 않으면 git switch가 작동하지 않을 때가 있음
  (이동하는 브랜치의 코드와 내가 변경한 코드에서 겹치는 부분이 있을 때 이동이 안 됨)
• 이런 경우 저장(add, commit)을 해주어야 해결되지만,
  급하게 브랜치를 이동하거나 개발이 덜 된 상황이라 저장하기 싫을 때가 있음
• 이런 경우 git stash로 임시 저장하고 switch로 브랜치 이동 가능
• -u는 untracked 파일들의 변경사항도 모두 저장하겠다는 뜻 (untracked 파일의 예시: 새로 만든 파일)
• -m 은 커밋 메세지처럼 어떤 기능을 개발하는 중이었는지 간단하게 메세지를 작성하는 옵션

 

git stash list

• git stash list 명령어로 임시로 저장된 부분 확인 가능
• q로 빠져나옴

 

git stash apply stash@{숫자} // 숫자 부분은 git stash list 명령어로 확인

• 잠시 저장했던 것을 되돌리고 싶을 때 입력

 

 

 

과거의 커밋으로 돌아가기 : git reset 혹은 git revert

• 협업 시 문제가 될 수 있으므로 어쩔 수 없는 상황이 아니라면 사용 비추 (다른 사람들도 커밋 내역 변경, 코드 꼬임)
• 현업에서 쓸 일은 거의 없음

git reset --옵션 커밋id

git reset --hard 5dc14b

• 과거의 커밋으로 완전히 되돌아가는 git reset
• 과거 커밋이 모두 사라지고 파일도 과거 버전으로 되돌아 감
• 옵션 종류: --hard, --mixed, --soft
• 고유 아이디: git log 명령어로 확인한 커밋 아이디의 문자열 5~6개

 

git revert 커밋id

• 과거 커밋을 다음 커밋으로 만들어 되돌아가는 git revert
• git reset처럼 완전히 커밋이 사라지는 것은 아니기 때문에 그나마 안전
• git revert 명령어를 입력하면 충돌(conflict)가 발생하는데, 기존과 겹치는 부분에서 변경이 있으니 결정하라는 것
• 충돌 시 git add . 와 git commit -m "커밋메시지" 입력으로 끝냄
• 충돌이 발생하지 않았다면 커밋 메시지 입력하고 끝냄

 

git revert

 

 

 

vim

• 텍스트 편집기
• git commit 시 -m 옵션을 사용하지 않으면 vim 텍스트 편집기가 열림
• 깃허브에서 conflict 혹은 git pull 시 만날 수 있음
• vim이 떴을 때 키보드 i를 누르면 ---INSERT--- 표시가 나오고 커밋 메시지 작성 가능
• 메시지 작성이 끝나면 키보드 ESC
• : + w + q 를 순서대로 입력 후 엔터 치면 커밋 메시지 저장 완료

 

 

 

⚠️ hint: waiting for your editor to close the file*. 에러 발생시 / 혹은 vim이 아니고 다른 것이 뜰 시

• git config --global core.editor "vim"

 

⚠️ LF will be replaced by CRLF the next time Git touches it 라는 경고문이 뜰 시

• (win) git config --global core.autocrlf true
• (mac) git config --global core.autocrlf input

 

 

 

 

---

 

2. Pull Request 활용하기

 

• 사실 협업 시 git merge 명령어로 합치는 경우는 거의 없음
• 터미널이 아닌 github에서 합치자
• 코드 리뷰 온라인에서 받고, 온라인에서 합치는게 충돌 여부 확인, 테스트 자동화 등 점검에 편하기 때문
• github에서도 merge와 같은 기능: Pull Request
• 당겨와 합치는 것(Pull)을 요청(Request)한다 라는 뜻

 

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

git switch -c 브랜치명

혹은

git checkout -b 브랜치명

 

2. 코드 작성

 

3. 코드 변경 저장

git add .
git commit -m "update: 로그아웃 기능 생성"

 

4. github에 코드 업로드

git push origin 브랜치명
ex) git push origin logout

 

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

6. base: 최종(기본)브랜치 / compare: 재료(기능)브랜치 설정하고
Pull request 메시지 작성 후 Create pull request 클릭해서 생성

7. Files changed에서 코드 변경점 확인, 여기서 코드 리뷰 가능

8. Merge pull request 버튼 누르고 Confirm merge 하면 합쳐짐

9. 로컬에도 반영: git checkout 브랜치명으로 이동, git pull origin 브랜치명으로 가져오기

 

 

 

---

 

3. 협업 시 생길 수 있는 문제점

 

 

문제점1 : 완벽하게 기능 개발해야 merge 가능

• 사용자한테 공개할 정도로 만들어야 메인 브랜치에 넣는건데, 기능을 다 구현하는데 너무 오래 걸림
• 전체적으로 보니 버그가 어디서 난 건지 찾기가 어려워서 버그 수정 오래 걸림
• 해결책: 개발용 브랜치 생성 (dev 혹은 develop)
  1. Main 브랜치(배포용)
  2. Develop 브랜치(테스트용)
  3. 기능 브랜치(기능 개발용)
  합치는 것을 Develop 브랜치로!

 

문제점2) Main 브랜치(배포용 브랜치)에 그냥 합치면 위험함

• 5번째 줄 코드가 val name = "상품명" 인 코드와 3번째 줄 코드가 val name = "회원명"인 코드가 합쳐진다면?
• 깃에서는 인지하지 못해서 그냥 합쳐지지만 에러가 생기고, 모두 다 같이 에러를 가져가게 됨
• 해결책: 로컬에서 먼저 테스트
  내 컴퓨터(로컬)에서 git pull origin dev 로 불러와 먼저 합쳐보기
  충돌 시 해결법 파악 용이

 

 

---

 

4. 협업 실전 가이드

 

 

1. 초기 세팅

1. 팀장: 초기 코드 작성 및 github 업로드

1. 폴더 생성
2. 짧은 초기 코드 작성
3. git init, add, commit
4. Github 레포지토리 생성
5. Github 업로드 (git push)

2. 팀장 : dev(혹은 develop) 브랜치 생성

1. git switch -c dev (로컬에서 dev 브랜치 생성)
2. git push origin dev (github에도 반영)

3. Github에서 dev 브랜치를 default로 설정

• Settings - Default branch - dev 누르고 Update 클릭

4. 팀원들을 Collaborator로 등록

5. 팀원: git clone 하기 (git clone 주소 .)

 

 

 

2. 기능 개발 시작

1. 기능 브랜치 생성 및 기능 개발

1. 기능 브랜치 생성 (git switch -c 기능브랜치명)
2. 코드 작성
3. 코드 업로드 (git add . / git commit -m "" / git push origin 기능브랜치명)

2. pull request 생성

3. 코드 작성자: 리뷰 요청하기 (Reviewers)

4. 코드 리뷰어: 리뷰하기

1. +를 눌러 작성, Finish로 완료
2. Comment는 의견
   Approve 승인
   Request changes 거절

5. 합치기 전 내 로컬에서 충돌 해결 및 테스트

• 내 로컬 속 기능 브랜치에서 git pull origin dev
• fatal: Need to specify how to reconcile divergent branches. 에러가 뜬다면
  git config pull.rebase false 입력 후 다시 입력

6. merge

1. 수정사항이 있는 경우 add, commit, push
2. Github에서 merge 버튼 클릭

 

 

 

3. 추가 기능 개발

1. 내 로컬의 dev에도 변경 사항 반영

1. dev 브랜치로 이동 (git switch dev)
2. git pull origin dev

2. 다음 기능 개발

1. 기능 브랜치 생성 및 코드 작성
2. Git add, commit, push
3. Pull request 생성 및 코드 리뷰
4. 내 로컬에서 충돌 해결 및 테스트
5. 코드 업로드 및 merge
6. 무한 반복

 

---

 

git flow (출처: 우아한형제들 / https://techblog.woowahan.com/2553 )

 

• main(master): 제품으로 출시될 수 있는 브랜치
• develop : 다음 출시 버전을 개발하는 브랜치
• feature : 기능을 개발하는 브랜치
• release : 이번 출시 버전을 준비하는 브랜치
• hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치