[Git/Github] 협업 프로젝트 시작 - 3 - Git 활용 개발 방식 및 시나리오 (fetch, pull, push)

협업 프로젝트 시작 시 github의 organization(조직) repository 생성과 초기화 설정,
그리고 해당 repository에 팀원들이 접근하여 코드를 가져오고 개발이 진행되는 시나리오에 대해 정리한다.

기본적으로 git flow (main - develop - feature) 규칙을 따른 예시로 설명하며,

이슈 관련 및 branch 명명 혹은 규칙 등은 팀의 컨벤션(룰)에 따라 달라질 수 있음을 염두한다.
 
크게 다음과 같은 파트로 설명한다. (사용 툴 - Git, Github, IntelliJ)
 

1.  [ organization, repository의 생성, 업로드, 설정 (팀장) ]
2.  [ organization repository 연동 및 설정 (팀원) ]
3.  [ Git 활용 개발 방식 및 시나리오 (fetch, pull, push) ]

 
 
 

[ Git 활용 개발 방식 및 시나리오 (fetch, pull, push) ]

0. develop 브랜치 체크 아웃 후 진행

 
수정 사항을 반영하기로 약속한 브랜치 (git flow 의 경우 대체로 develop 브랜치) 로 꼭 check out 을 진행한 후 다음 과정을 거쳐야 한다.
이는 마지막 과정인 push 와 pull request 이후에 진행될 앞으로의 과정에서 반드시 선행되어야 할 부분이다.
(꼭 꼭 대참사를 예방하자. conflict 과 여러 에러의 주범이다.)
 

 
IntelliJ 의 우측 하단 브랜치 명 -> Remote Branches 의 [origin/develop] -> [Checkout] 후 다음 단계를 진행한다.
 
 
 

1. [ 가져오기 - 1 ] organization repository -> 개인 repository (sync fork)

 
협업을 진행 중이라면 다른 팀원 누군가가 이미 우리 코드에 수정을 가했을 수 있다.
만약 그것도 모르고 이전의 코드에 개발을 하다가 반영을 하게 되면, 이미 수정된 코드와 나의 코드가 세게 부딪힐 것이다.
개인 repository 는 organization repository 에 어떤 수정과 변화가 있었는지 알지 못하기에,
개인 repository 와 organization repository 의 버전 (정보) 을 맞춰주는 작업이 필요하다.
해당 과정을 sync fork 로 수행할 수 있다.
 

 
 
 
organization repository 를 fork 한 개인 repository 로 접속하고, [Sync fork] 를 클릭한다.
 

 
다음과 같이 [Update branch] 가 활성화 되어 있다면 organization repository 에 변화가 있었다는 의미이며,
[Update branch] 를 클릭하여 organization repository 의 코드를 개인 repository 에 반영 시킬 수 있다.
 
 
 

2. [ 가져오기 - 2 ] 개인 repository -> IntelliJ (fetch)

 
fetch 의 경우 pull 과 유사하나, pull 이전 안전한 병합을 위해 활용한다.
pull 의 경우 organization 에서 변화가 있다면 내 코드와 충돌이 있든 말든 자동으로 병합하지만,
fetch 의 경우 충돌 부를 수동으로 수정해주어야 하여 더 안전한 병합이 가능하다.
단, fetch 는 변경사항을 확인만 할 뿐 변경된 데이터를 IntelliJ 에 직접 반영하지 않으므로
fetch 로 안전성을 확보한 후 pull 을 사용하는 용도로 활용된다.
 

 
 
IntelliJ 의 기능을 활용하면 간단히 fetch 를 활용할 수 있다. [Git] -> [Fetch] 를 클릭한다.
 

 
 
fetch 가 정상적으로 이루어졌다면 우측 하단에 다음과 같은 알림이 뜨며, 충돌이 날 경우 직접 알림을 띄워 충돌 부를 해결하도록 유도한다. (충돌의 경우는 추후 작성 예정)
 

 
 
 

