ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • #8 팀플과 협업을 위한 git/github - Forking Workflow(2)
    git/팀플과 협업을 위한 git 시리즈 2021. 8. 26. 16:44
    1. 원본 repository를 내 저장소로 fork 하기
    2. 내 로컬(pc)으로 clone 하기
    3. 원본 저장소를 remote 해주기
    > 브랜치가 무엇이고 어떻게 협업할까? Forking Workflow??
    4. 새로운 브랜치를 생성하기
    5. 해당 브랜치에서 개발하기
    6. fork한 나의 repository를 원본 repository에 병합하기 위해  PR(Pull Request) 생성하기
    7. 프로젝트 관리자가 확인 및 리뷰 후, 원본 repository에 merge
    8. 사용했던 브랜치 삭제
    9. 원본 repository를 pull 해서 fork한 내 repository를 최신화

    4번으로 돌아가서 새로운 기능 개발

    브랜치가 무엇인가 그리고 어떻게 협업할까?

     

    이제 branch에 대해 알아볼 시간이다.

    브랜치는 협업의 핵심이다.

     

    branch는 '분기'를 뜻한다.

     

    혹시 알고 있을지 모르겠지만,

    사실 지금까지 우리는 main branch 라는 곳에서 작업을 하고 있었다.

    그러면 새로운 브랜치를 만든다는 것은, main의 코드를 '분기'를 해서 작업을 한다는 것일까?

     

     

    일단 main 브랜치부터 살펴보자.

    메인 브런치는 항상 직진한다.

    언제까지? 프로젝트가 폐기될때까지.

    (얼마전 전역한 군필자의 드립)

     

    즉 이렇게 알파런칭, 베타런칭, 출시를 거쳐도 main은 계속된다.

    (소프트웨어 배포 생명 주기)

     

     

    그러면 처음으로 다시 돌아가서, 개발을 시작해보자.

     

    일단 첫번째로 백엔드 개발자가 로그인 api를 먼저 구현하겠다고 한다.

    오. 백엔드 개발자가 login API 라는 branch를 만들었다.

    그는 해당 branch에서 개발을 계속할 것이다.

     

     

     

    그러던 와중, 프론트엔드 개발자가 들어왔다.

    그리고는 signIn&Up 브랜치를 만들고 작업을 시작했는데, 이 사람 일하는 모습이 심상치 않다.

     

    슈퍼 개발자라 엄청나게 빠르게 회원가입, 로그인 페이지까지 뚝딱 만들어버렸다.

    이런경우에 어떻게 될까?

    앞서 백엔드 개발자가 api를 개발하고 있던 도중에

    프론트엔드 개발자가 ui/ux를 벌써 만들어버렸다.

     

    결과적으로 상관없다!

    branch라는 분리된 공간에서 작업했기 때문이다.

     

    그리고 이렇게 signIn&Up 브랜치를 main 브런치에 merge(병합)를 해준다 !

     

     

     

    그리고 그 뒤에 벡엔드 개발자도 로그인 api를 완성시키고, main 브런치에 merge를 해주었다.

    그렇다면 회원가입과 로그인 기능이 모두 완성되었다.

    그러면 이제 이 서비스에서는 회원가입과 로그인이 가능해진 것이다.

     

    브런치가 무엇인지, 브런치를 왜 쓰는지에 대해 이해가 되었는가?

    지금까지 브랜치를 설명하기 위해 "Feature Branch Workflow" 라는 협업 방식을 사용했다.

     


    Forking Workflow의 협업 과정

     

    위에서 브랜치에 브랜치를 이용한 협업방법에 대해 알아보았다.

    그런데 우리는 위의 방식과 조금 다르게 협업한다.

     

     

    일단 복잡한 개념보다는 그림과 함께 과정을 따라가보자.

    중요한 내용이니 천천히 따라오길 바란다.

     

     

    위 그림이 전편까지 우리가 했던 작업이다.

    원본 repository 를 fork해서 내 저장소로 가져왔다.

     

     


    이제 브랜치를 새로 만들어서 작업을 진행해보자.

    feature-main-page라는 브랜치를 만들어서, 커밋을 두 번하고, push까지 한 모습이다.

     

     

    이제 Pull Request를 통해 merge를 해주어야 한다.

    Pull Request는 프로젝트 관리자에게 브랜치 병합을 요청하는 것을 말한다.

     

     

     


    이제 풀 리퀘스트가 승인되면,

    *** 우리가 생성하고 작업했던 feature-main-page 브랜치가 upstream에 merge 된다. ***

     

    강조하지만, fork한 repository의 main브런치에 병합되는 것이 아니고, 

    원본repository(upstream)에 병합이 된다.

     

     

    그림으로 보자.

     

    짠. 이렇게 upsteam 에 merge가 된다.

    이렇게 되면 여러분들의 최종 목표였던 협업이 된 것이다.

     

     

     


    끝난게 아니다!

    다음 작업을 위해 사용했던 브랜치를 제거해주자.

     

     

    엇? 이렇게 되면 지금 내 저장소에 있는 버전은 내가 작업하기 전이 되어버렸다.

     


    걱정마라. 당신의 결과물은 이미 upstream에 병합되어있다.

     

    pull 이라는 작업을 통해 upstream의 최신 파일을 가져와서 내 저장소도 최신화를 시켜준다.

     

    그 후에 또 개발을 진행해야하거나 수정사항 생긴다면 또 브랜치를 생성하고 작업하면 되겠다.

     

     

     

     

     

     

     

     

     


    Forking Workflow의 작업 방식에 대해 이해가 잘 되었기를 바란다.

     

    혹시라도 이해가 잘 되지 않았다면, 내가 글로 정리한 내용을 보고 다시 한 번 눈으로 따라가보자.

    1. 원본 repository를 내 저장소로 fork 하기
    2. 내 로컬(pc)으로 clone 하기 (clone은 remote 작업이 포함되어 있다.)
    3. 원본 저장소를 remote 해주기 (upstream이라고 부릅니다)
    4. 새로운 브랜치를 생성하기 (feature 브랜치라고 부릅니다)
    5. 해당 브랜치에서 개발하기 (개발-add-commit-push)
    6. fork한 나의 repository를 원본 repository에 병합하기 위해  PR(Pull Request) 생성하기
    7. 프로젝트 관리자가 확인 및 리뷰 후, 원본 repository에 merge
    8. 사용했던 브랜치 삭제
    9. 원본 repository를 pull 해서 fork한 내 repository를 최신화

    그리고 4번으로 돌아가서 새로운 기능 개발.

     

     

     

    위의 순서는 bitbucket을 개발한 atlassian 페이지를 참고했다.

    댓글 0

Designed by Tistory.