[팀 프로젝트] Github 프로젝트 관리자로 활동하면서.. - 1차 병합완료

들어가며

이번 포스팅의 목적은 "당신의 발자취" 안드로이드 개발자로 활동하면서,

Github 관리자가 되어서 활동한 경험들에 대한 느낀점과 새롭게 배운점을 기록하기 위한 포스팅이다.

 

# 사담

우선, 어쩌다보니.. 프로젝트 Github 관리자가 되었다.

UMC 3기 앱 런칭 프로젝트에 참여하는 안드 팀원분들 중 Github로 협업 프로젝트를 진행해본 경험이 있는 사람은

나 밖에 없었다.

처음에는 Github를 통한 협업 관리하는 방법을 배우기 위해서 프로젝트에 참여했지만, 그렇지 않아서 많이 당황했다.

그리고, Github를 통한 프로젝트 코드관리는 이전 경험을 비추어 보았을 때, 내가 "주도적으로" PR을 관리하는 입장이 아니라

PR만 보내는 팀원 중 한명에 속할 뿐이었다.

그래서, Github 관리자로써 Github를 통한 프로젝트 코드 총괄하는 방법을 모르는 상태이기에 많이 당황했었던 기억이 난다.

 

처음에는 많이 당황하긴 했지만, 규모가 큰 Github 관리자로 활동해보는 경험도 드물고, 이때까지 배웠던

Git 협업 방식을 적용해보고, 이끌 수 있다는 소망에
나는 UMC 3기 앱 런칭 프로젝트의 안드로이드 부문 Github 소스코드 관리를 진행했다.

 

# 정리

이번 포스팅은 "당신의 발자취" 안드로이드 파트의 개발진으로 속하면서

Github 관리자로써 활동해본 경험을 회고를 진행하겠다.

 

---

Github - flow 전략

프로젝트 Github 브랜치 관리전략으로는 "Github - flow" 전략을 채택하여 사용하였다.

이전 여름방학 UMC 2기 웹 런칭 프로젝트에선, "Git - flow" 전략을 사용했지만,

해당 전략을 사용하는 이유는 2기 프로젝트에선 Git - flow 전략으로 코드를 관리하면서, 불필요한 브랜치가 많아서 PR에 대한

코드를 병합시킬 때 로직이 복잡했었다.

그래서, 이번 프로젝트에선 Git-flow 전략보단, 단순한 "Github - flow" 전략을 사용했다.

 

 

# Github - flow 전략에 따른 Github 협업방식 공유

Github-flow 전략을 채택하고 난 후, 안드 팀원분들에게 해당 전략을 통한 Github 협업 방식에 대해서 설명하였다.

Github를 통해서 모든 팀원들이 소스코드를 받아와서, Push & PR을 보내기에,
모두가 Github 협업 방식을 제대로 이해하는 것이 우선이라고 생각했기에 설명하는 과정을 거쳤다.

 

좋은 리더란, 자신이 지니고 있는 생각들을 함께하는 구성원들에게
이해하기 쉽게 설명하고, 프로젝트 상황속 감정적으로 대응하는 것이 아닌, 프로젝트가 올바른 방향대로 흘러갈 수 있도록
이성적으로 판단하고 의견을 제시하고 방향을 결정하는 사람이라고 생각한다.

그런 면에서, 이번 경험은 좋은 리더가 되기위한 "발판"이 되었다고 생각한다.
팀원분들은 Github를 통한 프로젝트 관리 경험이 없었기에, Github 전략을 통해 프로젝트를 관리하는 방법 & Github를 사용하는 방법이 익숙치 않았다. 그래서 나는 Github를 처음사용하는 분들에게 Github 전략을 통해 협업을 진행하는 것을 이해시켜야 했다.
이번 경험을 통해 깨닫게 된 점은 남들이 모르는 무언가를 이해하기 쉽게 설명하기 위해선,
"사례를 든 설명"이 효과적이라는 사실을 깨닫게 되었다.
이 부분에 대해선, 프로젝트 과정 중 세세한 부분이기에, 추후에 프로젝트가 성공적으로 완수되고,
프로젝트 전체 회고록에 기입하도록 하겠다.
"프로젝트 전체 회고록"은 "당신의 발자취" 안드로이드 리드 개발자로 활동하면서
과정, 느꼈던 점, 새롭게 배운점, 깨달은 점들을 세세하게 기록할 에정이다.

 