3. [ 가져오기 - 3 ] 개인 repository -> IntelliJ (pull)

 
pull 의 경우 원격 저장소에 수정된 코드를 IntelliJ 로 실제 반영하는 역할을 한다.
 

 
 
이 역시 IntelliJ 기능을 활용하면 간단히 활용할 수 있다. 
 

 
[Git] -> [Pull...]
 
 

 
이때 유의할 것은 반드시 작업 결과를 반영하기로 약속된 브랜치로 pull 대상을 설정하는 것이다.
main, 혹은 다른 브랜치로 내용을 pull 받아 작업을 진행하고 push 할 경우 끔찍한 conflict 를 발생시킬 수 있다.
pull 받을 브랜치 설정 -> [Pull] 을 통해 수정된 코드를 IntelliJ 에 반영할 수 있다.
 
 
 

4. [ 개발 - 1 ] Issue 발행

 
Github 에서 Issue 를 발행하고 번호를 부여 받으면, 추후 Issue 번호 별로 commit 과 pull request 히스토리를 모아 볼 수 있다. 발행된 Issue 번호는 commit message 에 명시해주어야 한다.
 
organization repository 에 접속하여 다음과 같이 Issue 를 발행한다.
 

 
[Issues] -> [New issue]
 
 

 
이슈 제목, 이슈 내용 작성 -> [Submit new issue]
이때 ` - [ ] ` 마크다운 문법을 활용하여 체크박스를 작성하고, 이후 기능 구현 시마다 체크박스를 닫으며 TODO List 로 활용할 수 있다. 
 
 

 
Issue 를 발행하면 사진과 같이 제목 옆에 이슈 번호가 부여된다. 해당 번호를 commit message 에 첨부하여 히스토리를 모아볼 수 있게 된다.
 
 
 

5. [ 개발 - 2 ] 기능별 브랜치 생성

 
기능 구현 완료 후, 이를 commit 혹은 push 하려 한다면 개인 브랜치를 통해 반영하고 pull request 후 병합해야 한다.
컨벤션에 따라 브랜치 명명 규칙은 다르므로 그에 맞게 브랜치 명은 달라질 수 있다.
중요한 것은 반드시 develop 브랜치에서 시작하여 새로운 브랜치를 생성하고 반영하여야 한다는 점이다.
 
IntelliJ [Terminal] 을 활용하여 다음과 같이 명령어를 활용한다.
 

 
` git checkout -b 브랜치 명 ` 으로 활용하며,
` checkout ` 은 브랜치를 바꾸는 명령어, ` -b ` 는 새로운 브랜치를 만드는 명령어이다.
코드를 먼저 작성하든, 해당 과정으로 브랜치를 만들고 코드를 작성하든 순서는 크게 상관 없다.
 
 
 

6. [ 반영하기 - 1 ] IntelliJ -> organization repository (commit, push)

 
commit, push 의 경우 작성된 코드를 organization repository 에 반영하는 역할을 한다.
자세히 다루진 않겠지만 commit 은 임시 저장을, push 는 저장된 것들을 모두 반영하는 역할이라 보면 되겠다.
원래대로라면 바로 윗단의 저장소에 반영되는 것이 맞겠지만, 이전 게시글의 upstream 설정을 통해 즉각 원격 저장소로 반영되도록 설정되어 있다.
 

 
 
IntelliJ 의 기능으로 간단히 적용할 수 있다.
 

 
[Git] -> [Commit...]
 
 
그럼 다음과 같은 commit 창이 뜨게 된다.
 

 
아직 완벽한 구현이 되지 않아 commit 만 원한다면 [commit] 만 누르고 추가적인 작업을 진행하면 되겠다.
[Changes] 를 통해 변화가 있었던 파일들의 목록을 확인할 수 있고, 항목을 더블클릭 하면 달라진 부분을 시각적으로 확인할 수 있다.
아래에는 commit message 를 작성하는 공간이며, 예시와 같이 이슈 번호를 commit message 에 명시해주어야 issue 란에서 확인할 수 있게 된다. 일전에 발행 받았던 issue 번호를 확인하고 작성해주어야 한다.

