📜 제목으로 보기

git-mission

https://github.com/woowacourse/retrospective/discussions/4

  • 미션repo 관리자와 fork하는 페어1페어2가 있다.
    • 관리자(upstream) - 페어1,2(origin) - 각 로컬(local) 형태로 구성할 예정
  1. 관리자는 github에서 repo(git-mission)를 파고, readme.MD를 작성한다.

     README.md
        
     # 백엔드팀
    

    image-20220217114126984

  2. pair1, pair2가 각각 관리자의 repo( 예정upstream) -> fork(origin) -> clone(local)한 뒤

    • main만 있던 repo안에 작업용 각자의 {github_id}

    • 미션repo(관리자repo)는 main만 일단 유지한다고 가정하며,

    • 작업자들은 main fork -> main clone -> local main외 local {본인github_id}를 파서 작업하자.

        git checkout -b is2js<github_id>
      
        git branch -a
      

      image-20220217115249981

      • 우테코와 같이 특수한 경우(관리자 repo가 main이외에 개별 br를 다 가지고 있는 경우)
        • 작업자들은 학습사이트를 통해 생성된 main + 수많은 {본인github_id} fork -> --single-branch하여 {본인github_id} clone ** -> local {본인github_id} 외에 **step1 을 파서 작업한다.
  3. pair1부터 readme.md를 수정 -> pair2는 대기(파일 수정해도 됨)

    • 파일수정

    • add + commit

    • (clone해왔지만, br바꿨기 때문에) push with origin과의 upstream 최초 설정

        git push --set-upstream origin is2js<github_id>
      

      image-20220217115906928

  4. pair1은 [fork repo]의 main외 작업br{github_id} -> [원본repo] main에 PR을 날릴 수 있다. image-20220217120608907

    • 보통 fork -> clone -> 작업br 파기 ->(origin입장에서 new br인)작업br push -> fork 작업br to 원본 main br로 PR in github
  5. 관리자의 merge in github

  6. pair2conflict를 내기 위해 관리자 최신main from pair1 or pair1 최신을 가져오지 않고

    • pair1작업끝내기 전에 같은 파일에 작업시작

    image-20220217121756406

  7. pair2의 무지성 PR -> conflict를 github가 알려준다.

    • 공통 작업자가 있다면, 같은 파일 수정 가능성이 있다면, PR전에 pairupstream의 pull부터 해야함. image-20220217121952676 image-20220217122213362
    • github에서 PR을 만드려고 하면 conflict를 알려준다. image-20220217122103056
  8. **pair2는 최신소스가 업데이트된 원본repo를 받아오기 위해 local <-> 원본repo upstream으로 등록하고, 받아와야한다. **

    • pair1을 pair로 등록하고 받아와도 될 것 같은데, 중심은 원본repo에서 받아온다.

    • 중간 다리인 fork는 주고/받을 때 별 영향이 없다. local과 원본repo가 연결되어야 최신소스를 받으니, upstream라는 별칭으로 원격저장소를 추가하여 연결한다.

      image-20220217122745898

        git remote -v
        # fork -> clone으로 형성된 origin = fork레포만 연결되어있다.
              
        git remote add upstream<원본레포 별칭> <원본레포 URL>
              
        git remote -v
              
        git fetch upstream
        # fetch는 커밋내역만 가져오는데 [원격저장소별칭]만으로 가져올 수 있다.
        # 가져올 br이 있는지 확인한다.
        git branch -a
              
        git merge upstream/main 
        # 가져올 [원격저장소별칭/br]  형태로 merge를 요청한다.
      
  9. 가져와서 conflict를 (vscode 등에서) 해결하고, 다시 fork(origin)으로 push -> github에서 PR을 날리면 된다.

     git push origin is2js{github_id}
    

    image-20220217123533765

  10. 우테코의 코드리뷰는 더 복잡하다.

    • 원본repo의 관리자 -> 리뷰어들이 merge를 담당한다

    • fork전, 우테코 학습사이트를 통해 원본repo에 main외 내 {github_id}로

      하면서 PR의 최종merge가 각자의 {github_id}로 되도록 먼저 생성한다.

    • fork하면, main + 모든 리뷰이들의 {github_id}들이 있다. -> 내 {gihub_id}의 br만 로컬로 clone해와야한다.

         git clone -b is2js<내github_id> --single-branch https://github.com/is2js/java-
         racingcar.git<url>
      
    • clone후, 내입장에서의 main branch인 {github_id}에서 작업용=리뷰어brstep1부터 파서 시작한다.

    • 만약, 페어가 있다면 한 곳의 step1을 선택한 다음, 작업이 끝나면 찢어진 뒤

      • pair라는 별칭으로 git remote add pair <URL>을 하고
      • fetch -> merge하여 작업된 pair의 코드를 가져온 뒤, 작업을 시작한다.

    image-20220216010500314