최근 한 OSS에 등장한 PR 은 git merge --squash <branch> 에서 통합되어 제출된 Author가 개작되어 일부 부근에서 화제가 되었다.이 일에 합병을 한 사람은 악의가 없는 것 같지만,git의 이해 부족으로 인해 발생한 사건이라면 슬프기 때문에 잠시 적어둡니다

무슨 일

담당자가 여러 내용을 포함하는 PR

발송

관리자는 그 중의 일부분만 합병하기 위해 관리자는gitmerge--squash를 실시했고 수정 제출을 바탕으로merge←를 실시했다. 이것이 문제다

코드의 내용은 엔지니어의 것이지만 Author만 관리자가 되어 엔지니어의 동기를 손상시켰다

말하자면 스쿼시를 하면 어떨까.

이곳은 이해하기 쉽게 총결되었다.
SE 조정을 목표로 하는 블로그 그림에서git-merge의 --ff, --no-ff, --squash의 차이를 볼 수 있다

http://d.hatena.ne.jp/sinsoku/20111025/1319497900
위의 그림에서 보듯이 작업 트리와 색인에 다른 지점을 포함하는 상태 차이를 반영하는 명령입니다.
이 상태는 아직 커밋되지 않은 상태이므로 다음을 수행할 수 있습니다.

여러 제출로 인한 차이를 하나의 제출로 요약할 수 있음

아직 커밋되지 않은 상태이므로 ** 도입된 차이점 편집 가능

그러나 다음과 같은 이유로 자신 이외의 약속에 대해 squash는 바람직하지 않다고 여겨진다.

기본적으로 스쿼시를 제출한 후의 차이점은 Author가 됩니다.→ 기존 만화 삭제 contribution

Author를 말하기 전에 다른 사람이 약속한 역사를 바꾸는 것을 원하지 않는다

어떻게 하면 좋을까요?

말은 그렇고 다른 사람의 약속을 합병하고 싶지만 일부는 합병하고 싶지 않을 때 어떻게 해야 하나.
나는 각양각색의 방법을 생각해서 너에게 보여 준 네 개를 주려고 한다.

git cherry-pick<commit id> 사용하기

제출 단위로 합병하거나 합병하지 않으면cherry-pick을 사용할 수 있습니다.git cherry-pick <commit id>는 다른 지점의 특정 제출을 통합하는 기능입니다.

git cherry-pick fadb18b1771895b5fd8f11114514dd951decb67d #指定のコミットをマージ
git cherry-pick develop~3..develop #範囲指定　最新から3つ目までのコミットをマージ

이것은 당연히 이미 존재하는commit를 합병한 형식이기 때문에 author 등은 당연히 개작되지 않을 것이다.
[기술][Git]git-cherry-pick 발굴

rebase--interactive 사용하기

@wataash선생님의 의견 추가
git rebase-interactive는 squash가 제출한 첫 번째 저자라고 합니다.
어떻게든 하고 싶을 때 이게 좋아요.
상세한 상황은 @wataash선생님의 보도를 보십시오
git rebase--interactive 중 누가 author가 되는지

커미션 좀 깎아 주세요.

어쨌든 하나의 제출로 정리하고 싶다면, 또는 제출 단위로 합병 여부를 구분하려면 공급업체에 squash를 요청하는 것도 하나입니다.
모 OSS에서 판매업자@mattn 측으로부터 지시에 따라 squash를 진행하자는 제안을 받았다.

병합 후 직접 편집 및 제출

뭐, 정공법이지.commit는 하나로 통일되지 않을 수도 있고, 로그가 더러워질 수도 있지만, 이것도 역사이기 때문에 억지로 바꿀 필요가 없다고 생각하는 사람도 이곳을 선택할 수 있다.

co-author 기능 사용

그 정도는 할 필요가 있다는 의견도 있지만 화제입니다.
github는co-author기능이 있습니다. 제출 메시지에co-author의 정보를 기술하면contribution의 일람에 이 사용자를 표시할 수 있습니다.

git commit -m "Refactor usability tests.
>
>
Co-authored-by: name <[email protected]>
Co-authored-by: another-name <[email protected]>"

자세한 내용은 화살표를 누르십시오.
https://help.github.com/articles/creating-a-commit-with-multiple-authors/

폴

자꾸 귀찮아요. author 같은 건 누구나 할 수 있어요. 어쨌든 일지를 깨끗하게 하고 싶어요!이런 사람도 있지만 개인적으로 기부자에 대한 가장 큰 경의를 표하고 남의 성과를 빼앗은 사람으로 오해받고 싶지 않기 때문에 주의를 기울여도 손해를 보지 않는다고 생각합니다.

참고 자료:

git rebase--interactive 중 누가 author가 되는지
GitHub의 3가지 통합 이해
c++ 정의되지 않은 오류