---

main 브랜치 구성

본격적으로 개발을 시작하기 위해, main 브랜치에

모든 팀원이 동일한 템플릿 구성으로 개발을 시작하기 위한 초기 프로젝트 파일을 올려두었다.

 

Github를 통한 협업 관리를 위해선, 모든 팀원들이 동일한 "커밋 계층"에서 개발을 시작하고,

개발이 완료되었을 때, 초기에 셋팅해둔 main 브랜치에 소스코드를 병합한다.

그래서, Github 협업의 기초인 모든 팀원들이 동시에 개발을 진행할 수 있는

"초기 개발 템플릿"을 구성해두고 main 브랜치에 올려두었다.

 

초기 템플릿 구성은 다음과 같이
바텀네비게이션의 클릭이벤트에 따라서
화면 전환만 발생하도록 세팅을 해두었다.

 

초기 템플릿을 구성한 사항에 대해선,
앱 프로젝트가 완전히 끝난 뒤 "프로젝트 전체 회고록"에 구성한 과정을 자세히 기록해두겠다.

 

 

# gitignore 설정

main 브랜치에 대한 초기 템플릿 구성 중
중요한 요소들 중 하나인 .gitignore 파일에 대한 설정이다.

 

.gitignore 파일은 git 시스템이 파일에 기입한 파일들은 Github의 커밋 파일로 인지할 수 없도록 설정하는

Github 설정파일이다.

그래서, .gitignore 파일에 대한 구성은
프로젝트에서 사용하는 개발 스택에 따라서 달라진다.

이에 대해선, 초기에 Github 관리자가 설정해두고, main 브랜치에 올려두어야 하기에,
초기 템플릿을 구성하면서, 함께 진행하였다.

gitignore.io

gitignore.io 웹사이트를 사용하면, 자신의 프로젝트 환경에 따른 .gitignore 파일의 적절한 구성에 대해서
자동으로 파일 내용을 생성해준다.

그래서, 해당 웹사이트에서 이번 프로젝트의 개발 스택인

Android, AndroidStudio, Kotlin 에 대한 .gitignore 파일을 생성해뒀다.

 

 

---

main 브랜치 구성완료 & 개발 시작, 완료

main 브랜치를 초기 템플릿으로 구성이 완료하여
나를 비롯한  팀원 모두 각자 맡은 사항에 대한 개발을 시작하였다.

main 브랜치 코드를 클론하여 Github - flow 전략으로 개발을 시작하는 방법은 아래와 같다.

• git clone {Github 원격 저장소 레포 URL}
  
  
• git branch {feature/자신이 맡은 개발 파트}
  (feature 브랜치 로컬에 생성)

• git checkout {feature/자신이 맡은 개발 파트}
  (로컬에 생성한 feature 브랜치로 이동)
  
  

• 로컬 브랜치에서 개발 시작
  
  

로컬 브랜치에선 개발이 완료되면, git add & git commit 을 수행하여
로컬 저장소에 개발사항을 반영한다.

그리고 반영이 정상적으로 완료되면, git push origin feature/{자신이 맡은 기능} 명령으로

원격저장소의 feature 브랜치로 프로젝트 코드를 올린다.

 

원격저장소에 프로젝트 개발한 사항이 반영된 걸 확인 한 뒤,
feature 브랜치의 코드를 main 브랜치에 병합 요청인 "Pull Request"를 보낸다.

 

해당 사항이 나를 비롯한 팀원 모두가 진행했던 사항이다.

안드로이드 개발 파트에 따라서 분담된 자신의 파트가 개발이 완료하고,

