[Github] 깃허브를 사용한 협업 개발

 

이 글에서는 깃허브를 통해 협업 개발을 하는 과정을 CLI 기준으로 정리하겠다.

이슈에 따른 브랜치 생성, 메세지 컨벤션, commit, push, pull request와 merge하는 방법과 함께 기본적인 리눅스 명령어도 소개될 예정이다.

MC2 프로젝트를 하면서 우리 팀에서 사용했던 방법이므로, 이 방법 외에 다른 방법도 있으며, 절대적인 규칙은 아니다.

 

또한 이 글은 아래의 사항들을 전제로 한다.

1. 깃허브에 대한 기본적인 지식이 있다.

2. 깃허브에 팀 레포지토리가 생성된 상태이며, 프로젝트 파일의 뼈대가 완성되있는 상태이다.

3. main브랜치 외에 개발을 위한 develop 브랜치가 생성되어있는 상태이다.

 

---

 

1. 이슈생성

1. Issues 규칙에 맞춰서 생성
   • Issue 제목 규칙

   [Issue 종류] 뭘 할지 한 줄 정리
   
   ex) [Feat] 탭바 추가 - 홈, 메세지 문구, 수신함
   

   • Issue 종류
     • FEAT(feature): 기능
     • BUG: 오류 수정
     • REF(refactory): 코드정리
   • Issue 라벨 선택
     • bug: 버그 고치기
     • documentation: 문서작업
     • enhancement: 새로운 기능
     • help wanted: 도와주세요!
2. 브랜치 생성
   • creat a branch 버튼 클릭해서 생성
   • 브랜치명은 이슈명 그대로
   • 커맨드 복사

 

2. Clone 및 브랜치 생성

1. 터미널에서 클론
   • 레포에 클론 링크를 복사해놓은 상태로 터미널에서 클론할 위치로 이동(`pwd`, `ls`, `cd`)
   • `git clone [복사한 링크]` 를 통해 클론
2. 브랜치 생성 및 이동
   • clone받은 위치로 이동 후, 이전에 복사한 브랜치 커맨드를 붙여넣기
   • 브랜치가 생성되면서 새로운 브랜치로 바뀜
   • 깃헙 레포와 xcode에서 브랜치 변경 확인

 

3. Commit 및 Push

1. commit
   • Xcode에서 코드작업 진행
   • 터미널에서 `git status`를 통해 수정된 상태(빨간색 modified) 확인
2. commit message
   • `git add .` 를 해줘서 업데이트된 내용 반영
   • `git commit -m “[커밋메세지]”` 를 통해 커밋메세지 작성
   • Commit Message 규칙

   [Issue 종류/#Issue 번호] 한 줄 정리
   
   ex) [Feat/#22] 탭바 추가
   

   • 터미널로 커밋메세지 남기는법 예시

   git commit -m “[Feat/#123] 한 줄 정리 (엔터) 설명 작성"
   
   * 쌍따옴표는 설명 포함하고 작성하기
   
   ex) git commit -m “[Feat/#123] 뭘 바꿨는지 대충 설명
   큰따옴표로 안닫고 엔터 눌러서 줄바꿈 하면 여기가 자동으로 description이 됨 ㅋㅋ”
   

3. push
   • `git push`로 push

 

4. Pull request

1. 깃헙 레포로 돌아오면 상단에 push한 내용 반영됨
   • Compare & pull request버튼을 클릭
2. Compare & pull request
   • merge할 브랜치와, 현재 브랜치 잘 확인
   • 터미널에서 입력한 커밋메세지 및 description이 잘 반영되어있는지 확인
   • Create pull request 클릭
3. pull request
   • Commits, Files changed에서 올린 커밋과 코드에 바뀐부분 확인 가능
   • Files changed의 +버튼을 눌러서 코드리뷰 가능

 

5. Merge 및 pull

1. 두 명의 approval이 있으면 merge 가능
   • 빠른 작업을 위해 풀리퀘 날렸다고 카톡으로 말해주고 승인해주기,,
2. Merge pull request 버튼 클릭
3. pull
   • 터미널에서 `git checkout develop`을 통해 develop 브랜치로 이동
   • `git pull`로 로컬의 develop 브랜치 최신화
4. 사용 완료한 브랜치 삭제
   • git branch -d [브랜치명] 을 입력해서 작업 브랜치 삭제
     • 브랜치명은 이슈번호 누르고 tab하면 자동완성
     • 꼭 develop브랜치로 바꿨는지 확인
   • `git branch`로 브랜치 삭제되었는지 확인

 

6.  브랜치 최신화 및 conflict 해결

1. 내가 A라는 브랜치에서 작업하고 있는 도중에 다른 사람이 develpo 브랜치에 작업물을 올려 최신화가 된 상태! 나도 그 최신화된 상황에서 작업하고 싶다면
   • 현재 작업중인 브랜치를 commit 또는 stash를 통해 임시로 처리
   • `git checkout develop`을 통해 develop 브랜치로 이동
   • `git pull`을 통해 develop 브랜치 최신화
   • `git checkout A`를 통해 내가 작업하던 브랜치로 이동
   • `git merge develop`을 통해 최신화된 develop 브랜치를 A 브랜치로 병합
2. merge를 할 때 conflict가 발생 (이를 방지하기 위해 commit보다는 stash 사용하는것이 좋음)\
   • merge를 했는데 오류메세지와 함께 실패했다면 CONFLICT 뒤에 어떤 파일에서 conflict가 났는지 확인할 수 있음
   • 해당 파일명을 복사해 `open [복사한 파일명]` 을 통해 파일을 엶
   • Cmd + F 를 통해 “HEAD” 혹은 “<<<<” 를 검색해서 conflict난 부분을 찾음

<<<<<<< HEAD

[A 브랜치의 내용]

=======

[Develop 브랜치의 내용]

>>>>>>> develop

• HEAD와 === 사이, 그리고 ===와 develop 사이의 내용에서 차이가 있기 때문에 conflict가 발생한 것이다
• 하나의 내용으로 통일하고 나머지를 지워주는 식으로 파일을 수정한 뒤 꼭 Cmd + S로 저장!
• 다시 터미널로 돌아가서 merge를 하면 성공

 

기타 리눅스 명령어

• `git restore .`: 헉 내 브랜치인줄 알았는데 devleop이었다 ㄷㄷㄷ ⇒ 브랜치 원래 상태로 되돌리기
• `git stash`: 내가 한 작업물을 커밋하지 않고 다른 브랜치로 이동할 경우 conflict가 남 ⇒ 내가 해놓은 작업을 잠시 다른곳에 보관!
  • `git stash`, `git stash save` 이 두 개의 명령어로 stash 작업을 해놓으면 작업물을 안전하게 저장
  • `git stash pop`: 저장해놓은 작업물을 불러옴
  • `git stash apply`: pop을 이용하면 저장공간의 파일이 지워지는데, conflict날 것을 대비해 저장공간에 저장은 유지한 상태로 불러오고싶다면 apply