작성이 완료 되었다면 [Commit and Push...]

 

 

 

push 까지 진행하게 되면 다음과 같은 창이 뜬다. 

오른쪽 창에는 여태까지 commit 한, 이번 push 로 반영될 모든 정보들에 대한 파일, 패키지 등이 리스트업 된다.

이때 꼭 확인해야 할 부분은 사진에서 별표 표시된 부분처럼, 나의 브랜치가 origin : develop 으로 push 될 것인지이다.

(참고 : 만약 해당 부분이 main 혹은 다른 브랜치 명으로 자동 완성 되어 있다면, 아마 코드 작성 전 pull 받은 브랜치가 main 혹은 다른 브랜치일 가능성을 확인해보고, 심각한 경우 hard reset 후 재작성까지 고려해야 한다.)

main 으로는 절대 보내지 말자.
 

 

 
반영하면 다음과 같이 번호에 맞는 Issue 의 히스토리로 확인할 수 있게 된다. 
단, Issue 에 대한 히스토리는 pull request 가 통과한 내용들에 대해서만 반영된다.

해당 이슈에 대한 개발이 완료 되었다면 개별 체크박스를 체크하고, 아래의 [Close issue] 를 클릭하여 해당 이슈에 대한 기능 구현이 끝났음을 명시할 수 있다. (닫힌 issue 들에 대해서도 commit message 에 이슈 번호를 명시한다면 추가적인 히스토리가 생길 수 있다)
 
 
 

7. [ 반영하기 - 2 ] 개인 브랜치 -> develop 브랜치 (pull request)

 
push 이후 팀원들의 코드 리뷰 및 검증이 끝나면 실제 develop 브랜치에 반영하게 된다. (pull request)
 
push 가 완료되었다면 organization repository 에 접속한다.
 

 
다음과 같이 노란색 창이 상단에 뜨게 되는데, main 브랜치 공간에서 확인할 경우 노란색 창이 2개 뜬다.

(개인 브랜치 -> develop / develop -> main)

절 대 main 으로 가는 pull request 를 건들지 말자.

 

브랜치를 [main] 에서 [develop] 으로 교체 -> 자신이 push 한 브랜치 명의 알림 (노란색 창) 의  [Compare & pull request]
 
 

 
다음과 같은 화면이 나오는데, [Add a title] 및 [Add a description] 으로 제목과 내용에 대해 작성할 수 있으며,
우측의 탭을 이용해 [Reviewers], [Assignees], [Labels] 등을 설정할 수 있다.
 
이때 정말 꼭 반드시 최고 중요하게 merge 되는 브랜치를 develop 으로 설정해두어야 한다.
(main 으로 됐다간 진짜 참사가 난다)
이 부분을 develop 으로 바꿔주면 제목 및 내용이 commit message 를 따라 자동으로 바뀌게 된다.
 
 

 
이후 해당 pull request 에도 번호가 부여되며, 아래 탭을 통해 merge 및 rebase 를 설정할 수 있게 된다.
 
 

 

팀 규칙을 단순 merge가 아닌 rebase로 했을 때엔

[Merge pull reqeust] 의 화살표 -> [Rebase and merge] 
 
 

 
이때 정상적으로 confirm 이 되지 않는다면 수기로 conflict 난 부분을 수정해주어야 한다.
[Confirm rebase and merge]
 
 

 
그럼 다음과 같이 완료 메세지가 뜬다.
 
 
 

0. develop 브랜치 체크 아웃 후 진행

 
아우 pull request 도 했고 고생했다 이제 자야지 ~~
하고 다음 날 branch 안 바꾼 상태로 새로운 기능을 개발하면 재앙의 시작이다.
새로운 코드 작성 전/후(pull request 후),  꼭 0 ~ 3 번을 반복해서 다음에 벌어질 실수를 꼭 꼭 예방하자.
 
 
 
 
 
 
 
이상으로 협업의 기본 준비에 대한 내용을 마침!