30
git 모범 사례로 자주 커밋해야하지만 코드를 검토하려면 여러 커밋으로 구성된 패치를 한 번에 검토해야 할 수도 있습니다. 여러 커밋을 검토하고 병합 또는 거부 할 수있는 방법이 있습니까?Gerrit : 하나의 "변경"으로 여러 커밋 결합
A
답변
13
아니요, Gerrit는 현재 일괄 검토에서 일괄 처리 커밋을 지원하지 않습니다. 그러나 몇 가지 다른 옵션이 있습니다.
$ DAYJOB에서 우리 팀은 더 큰 변경을 위해 기능 분기를 사용합니다. 작은 커밋은 개별적으로 기능 지점으로 검토/병합되지만 기능 분기는 모든 것이 좋은 위치에 있고 모든 개발자가 만족하면 병합됩니다.
또한 Gerrit는 관련 커밋을 그룹화하는 편리한 방법 인 항목 분기를 지원합니다. 그것들은 documentation에서 간략하게 논의됩니다. 이러한 커밋은 개별적으로 검토/병합해야하지만 웹 UI에서 신속하게 그룹화 할 수 있습니다.
22
스쿼시를 임시 분기에 병합 한 다음 검토를 위해 변경 사항을 게시 할 수있는 한 가지 방법은 다음과 같습니다.
git checkout -b feature
git commit -m "start feature"
...
git commit -m "finish feature"
git checkout -b feature-review master
git merge --squash feature
git commit
이제 feature-review 분기 feature으로 만와에게 단 하나의 커밋 않았다 master에 동일한 DIFF 상대적으로 포함됩니다.
git commit --amend -C HEAD
을하고 그에 따른 검토를 위해 밀어 : 이미 게시 검토 요청을 업데이트해야하는 경우
0
당신은 커밋을 수정 활용할 수 있습니다.
필자는 공개 커밋은 원자 적이어야하며 기여하고자하는 기능을 모두 포함해야한다고 생각합니다. 일반적으로 모든 중간 커밋을 공유하고 싶지는 않습니다. 검토 전에 커밋을 쪼개는 것이 좋습니다.
+0
사상 학교는 작은 원자 커밋의 연속으로 파괴적인 변화를 만드는 것이 가장 좋으며, 각각은 찌를 수있는 힘이 있다고 말한다. 이러한 작은 커밋을 유지하면 왜 당신이 무엇을했는지, 왜 쉽게 되돌릴 수 있는지, 이분법이 더 유용하고 리뷰가 더 쉽고 빠를 수 있습니다 (예 : 데이터 파일을 정렬하고 한 줄을 추가했을 때이 둘은 두 개 작은 커밋 메시지는 어떤 일이 일어 났는지, 왜 그런지 분명하게 해줍니다. 스쿼시는 일종의 커다란 차이가 삽입을 불투명하게한다는 것을 의미합니다.)이 아이디어는 내가 일한 최고의 장소에서 인기가 있습니다. –
답장을 보내 주셔서 감사합니다. 그런데 코드를 변경 한 후 코드 검토를 수행 한 후 마스터로 밀어 넣거나 병합하려면 어떻게해야합니까? – Nonos
당신이 원하는 브랜치 ('feature' 또는'feature-review')에서 계속 작업 할 수 있습니다. 역사에 얼마나 관심을 갖고 커밋을 무너 뜨릴 지에 따라 최종 커밋을 마스터하기 위해 스쿼시 병합을하는 과정을 반복 할 수도 있습니다. –
'git merge --squash'는 히스토리를 다시 쓸 것이고, – summerbulb