Git으로 협업하기

6개월 간의 인턴을 마무리하며 인수인계서를 쓰고 있다.

그런데 다음 인턴분께서 Git을 사용해본 적이 별로 없으신 것 같아 인수인계서 쓰는 김에 Git 사용법+그 외 프로젝트 할 때 주의사항이나 참고하면 좋을 것들도 같이 정리해서 블로그에도 공유해본다.

 

 

Git을 사용해서 코드를 관리하는 방법은 대체로 아래 순서를 따릅니다.

 

이슈 생성→브랜치 생성 및 브랜치 변경→작업→commit→push→PR→merge→pull

 

1. 이슈 생성하기

Git Repository에서 Issues를 클릭하고 New issue를 클릭합니다

 

title과 description을 씁니다

Assginees에는 보통 assign yourself를 클릭해서 자기 자신을 선택합니다

본인이 맡은 이슈는 본인을 assgin하고 같이 하거나 다른 사람이 맡는 일은 다른 사람 assign 하면 됩니다.

 

 

Labels이나 Milestone은 저희 프로젝트에서는 따로 안썼는데 쓰고 싶으시면 도입하는 것도 좋을 것 같아요~

 

 

마크다운을 쓰시면 이렇게 편하게 글을 쓸 수 있습니다

Submit new issue 클릭!

 

 

 

이렇게 이슈가 생성이 되었습니다.

이슈가 생성되었으면 브랜치도 만들러 가볼까요?

 

2. 브랜치 변경 및 작업

아마 대부분 git flow를 이용하면 main브랜치에서 배포하고, develop에서 개발, feat 브랜치에서 기능 개발을 진행할겁니다.

git checkout -b feat/#이슈번호/브랜치명

 

터미널에 입력하여 브랜치를 생성 및 변경합니다.

 

여기서 npm run dev로 실행시키고, 작업 후 커밋합니다.

 

 

잠깐, 이슈 번호는 어디서 확인할까요?

 

이슈의 제목 옆에 연한 글씨로 적혀있습니다.

 

3. Commit & Push

 

변경 사항을 저장

git add .

 

커밋

git commit -m "feat/#이슈번호: 작업 내용"

 

푸시 (로컬 저장소에서 원격 저장소로 업로드)

git push origin 브랜치명

 

Git Convention은 본인 작업 스타일에 맞춰서 편하게 변경해서 쓰시면 됩니다

예시 이미지는 에러처리가 필요해서 브랜치명을 fix로 시작했는데 fix, feat, chore 등 용도에 따라 바꾸세요!

 

보통 아래 규칙을 많이 따라서 작업합니다

feat	새로운 기능 추가
fix	버그 수정
docs	문서 변경
style	코드 형식 변경(공백, 세미콜론 등의 변화가 없는 경우)
refactor	코드 리팩토링
test	테스트 코드 추가/수정
chore	그 외 자잘한 작업

 

커밋을 할 때 #이슈 번호를 커밋메세지에 넣으면 이렇게 이슈 페이지에 커밋 내역이 뜹니다.

이슈 번호 필수! ( 빼먹으면 해당 브랜치에서 작업해도 이슈에서 안보임)

4. PR 하기

만약 git push origin까지 했다면 Pull requests에 Compare&pull request 버튼이 뜰 텐데, 이 버튼을 누르면 바로 Pull Requset를 만들 수 있습니다.

 

만약에 노란 Compare&pull request 버튼이 뜨지 않더라도 아래의 New pull request를 눌러서 PR을 할 수 있으니까 당황하지 마세요

base에는 최종적으로 병합할 브랜치, compare에는 새로운 기능을 개발한 브랜치를 선택합니다.

 

merge가 가능한지 확인하고 Create pull request를 누르면

 

맨 첫번째 사진에서 Compare&pull request를 누른 것과 같이 Open a pull request 창을 볼 수 있습니다.

 

 

여기서 Write 부분에 작업 내용, 관련 이슈, 스크린샷, 추가사항 등등을 적고 Create pull request를 누르면 됩니다.

 

코드 리뷰를 받고 싶다면 Reviewers 톱니바퀴 버튼을 클릭해 팀원을 넣어줍시다. 그럼 팀원에게 메일이 가서 PR을 확인할 수 있어요!

 

타이틀은 보통 feat, fix, chore 등 기능 표기와 이슈 번호, PR 설명으로 간단하게 적습니다

