현재까지의 진행 상황을 보니 대부분 아직 GitHub를 이용한 개발 협업에 익숙하지 않으신 것 같아요! 사전 설명이 부족했음에 반성하며.. Git 협업에 대해 조금이나마 도움을 드리고자 본 문서를 작성하게 되었습니다.
깃허브 특) 분명 개발자를 돕기 위해 만들어진 건데 뭔가 어렵고 스트레스 받아서 보면 깃허브임 하지만 개발자와 뗄레야 뗄 수 없는 관계인 GitHub.. 협업에서 어떻게 사용하면 좋을지 간단하게 알려드리니 도움이 되셨으면 좋겠습니다 :)
깃허브를 활용한 협업의 핵심은 쉽게 말해 각자 다른 부분을 작업해 합치기(merge)라고 할 수 있습니다. 별도의 브랜치에서 누구는 A를, 누구는 B를 작업한 뒤 이를 합쳐 A+B의 최종 작업물을 만드는 거죠! 이 문서에서는 각자 작업 내용을 어떻게 나누고, 어떻게 관리하며, 어떻게 합치고, 합친 내용을 다시 어떻게 반영하는지까지 세션 실습, 나아가 해커톤 실전에서까지 써먹을 수 있는 GitHub 협업의 기초를 다룹니다
먼저, 브랜치를 구분해야 합니다. 우리는 지금까지 main 브랜치 하나만 사용해서 코드를 관리해왔어요. 하지만 모두가 같은 브랜치에서 같은 파일을 작업한다면 코드가 꼬이거나, 충돌이 나게 됩니다. 이를 Conflict라고 해요😱
Git을 활용해 다른 사람과 함께 개발 협업을 하기 위한 첫 단계는 바로 브랜치를 나누는 것입니다. 브랜치는 어떻게 나눌까요? 보통 실무에서는 해당 브랜치에서 작업하는 내용을 바탕으로 브랜치를 만들어 구분하고(이 방식에 대해서는 하단의 부록 - Git Flow에서 더 자세하게 설명해드리겠습니다.), 야매긴 하지만 인원 별로 브랜치를 파서 관리하는 경우도 있습니다.
작업 내용 기준이든, 담당자 기준이든 이렇게 브랜치를 나누고 나면
merge) 합쳐진 작업물 만들기
이때, 이 합쳐진 작업물 코드에는 에러가 없어야 합니다. 즉, 에러가 남아있는 코드를 전체 작업물로 보내서는 안 됩니다.rebase 또는 pull)의 순으로 GitHub 협업의 전체적인 흐름이 진행됩니다. 제일 먼저 할 것은 브랜치를 나누는 거에요!
브랜치를 나누고, 각자 어느 브랜치에서 무얼 작업할지 정하는 것까지 되었어요! 그렇다면 각자 브랜치에서 각자의 작업 내용은 어떻게 관리하면 될까요? 이때 필요한 것이 바로 **커밋(Commit)과 커밋 메시지(Commit message)**입니다.