워크플로 | Notion

<aside> 💡 이하의 모든 내용은 여러분이 git의 기본적인 사용법을 안다고 가정합니다. 스테이지, 커밋, 버전 관리, 브랜치 등등의 용어와 뜻을 아신다면 충분합니다.

</aside>

<aside> 💡 이 문서의 내용은 아직 완벽히 작성되지 않았으며, 불친절합니다. 대략적 개요로만 생각하시고 자세한 내용은 아래 참고자료를 통해 직접 알아보셔야 합니다.

</aside>

git을 사용해 일관적으로 협업을 할 수 있는 방법입니다.

간단한 프로젝트이기 때문에 중앙집중식 워크플로를 사용하며, 풀 리퀘스트를 사용하지 않습니다.

다수의 feature 브랜치를 만들어 사용하며, release 브랜치를 사용하지 않습니다. (그야 릴리즈가 한번밖에 없으니)

이외에는 git flow와 상당히 비슷합니다.

과정

저장소를 만들거나 clone합니다. 각 저장소에 대한 설명은 GitHub 조직 문서를 참고하세요.
develop 브랜치와 main 브랜치를 만듭니다. 이미 있다면 있는 걸 사용합니다. develop은 현재 개발중인 버전을 의미합니다. 다른 사람과 코드를 합쳐서 테스트 할 때 좋습니다. main 은 정상적으로 작동하는, (부분적으로) 완성된 버전을 의미합니다.
해당 저장소에서 자신의 변경사항을 가리킬 브랜치를 하나 만듭니다. 이를 feature브랜치라고 합니다. 이름이 feature 인 것은 아니고 어떠한 이름이어도 일단은 상관 없습니다. 어떤 변경사항을 담는지 고려해 적당한 이름을 붙혀 주세요. 브랜치를 만드는 것은 자신의 변경사항이 다른 사람의 변경사항에 의해 덮어씌워지는 등의 이슈를 방지하기 때문에 유용합니다. 또한 feature 브랜치는 간단한 변경사항(특정한 기능 추가 등)을 담기에 좋습니다. 만약 같은 브랜치를 사용한다면 서버로 푸시를 보낼 때 상대방이 먼저 커밋을 했다면 푸시가 실패할 수 있습니다. 이 경우
서버에 올라가 있는 (최신 버전의) 브랜치를 pull합니다.
로컬에서 <remote>/<branch>와 merge를 진행합니다.
서버로 해당 브랜치를 다시 push합니다.
그 후 변경사항들을 적용하며 커밋들을 만듭니다. 커밋 메세지를 작성하는 적절한 방법은 커밋 규약 문서를 참고하시면 좋습니다.
기능 구현을 완료했다면 develop 브랜치로 수정사항을 보냅니다. (develop 브랜치에서 현재 feature 브랜치를 merge 합니다) 만약 머지를 진행하던 중 충돌이 발생한다면
develop 브랜치를 pull 합니다.
로컬에서 merge conflict가 발생합니다. 적절히 이를 해결합니다.
해결된 버전을 develop 브랜치에서 fast forward로 가져옵니다.
3으로 돌아가 다시 새 기능을 구현합니다.
만약 충분히 개발이 완료된 것 같으면 develop 브랜치의 내용을 main 에 반영합니다.

대안

위의 내용을 꼭 반드시 지켜야 하는 것은 아닙니다.

위의 내용을 이해하기 힘드시거나 적용하기 마땅치 않다면 대안으로, 자기 자신의 브랜치 딱 하나를 만든 후 그 브랜치에 우선 지속적으로 커밋을 하는 방법이 있습니다.

다음 명령어를 따라하세요:

$ git clone <저장소>
$ cd <저장소>
$ git checkout -b <내 이름>
$ # 변경사항을 만듭니다.
$ git add .
$ git commit -m "커밋 메세지" # 커밋 규약 참고
$ # 또다른 변경사항을 만듭니다.
$ git add .
$ git commit -m "커밋 메세지 2"
$ # 원하는 만큼 커밋하신 후
$ git push origin <내 이름>
# 미리 설정한 이름과 github 인증 토큰이 필요합니다.