해당 작업을 거쳐 원격저장소에 자신이 맡은 feature 브랜치에 개발완료한 코드를 올리고,

PR을 보내는 과정을 진행했다.

 

---

PR 받아서 병합

팀원들의 모든 PR을 받아서 main에 병합을 진행하는 과정은 Github 관리자인 내가 진행했다.

PR을 받아서 병합하는 과정은 생각보다 단순했다.

 

과정을 요약하자면 다음과 같다.

- PR 받기

- 충돌유무 판단

- 충돌 시 충돌 크기에 따른 충돌 해결

- 충돌이 작은 경우

      - Github 웹 사이트에서 해결

- 충돌이 큰 경우

      - 로컬에서 main 브랜치와 충돌 발생한 feature 브랜치를 가져와서
         main & feature을 merge 후
         로컬에서 충돌 해결 (해결 후 테스팅 & main 브랜치에 push)

 

- 충돌 없애고, main에 병합
   

- 병합되어 업데이트된 main 브랜치 로컬에서 pull 받아와서 테스팅

 

 - 테스팅 성공 시 다른 feature 브랜치 PR 병합작업 진행

 

 

 

# 충돌 해결과정 (Github 웹 사이트 내 해결 - 작은 충돌)

다음과 같이 다소 적은 파일에서 충돌이 발생하면,

Github 웹 사이트 자체에서 충돌을 해결할 수 있는 툴이 제공된다.

그래서, 작은 충돌은 다음과 같이 충돌이 난 파일 하나하나씩 쉽게 충돌을 해결할 수 있다.

 

충돌은 초기 템플릿에서 같은 파일의 같은 줄을 동시에 다른것으로 수정할  때 발생한다.

그래서, 이 점을 유의해서 충돌을 해결할 때는

main의 코드와

feature의 코드를 비교해가면서, 새롭게 추가되고,
중복되는 요소는 제거한 채 충돌을 해결하면 된다.

 

충돌을 해결하는 방법은
생각보다 단순하다.

충돌 원리 자체가 같은 파일에 존재하는 특정한 줄의 코드를 여러 사람이 수정했을 때 발생하기 때문에
그 점만 인지하고, 충돌을 해결하려고 한다면, 쉽게 충돌난 사항을 해결할 수 있다.
(단, 충돌이 나기 전 Github에 올라온 코드들은 에러가 없이 정상적으로 동작이 되는 코드라는 가정하에 병합을 진행한다.)

 

# 충돌 해결 시 유의할 사항

- 동일 코드 중복 기입여부

- 테스팅 동작 사항

---

마치며

이번 UMC 3기 앱 런칭 프로젝트에서, 우연치 않게 안드로이드 파트 리드 개발자로 활동하고 있다.

처음에는 이끌어본 경험이 적기도 하고, 이렇게 큰 프로젝트에서 리드에서 이끈적은 한번도 없었기에,

걱정과 불안이 가득했었다.

그래도, 처음 겪어보는 큰 프로젝트에서 리드해서 프로젝트를 완성하는 경험을 쌓을 수 있다는 소망덕에

포기하지 않고 안드로이드 리드 개발자로 책임감있게 활동 중이다.

 

# 리드 개발자로써 활동하며 느낀점

리드 개발자로 프로젝트에 임하면서 많이 느끼고 있는 점은.. 프로젝트에서든 조직에서든 리드에서 구성원들을 이끄는 역할은

정말이지, 말로 설명할 수 없을정도로 강한 책임감을 지녀야한다는 점이다.

이번 경험을 통해 "책임감"을 효율적으로 사용하는 법도 기르고, 구성원들 간의 효율적으로 소통하는 방법들을 많이 배우는 중이다.

 

# 레퍼런스는 모든 정보를 가지고 있다.

리드 개발자로 활동하면서 또다른 새로운 느낀점은 "레퍼런스"는 뭐든지 다 지니고 있다는 점이다.

처음 접하는 분야여도, 직접 구글 검색이든, 커뮤니티 질문으로 리드해서 이끄는 방법 또한 쉽게 알아낼 수 있다.

