[Project] github 이슈 및 브랜치 완벽 정리

📌 개인적인 공간으로 공부를 기록하고 복습하기 위해 사용하는 블로그입니다.
정확하지 않은 정보가 있을 수 있으니 참고바랍니다 :😸
[틀린 내용은 댓글로 남겨주시면 복받으실거에요]

연휴가 왔고, 우리 팀은 그 시간 동안 각자 코드를 작성해서 Git에 올리기로 했다.

---

ISSUE 카드 및 LIST 작성

회의를 통해 Issue 카드를 클래스별로 나눠서 작성하기로 했고, 이슈 번호도 랜덤이 아닌 순차적으로 맞추기로 했다

그래서 이슈 카드와 이슈 템플릿을 미리 작성해두고 각자 담당 클래스를 이슈를 올린 후 브랜치를 만들고 거기에 commit → push 후 dev에 merge 하기로 합의 했다.

1. 이슈 리스트 작성

   

2. 이슈 템플릿 만들기

   

   

3. 이슈 카드 작성

   

처음에는 간단한 CRUD 구현부터 시작했는데, 금방 끝나서 dev 브랜치에서 새로운 브랜치를 따고 코드를 올리려고 하니, 벌써부터 충돌이 발생했다. 알고 보니 .gitignore 파일을 설정하지 않아서, 각자의 환경에 따른 파일들이 추적되며 충돌이 일어난 것.

결국, 다들 연휴 동안 각자 로컬에서 코드를 작성한 후 한 번에 올리기로 했다. Git이 협업을 위해 사용되는 도구라지만, 그 순간만큼은 차라리 복사하고 붙여넣는 게 나을 것 같았다.😥😂

그래도 팀원분이 브랜치 사용법을 예쁘게 정리해주어서 이대로만 하니까 그 이후에는 거의 충돌이 없긴 했다.

브랜치 사용법 정리

1. 로컬 환경에서 파일 저장 위치에서 레포지토리 클론하기:

    git clone (레퍼지토리 주소)
   

2. 작업 시작 전에 최신 dev 브랜치로 동기화하기:

    git checkout dev
    git pull origin dev
   

3. 새로운 기능 작업을 위해 새로운 브랜치 생성:

    git checkout -b (branch name)
   

   우리 팀은 브랜치 이름을 feature/no이슈카드번호-이슈카드이름 형식으로 규칙을 정했다. (예: feature/no1-MemberEntity)

4. 새 기능 코드 작성

5. 코드 작성이 끝나면 dev 브랜치와 다시 동기화 확인:

    git checkout dev
    git pull origin dev
    git checkout (생성한 branch이름)
    git merge dev
   

   이 과정에서 충돌이 발생하면, 작업 도중 누군가 dev에 merge한 내역에서 생긴 충돌을 해결해야 한다.

6. 코드가 완성되면 원격 저장소에 push:

    git add (구현한 기능 관련 파일들만)
    git commit -m "feat: 이슈카드이름 (#이슈번호)"
    git push origin (새 브랜치 이름)
   

7. GitHub에서 dev 브랜치로 PR 보내기
8. 다른 기능 작업 시 2번부터 반복⚡⚡

문제는, push 후에 repository가서 merge할 때 자꾸 dev가 아닌 main에 합치는 실수를 하곤 했다. revert를 함부로 눌렀다가 올렸던 파일들이 삭제되기도 하고… 한마디로 난리였다.

그래서 GitHub의 기본 브랜치를 main에서 dev로 바꾸고 나니, 그나마 실수가 줄었다.

덕분에 이제는 하루에 팀원들 것까지 합쳐서 70개 넘게 올렸다. 정말 장족의 발전이다. 이게 프로젝트를 하고 있는 건지, GitHub 공부를 하고 있는 건지 헷갈릴 때가 많다. 그래도 조금씩 나아지고 있으니 다행이라고 해야 할까?

이런 시행착오 덕에 팀워크도 점점 맞춰지고, Git 사용법도 점점 익숙해지는 것 같다.

Project 카테고리 내 다른 글 보러가기