[feat/#이슈번호] 이슈제목 이런식으로 썼어요

 

 

제목에 #이슈번호를 적고, closed #이슈번호, close #이슈번호 등을 입력하면 자동으로 PR에 관련 이슈가 연동되고 PR merge 시 이슈가 닫힙니다. 연결하지 않으면 자동으로 닫히지 않아 직접 닫아줘야하는 번거로움이 있으니 PR할 때 이슈번호를 까먹지 않고 추가하는 것을 추천드립니다

 

PR을 하면 이렇게 브랜치 간 충돌이 없는지 등을 체크해줍니다

저는 AWS Amplify를 이용해 PR마다 Web Preview링크를 생성하게 세팅해둬서 항상 PR 시 체크를 해줘요

Amplify 내부에서 Web Preview링크를 생성하기 위해 새로 빌드를 하기 때문에 빌드 오류가 발생하진 않는지 확인할 수 있어 편리합니다.

 

만약 빌드 오류가 발생했다면?

AWS amplify에 접속해 로그를 확인하고, 빌드 시 어느 부분에서 오류가 났는지 확인할 수 있습니다.

그러나 AWS amplify까지 접속하기는 귀찮기 때문에 저는 그냥 로컬에서 npm run build 눌러서 빌드해보고 여기서 터미널 로그 보고 에러를 잡았습니다.

 

npm 명령어는 어디서 확인할 수 있나요?

package.json의 scripts에서 명령어를 확인할 수 있습니다.

 

npm run lint를 하면 js convention에 따라 어느 부분을 어떻게 고치면 코드를 더 깔끔하게 작성할 수 있을지 알려줍니다

뭘해야할지 모르겠다.. 싶을 때 콘솔을 보고 리팩토링해보는 것을 추천합니다

check가 끝나기 전에 merge 하면 안됩니다

check가 영원히 pending상태에서 안끝나는 수가 있어요 amplify 오류인 듯

 

체크가 완료되었으면 Merge pull request를 눌러 merge를 완료합니다.

 

Create a merge commit, Squash and merge, Rebase and merge 등 다양한 머지 전략이 있는데요, 저희 프로젝트는 소인원으로 진행했기 때문에 머지와 커밋 내역을 깔끔하게 정리하는게 굳이 필요하진 않을 것 같아서 Create a merge commit을 썼습니다.

• Create a merge commit은 merge를 위한 커밋을 생성해 merge를 진행합니다.
• Rebase를 쓰면 merge를 위한 커밋을 쓰지 않을 수 있고,
• Squash는 해당 브랜치의 커밋 내역을 하나로 합쳐 main, develop 브랜치의 커밋 내역을 PR 단위로 깔끔하게 관리가 가능합니다.

아래 글을 읽으면 이해가 좀 더 쉬우실 거예요

 

[ git ] Merge, Squash and merge, Rebase and merge 차이

[ git ] Merge, Squash and merge, Rebase and merge 차이

 

Merge pull request 버튼을 누르고 merge를 해주면 PR이 닫히면서 merge가 됩니다.

Delete branch 눌러서 브랜치 삭제하면 끝!

만약 이미 PR을 했는데 커밋을 더 하고 싶으면 어떻게 해야할까요?

• PR이 닫히지 않았다면 이미 PR을 생성했어도 해당 브랜치에 마저 작업 후 커밋, 푸시하면 됩니다.

 

5. Pull 받기

develop 브랜치로 내가 만든 feat 브랜치를 병합했으면 다시 pull을 받아야겠죠?

현재 작업 중인 브랜치에서 develop 브랜치로 브랜치를 변경합니다.

git checkout develop

 

그 후 원격 저장소에서 코드를 pull 해옵니다.

git pull origin develop

 

그 다음, 새롭게 개발하고 싶은 기능이 있다면,

이슈 생성→브랜치 생성 및 브랜치 변경→작업→커밋→푸시→PR→merge 순서대로 반복합니다.

 

끝!

 

6. 추가사항

git을 사용할 때는 VScode의 터미널을 bash로 설정하는 것을 추천드립니다.

 

powershell 보다 터미널이 알록달록해서 가독성이 좋고 우측에 현재 브랜치 명이 뜨기 때문에 헷갈려서 잘못된 브랜치에서 작업할 확률이 줄어들어요.

 

 

 

notion으로 작성하고 pdf로 뽑았다.

 

너무 기본적인거도 다 적었나...? 리액트 넥스트 처음 쓸 때 npm start인지 npm run dev인지도 헷갈렸던 기억이 나서... 다다익선의 마음으로 적었다.

 

인턴이 끝나니까 기쁘기도 하고 아쉽기도 하고 걱정되기도 하고.. (나의 인생, 미래, 우리 회사와 내가 하던 프로젝트의 미래 등등이..)

 

잘 되었으면 좋겠다.

 

화이팅!