팀 프로젝트에 필요한 Organization 생성부터 이슈 관리, pull requset, git flow에 대한 글입니다.
git 초보자가 팀 프로젝트를 준비하면서 정리한 글입니다. 틀린 부분이 있을 수 있습니다.
처음 팀플을 시작하시는 분들에게 어느 정도 도움이 되었으면 좋겠습니다.
git에 대한 기본적인 사용법을 아시고 보면 좋습니다.
git 사용법이 서투시다면 해당 사이트에 문제를 푸시는 것을 추천드립니다.
https://learngitbranching.js.org/?locale=ko
Learn Git Branching
An interactive Git visualization tool to educate and challenge!
learngitbranching.js.org
상황
프론트 n명 백엔드 n명의 소수 인원의 팀 프로젝트
프론트와 백엔드 리포지토리 분리해서 작업
1. Organizations(조직) 생성
orgnizations을 생성해 주는 이유는 물론 선택이지만, 우리는 프론트와 백엔드의 리포지토리를 분리해서 만들기로 결정했기 때문에 하나의 조직 안에 두 개의 리포지토리를 생성해 줄 것이다.
(하나의 리포지토리에 백엔드와 프론트 폴더를 같이 넣는 경우도 있다.)
사용법
깃 프로필 클릭해서 Your orgnizations 클릭
new 조직 생성 클릭
토이 프로젝트는 Free로 충분하다고 한다.
차례대로 조직이름과 접촉할 이메일 알맞게 체크해 준 뒤에 Next를 누른다.
팀원의 이메일을 입력해서 초대하면 된다. 그다음 Complete setup를 누르면 드디어 조직 생성이 완료됐다.
처음 organizations을 보았을 때 뭔지도 모르고 어려울 것 같아서 클릭조차 해 보지 않았었는데, 막상 생성해보니 Repository를 조직원들끼리 쉽게 공유할 수 있는 편리한 기능 중 하나였다.
정말 간단하게 조직을 생성할 수 있었다.
2. 리포지토리 생성
조직 안에서 프론트 리포지토리와 백엔드 리포지토리를 만들어서 각각 개발을 이어나가면 된다.
3. 팀 단위 개발
이제부터는 본인이 맡은 개발 레포지토리에 들어가서 어떻게 개발 프로세스가 돌아가는지 알아보겠다.
1) clone vs fork
먼저 원격 레포지토리를 내 컴퓨터에 가져와야 한다. 아마 기존에 혼자 git을 사용했을 때는 clone을 사용했을 것이다. 하지만 clone 말고도 fork 방식이 존재한다.
두 방식에 대한 설명이다.
1. clone을 통해 해당 레포지토리를 나의 local 저장소로 바로 가져온다.
2. fork를 통해 해당 레포지토리를 나의 깃허브 레포지토리로 가져온 뒤에 clone을 통해 local 저장소로 가져온다.
위 그림을 보면 쉽게 이해할 수 있을 것이다. fork 방식은 나의 깃허브로 옮겨오는 과정이 추가되었을 뿐 그 뒤에는 clone과 동일하다.
clone 방식과 fork 방식에는 각각의 장단점이 존재하며, 딱히 어느 방식이 더 맞다는 결론을 낼 수 없었다.
우리는 좀 더 편의성이 있는 clone 방식을 선택하겠다.
ChatGPT에 물어본 결과
일반적으로 git clone은 자신의 계정에 별도의 복사본을 만들지 않고 프로젝트에서 직접 작업할 수 있기 때문에 팀 프로젝트에 더 나은 옵션입니다. 이렇게 하면 다른 팀 구성원과 더 쉽게 공동 작업하고 변경 사항을 기본 프로젝트에 다시 제출할 수 있습니다. 그러나 git fork는 기본 프로젝트에서 허용되지 않을 수 있는 변경 사항을 실험하려는 경우와 같은 특정 상황에서 유용할 수 있습니다.
(하지만 다른 시니어 개발자 글에는 fork를 선호하였다)
2) 프로젝트를 로컬 저장소에 등록
!!!! 이미 팀장이 리포지토리에 프로젝트 세팅 작업을 마친 상태라고 가정한다. 팀원인 우리는 해당 프로젝트를 clone 해서 로컬 저장소로 가져온다.
이제 프로젝트를 clone 하여 본인 컴퓨터에 연결해주면 된다. (과정 생략)
$ git clone '주소'
$ git remote -v
origin https://github.com/test20230106/backend.git (fetch)
origin https://github.com/test20230106/backend.git (push)이렇게 결과가 나오면 된다.
3) 이슈 관리
이슈 관리란 팀에서 개발할 기능 목록을 게시글 형태로 작성하여 작업 진행상황을 기록하는 시스템이다.
이슈 = 기능
이슈를 관리해줌으로써 개발 진행 상태를 간편하게 알 수 있다. 즉 본인이 개발할 기능(이슈)을 남들에게 알려줌으로써 혼선을 막을 수 있다.
이슈를 관리해주는 도구는 많이 존재하지만 우리는 깃허브에서 제공하는 기능을 사용할 것이다.
Issues와 Projects 두 개를 사용하면 간편하게 이슈를 관리할 수 있다.
4) Projects 생성
먼저 프로젝트를 생성한다. 프로젝트는 이슈를 모아놓는 저장소라고 생각하면 된다.
이슈를 관리한다는 것을 결국 개발 진행 상태를 알아보기 쉽게 관리한다는 것과 같은 말이다.
이에 table 형태로 볼 수도 있고 Board 형태(칸막)로 볼 수 있다. 우리는 Board 형태로 관리할 것이다.
만들게 되면 이렇게 화면이 뜬다.
간단하게 설명하자면
1. 앞으로 개발할 기능 리스트는 Todo에 넣어준다.
2. 개발이 진행될 경우 In Progress로 이동시켜 준다
3. 개발이 끝난 경우 Done에 이동시켜주면 된다.
하지만 해당 화면에서 직접 이슈를 추가하는 일을 잘 없을 것이다. 실제로는 연동을 통해 이슈를 생성하고 이동시켜줄 수 있다.
5) 이슈 등록
새롭게 개발해야 되는 기능이 추가되었다. 이슈 칸에 들어가서 이슈를 생성해 주자.
1. 이슈 제목
2. 이슈 내용
3. 이슈를 진행할 사람
4. 라벨 : 해당 이슈가 어떤 유형인지 표시할 수 있는 해시태그와 같으며 라벨 내용을 추가하거나 수정할 수 있다.
5. 아까 위에서 만들어 준 프로젝트와 연동시켜 준다.
이슈가 잘 생성되었다. 프로젝트의 이슈 상태를 Todo로 설정해주고 Project로 가보면 자동으로 추가되어 있다.
6) 이슈 지정
등록된 이슈 중 본인이 진행할 이슈를 고른다.
Assigness에 본인을 등록시키고 이슈 상태를 In Progress로 변경한다.
이제부터는 실제로 해당 이슈에 맞는 개발을 진행해주면 된다.
7) Git flow 전략
깃 전략은 git flow를 사용한다.
git flow는 협업에서 효율적으로 branch를 관리하기 위한 일종의 방법론(규칙)이다.
총 다섯 개의 브랜치가 있다.
master : 제품이 출시되는 브랜치, [항상 유지]
hotfixes : 제품 출시 후 긴급 버그 발생 시 만들어지는 브랜치, [생성 후 삭제]
release : 제품을 출시하기 전에 버그가 존재하는지 체크하는 브랜치 [생성 후 삭제]
develop : 개발을 진행하는 브랜치 [항상 유지]
feature : 기능을 개발하는 브랜치 [생성 후 삭제]
지금 당장은 develop, feature만 신경 쓰면 된다.우리는 feature 브랜치를 생성하여 기능을 개발하고 develop 브랜치에 merge 하는 과정을 실습한다.
git flow는 생각보다 까다롭기 때문에 직접 깃 실습을 통해 익히는 게 좋다. git flow를 자세히 담기에는 게시글이 너무 길어질 거 같아서 좋은 블로그 글을 남긴다.
https://velog.io/@diduya/git-%ED%9A%A8%EC%9C%A8%EC%A0%81%EC%9D%B8-%ED%98%91%EC%97%85%EC%9D%84-%EC%9C%84%ED%95%9C-Git-Flow-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-git-branch-repository
8) develop 브랜치 생성
main(=master)은 출시에 사용하는 브랜치이기 때문에 기본적으로 develop 브랜치에 merge 할 경우가 많다. 따라서 develop 브랜치를 디폴트로 설정한다.
아까 만든 develop 브랜치를 default 브랜치로 변경한다.
변경하고 다시 레포지토리로 돌아와서 잘 적용되었는지 확인한다.
로컬 저장소도 main 브랜치 대신에
git branch develop 명령어를 통해 develop 브랜치를 생성해 준다.
9) 개발 진행
개발 환경으로 이동한다. 개발 순서는
1. 기능에 맞는 git branch 생성 및 이동
2. 개발 진행
3. add commit push 작업
4. pull request 요청
순서대로 진행해 보자.
1. 기능에 맞는 git branch 생성 및 이동
브랜치 이름의 경우 feature/이슈넘버-기능이름 으로 정한다. 브랜치명은 딱히 정해저 있지 않기 때문에 팀원끼리 잘 상의해서 정하면 된다.
아까 우리의 이슈넘버는 1이고 테스트를 진행 중이기 때문에 feature/1-test 로 branch를 생성한다.
git branch feature/1-test // 브랜치 생성
git checkout feature/1-test // 브랜치 이동
위 작업을 한 줄로 하면
git checkout -b feature/1-test // 브랜치 생성 + 이동
2. 개발 진행
저는 간단하게 README.md 파일을 수정하겠습니다.
3. add commit push 작업
git add .
git commit -m 'test 1'
git push origin feature/1-test
4. pull request 요청
깃허브에 들어가 보면 pr(pull request) 요청화면이 뜨고 pr 요청을 보내면 된다.
1. merge 할 브랜치 선택 (develop에 merge 해야 된다.)
2. pr 제목
3. pr 내용
4. 리뷰해줄 사람 지정
5. 기능 구현한 사람 지정 (기존 issue와 동일하게)
6. 라벨 지정 (기존 issue와 동일하게)
7. 프로젝트 지정, 이미 issue에서 등록해줬기 때문에 생략한다.
1. 요구되는 조건을 만족해야 merge 될 수 있도록 규칙을 정할 수 있다. (여기서는 생략)
이곳에서 프로젝트에 대한 리뷰를 진행한다. 팀원들의 리뷰가 끝나고 merge 여부가 허용되면 Merge pull request 버튼을 누르고, 최종적으로 develop 브랜치에 merge가 된다.
이제 필요 없어진 feature/1-test 브랜치를 삭제해 준다.
1~4 번까지 개발 사이클을 볼 수 있었다.
다음 추가적으로 기능을 개발해야 될 경우 로컬에 있는 develop 브랜치를 최신상태로 만들어 줘야 한다.
git checkout devleop // develop 브랜치로 이동
git pull origin develop // 최신 상태 pull로 가져옴이 상태로 만든 뒤 다시 1번부터 작업을 진행하면 된다.
10) 이슈 마감
끝낸 이슈를 정리해 준다.
1. 연동된 프로젝트에 이슈 상태를 Done으로 바꿔준다.
2. 이슈를 닫아준다.
잘 이동된 모습니다.
+
추가적으로 local에 있는 브랜치가 쌓이게 되면 삭제하고 싶을 수 있다.
git branch -d "브랜치이름" 으로 삭제할 수 있지만
git branch -a 을 하면 원격에 있는 브랜치는 아직 남아있다.
git fetch -p 를 하면 원격 주소의 브랜치와 동기화시켜주기 때문에 remotes/origin/feature/1-test 브랜치가 사라진다.
참고자료
백엔드가 이정도는 해줘야 함 - 3. 개발 프로세스 정립
이번엔 백엔드 포지션에서 어떤 방식으로 개발을 진행할지를 결정하자. 개발 프로세스 정립에 대해 두 가지의 의사결정을 진행할 것이다. 도입 이유 개발 프로세스는 어떻게 이슈를 관리하고,
planbs.tistory.com
https://dallog.github.io/git-branch-strategy/
달록팀의 git 브랜치 전략을 소개합니다.
이 글은 우테코 달록팀 크루 매트가 작성했습니다. Git-flow git 브랜치 전략 중 하나이다, 이것은 어떠한 기능을 나타내는 것이 아니라 방법론이다. 각각의 프로젝트와 개발 환경에 따라 알맞게 수
dallog.github.io
https://www.theserverside.com/answer/Git-fork-vs-clone-Whats-the-difference
Git fork vs. clone: What's the difference? | TheServerSide
What's the difference between Git fork and clone? In this article, we compare and contrast these two Git repo copy strategies.
www.theserverside.com
+ 우테코 git 팀프로젝트 레포지토리를 많이 참고했습니다.
'개발 도구 > github' 카테고리의 다른 글
| 내가 보려고 정리한 깃 사용법 #기초 #리눅스 환경 (0) | 2022.01.25 |
|---|
댓글