그래서, 처음 접하는 분야에서의 리드하는 역할을 받더라도, "레퍼런스" 검색만으로도 충분히 해당 프로젝트에서 이끄는 사람으로

자라날 수 있다는 사실을 깨달았다.

 

# 리드하는 자리에서의 결정은 "강요" 가 아닌 "설득"으로 작용해야한다.

리드하는 자리에서 내리는 결정들은 곧,

소속한 구성원들의 방향성이 되어지고, 이에 따른 행위로 이어진다.

그렇기에, 리드하는 자리의 결정은 "강요"로 이루어진다면,

구성원들은 협업 시너지를 만들어 낼 수 없다.

"진실되게, 리드자의 결정에 공감하지 않기 때문에, 비효율적인 작업을 하기 때문이다."

 

따라서, 소속한 구성원들에게 리드하는 자리의 "결정"을 이해할 수 있게

리드하는 사람이 구성원들을 "설득"시켜 소속한 구성원 모두가 공동의 방향성 대로

프로젝트가 진행할 수 있도록 노력해야한다는 점을 깨달았다.

 

"주장은 곧, 고집이 될 수도 있다."

" 고집은 협업 시너지를 만들어내지 못한다. "

 

해당 깨달음에 대해선,
리드하는 자리로써 활동하면서 느꼈던 점을 내 생각을 토대로 기입했다.
그래서, 이 점에 대해선, 흘려보기를 권장한다.
나 또한 이 부분에 대해선 "리더는 매일 평균대에 선다" 라는 책을 추후에 읽어보면서 내 생각을 구체화해볼 것이다.

 

# 프로젝트가 절반이상 진행되며, 생각정리

처음에 안드로이드 개발자로써 프로젝트의 구성원으로 합류했을 때는 이번에도

프로젝트 경험이 풍부한 사람들과 프로젝트를 진행하면서 많이 배워야겠다 라는 생각을 하고 참여를 했지만,

이번 프로젝트는 2기 프로젝트의 "빙글"님의 자리가 내 자리가 되었다.

 

회의를 몇차례 가지면서, 해낼 수 있을까? 라는 생각과 함께 부정적인 생각이 머릿속에 가득찼었다.

하지만, 난 이처럼 큰 프로젝트에서 리드해보는 경험을 쌓아서 더 큰 프로젝트를 이끄는 사람이 될 수 있다는 소망과 함께
포기하지 않았고, 그에 따라 "책임감"있게 리드하는 자리로써 PM을 보조하여 활동에 참여하였다.

 

그러면서, 힘들기도 많이 힘들었지만, 프로젝트에 속한 구성원분들과 함께 소통을 하면서 프로젝트에 방향성을 맞추어갔고,

점차 프로젝트가 안정적인 형태로 꾸려지기 시작했다.

그래서, 현재 상황은 안드로이드 개발 파트 1차 부문을 개발이 완료된 사항이고, 후속 개발 (API 작업)및 유지보수만을 남아둔 상황이다.

참 신기할 따름이다. 불가능해보였던 프로젝트가 방향성이 잡힌 채 일정하게 안정적으로 프로젝트가 진행되고 있는 걸 보면,

소망을 가진 채 실천만 한다면, 해낼 수 없는 건 존재하지 않다라는 사실을 깨닫게 해주는 좋은 경험을 경험해오고 있는 중이다..

 

아직, 프로젝트가 끝나진 않았지만, 성공적으로 프로젝트를 마무리하고, 2/15일에 진행하는 UMC 3기 앱 런칭 데모데이에서 꼭
"대상"을 수상할 각오로 앞으로 남은 프로젝트에 임할 것이다.

 

 

프로젝트 전체 회고록에선,
프로젝트 기획 & 설계 & 개발과정을 전체적으로 돌아보면서 기록할 예정이다.
해당 포스팅은 2/15일 지나고, 추후에 업로드 할 예정이다.
그리고, 프로젝트의 리드 개발자로써 활동한 사항에 대해서도 추가적으로 업로드 할 예정이다.