너무 큰 Pull Request를 작은 덩어리로 나누세요.

8322 단어 GitGitHubpullrequest

해결해야 할 문제


시도하면서 설치하다가 갑자기 알아차렸어요...
아베의 차이는 매우 크다...

자신이 레비아라면 살의를 느낀다.
어떻게 작은 덩어리로 나눌 수 있습니까?

어떡하지?

cherry-pick 이런 거.
실험을 반복하면서commit을 하기 때문에 로그를 봐도 뭘 가져가야 할지 모르겠어요.
그때 선구자를 발견했다
https://brewing-bits.com/blog/splitting-big-merges/
참고로 git rebase -i를 사용하여 세분화한다.

대략적인 절차

  • master 에서 작업 지점 다시 분리
  • 대량의 변경 중에서 하나의 통일된 변경을 1개 지점으로 선택commit
  • 제작 PR(PullRequest)
  • 현재 브랜치 기반 새 탄젠트 브랜치
  • 동일하게 변경 사항을 줍니다.commit
  • 제작 PR(PullRequest)
  • 4-6
  • 반복

    사용 명령

    git log --oneline --reverse HEAD..huge_update_branch -- path/to/file/에서 기술한 장면은 다음과 같은 절차를 이용하여 명세표를 작성하여 개념 디자인에서 체량의 부피를 분석하도록 한다.hash commit-message복사된 편집기에서 git rebase -i HEAD 명령으로 "이 제출 사용"과 "사용 안 함"을 결정합니다.
    ...뭐, 해봐

    시도하다


    여기서 크게 변경된 지점을 rebase 으로 설정합니다.
    우선 마스터부터 점심을 썰자.huge_update_branch여기서 고른 한 세트의 변경을 진행하다.
    뭐 공부 해요?
    말단의utility류부터 시작합시다.

    시작하다

    git checkout -b huge_update_branch_part1
    ababcdcd1 utilに新しいメソッド追加したよ 
    efefghgh2 ファイル名変えたよ
    ijijklkl3 タイポ
    
    대량의 변경이 있는 지점git log --oneline --reverse HEAD..huge_update_branch -- path/to/util/과 현재의 지점huge_update_branch의 차분 로그에서 huge_update_branch_part1 이하의 파일에 변경된 제출 로그를 한눈에 볼 수 있다.path/to/file/에서 이걸 사용합니다.rebase
      1 noop
      2 
      3 # Rebase abcdefg..abcdefg onto abcdefg (1 command)
      4 #
      5 # Commands:
      6 # p, pick = use commit
      7 # r, reword = use commit, but edit the commit message
      8 # e, edit = use commit, but stop for amending
      9 # s, squash = use commit, but meld into previous commit
     10 # f, fixup = like "squash", but discard this commit's log message
     11 # x, exec = run command (the rest of the line) using shell
     12 # d, drop = remove commit
     13 #
     14 # These lines can be re-ordered; they are executed from top to bottom.
     15 #
     16 # If you remove a line here THAT COMMIT WILL BE LOST.
     17 #
     18 # However, if you remove everything, the rebase will be aborted.
     19 #
     20 # Note that empty commits are commented out
    
    물론 차이가 없기 때문에 처음에는 이런 느낌이 든다.
    방금 제출한 일지를 붙여라.
      1 ababcdcd1 utilに新しいメソッド追加したよ 
      2 efefghgh2 あ、utilの新しいメソッドにコミットし忘れ
      3 ijijklkl3 タイポ
      4 # Rebase abcdefg..abcdefg onto abcdefg (1 command)
      5 #
      6 # Commands:
    (以下略)
    
    각 커밋에 대한 확인 명령입니다.
      1 pick ababcdcd1 utilに新しいメソッド追加したよ 
      2 fixup efefghgh2 あ、utilの新しいメソッドにコミットし忘れ
      3 fixup ijijklkl3 タイポ
      4 # Rebase abcdefg..abcdefg onto abcdefg (1 command)
      5 #
      6 # Commands:
    (以下略)
    
    첫 번째 로그git rebase -i HEAD만 사용하고 뒤에 두 개가 첫 번째pick입니다.
    나왔습니다.

    다음


    그 다음에는 기본적으로 이것을 반복한다.
    현재 있는 브랜치fixup에서 새 브랜치를 잘라냅니다.
    (여기는 잘 모르겠어요. huge_update_branch_part1 괜찮아요.master그럼 다음으로 변경 사항만 선택합니다git checkout -b huge_update_branch_part2.model마찬가지로 Rebase 편집기에 명령을 붙여넣고 지정합니다.git log --oneline --reverse HEAD..huge_update_branch -- path/to/model/
      1 pick ababcdcd1 modelのrecord変えたよ 
      2 pick efefghgh2 リネーム
      3 fixup ijijklkl3 タイポ
      4 drop mnmnopop4 もう一つリネーム
      5 drop qrqrstst5 revert:もう一つリネーム
      6 # Rebase abcdefg..abcdefg onto abcdefg (1 command)
      7 #
      8 # Commands:
    (以下略)
    
    나중에 반복...
    사소한 PR로 나뉘어졌다-!(´▽‘)Noway
















    전체 16탄의 PR 완료
    이것도 힘들지만 곧 합병할 거예요.
    (중간에 1000줄을 넘었지만 레네임을 위주로 해서 숫자만큼 큰 충격은 없었다)

    감상

  • 변경된 방법에 따라 비교적 큰 충돌이 발생할 수 있다.
  • 착실하게 해결할 수밖에 없다.
  • 이것은 비교적 맵다.
  • 그래서 가장 좋은 실천은'일이 이렇게 되기 전에 방법을 생각해 보는 것이다'
  • 테스트 코드의 변경에 대해 마지막 PR에서 요약하여 수정하는 것이 매우 쉽다. 정말 좋다.
  • 마지막 선전 전까지 빌딩에 이끼가 계속 끼는 셈이다.
  • 그래서 갑작스럽게git rebase -i HEAD가 아니라 master 모든 홍보를 지점에 던졌다.
  • , 테스트를 통과한 단계develop의 PR을 모두 준비한다.
  • "결국 테스트를 통과했으면 좋겠다"어느 정도 테스트 커버가 없으면 무섭다.
  • 참고 페이지에 쓴 master 잘 사용됩니다.
  • "대원의 분지와 차이가 있는지만 확인했다면 git show-branch 괜찮겠지?"쓸데없이 생각하다.
  • 여러 학급에 대해 같은 수정을 했지만 난잡한 가운데 제출할 때도 정리한 후pushgit diff 좋아요!
  • 좋은 웹페이지 즐겨찾기