폴더별로 아주 큰feature 분기 보기

4382 단어 GitGitHub

배경


대형 기능의 구현이 완료되었습니다. 몇 달 전에 끊어진 피처링 지점을 개발자에 넣을 때가 되었습니다.하지만 이렇게 GitHub으로 Pull Request를 보내면...변경이 너무 많아서 표시하는 데 시간이 많이 걸리고 논평하기 어려운 상태입니다.차이가 심한 경우 코드가 일부만 표시되는 경우도 있습니다(※).원래 이렇게 큰 차이는 평론의 입도로도 적합하지 않기 때문에 따로 평론을 하기로 했다.
(※ 상한선은 GitHub 공식 홈페이지 입니다.
구체적으로 말하면 이번 작업은 iOS 응용 프로그램의 자료 라이브러리로 변경 내용은 다음과 같다.
  • CocoaPods에 라이브러리 추가
  • 이미지, 사운드 등 리소스 파일 추가
  • 내장 프레임워크 생성 및 추가
  • 응용 프로그램 주체의 코드 변경
  • 예를 들어 CocoaPods에 라이브러리를 추가하면 이것들은 모두 Pods 폴더 아래에서 분리되기 때문에 모든 폴더에 Pull Request를 만들 수 있는지 고민했습니다.

    각 폴더에 대해 드래그 요청 보내기


    기능 개발 지점featureA이 충돌을 해결했다고 가정합니다.

    STEP0: featureA 레이블 추가


    작업 시작 지점에 라벨을 붙이다.(꼭 필요한 것은 아니지만 피처A에서 미세한 조정이 지속되면 이해하기 쉬워진다.)
    git checkout featureA
    git tag featureA_alpa
    

    STEP1:develop의 base 분기

    git checkout develop
    git branch base
    

    STEP2: develop의 compare 분기

    git checkout -b compare
    

    STEP3: 비교 지점에 기능 A 병합

    git merge featureA_alpa
    

    STEP4: 비승인 폴더를 베이스 브랜치에 넣기


    여기가 포인트!
    예를 들어 Sources 원하는 객체는 다음과 같습니다.
    git checkout base
    git checkout compare ":(exclude)Sources"
    git commit
    
    체크아웃할 때 여러 경로를 지정하면 지점을 전환하지 않고 지정한 파일 폴더의 내용만 가져옵니다.:(exclude)를 더하면 그 경로를 배제한다는 뜻이다.

    STEP5: 기본 브랜치를 compare 브랜치에 병합


    이것은 원본 아래의 변경 사항만 차이로 표시합니다.
    git checkout compare
    git merge base
    git tag review_start
    

    STEP6:push Pull Request!

    base 브랜치와 compare 브랜치를push하여 GitHub에 드래그 요청을 작성합니다.
    git push origin base
    git push origin compare
    
    이제 원본 코드 아래의 변경 사항만 드래그 요청에 표시됩니다!

    STEP7: 검토 및 수정


    여느 때와 마찬가지로 GitHub에서 논평의 교환과 코드 논평을 하고 지적된 수정compare 지점을 진행한다.

    팀 개발을 진행할 때 그동안 개발자와 피처A도 진행하고 있습니다!(단, 피처A에 관해서는 댓글 대상 폴더의 변경을 잠시 기다려 주십시오.)

    STEP8: 수정 섹션을 featureA로 가져오기


    수정된 커밋을 다시 featureA에 기반합니다.
    git rebase --onto featureA_alpa review_start compare
    
    compare에 브랜치를 결합합니다.필요한 경우 Pull Request를 제출하십시오.
    git checkout featureA
    git merge compare
    

    이렇게 해서 Sources 이하는 이미 댓글을 달았던 상태!
    이후 댓글이 필요한 폴더를 반복하여 모두 완성하면featureA 섹션을 featureA에 넣습니다!

    어렵기 때문에 GIF 애니메이션을 해봤어요.

    Pros & Cons


    이러한 방법으로 검토된 분기develop에는 모든 compare 내용이 포함되어 있으므로 구축 및 확인 작업을 수행할 수 있습니다.새로운 기능 규격을 잘 모르는 평론가에게는 실제 조작이 큰 장점이다.
    다른 한편, 모든 드래그 요청의 연결 부분을 토론하기 어렵기 때문에 어떻게 분할하는가가 중요하다.새로 만든 모듈 인터페이스를 보여주고 싶다면, 모듈과 사용 부분을 동시에 포함할 수도 있습니다.

    좋은 웹페이지 즐겨찾기