게시되지 않은 기록을 다시 작성하는 단점은 무엇입니까?

Question

저는 개발 과정에서 "잃어버린 역사"의 단점이 무엇인지 궁금합니다. 하나의 유명한 예는 물론 git rebase -i/git merge --squash이지만, "메인 라인에 변경 사항을 제출하기 전에 저의 커밋 내역을 정리하고 싶습니다"아래에있는 described here은 무엇입니까?

패치를 내보내고 다른 분기에 적용하면 분기의 "기록"이 손실 될 수 있지만 병합 된 후 해당 분기와 해당 커밋 기록이 유용한 이유는 무엇입니까?

그런 기술이 "더러운"것으로 간주되는 이유에 대해 누가 자세히 설명해 줄 수 있습니까? 주 분기에 변경 사항이 적용될 수있는 한 변경 사항이 원래 처음에 커밋 된 순서가 중요한 이유는 무엇입니까?

Answer 1

이 있다면 :

* (master) Merge feature-branch into master 
|\ 
| * (feature-branch) Fix a comment typo 
| * Add comments 
| * Add feature task 3 
| * Consolidate feature tasks 1 and 2 
| * Add feature task 2 
| * Forgot a semi-colon 
| * Add feature task 1 
|/ 
* Older commit on master 

대 이것을 :

* (master, feature-branch) Add feature 
* Older commit on master 

첫번째는 master에 feature-branch의 (--no-FF) 병합하고, 하단은 스쿼시이다/feature-branch의 rebase는 master에 있습니다. 첫 번째 예제는 매우 자세해서 회귀 테스트를보다 집중적으로 수행 할 수 있지만 많은 기능이 있으면 지저분 해집니다. 두 번째는 많은 기능을 가지고 있지만 분기 정의가 없으면 읽기가 더 깔끔합니다. 당신의 자신의 방법은 프로젝트의 크기, 팀의 크기 등 개인적으로

에 따라 달라집니다, 나는 엄지 손가락의 규칙을 커밋 이것에 대해 것이다 누군가 다른 치료를 사용합니다. 아무도 다운 스트림을 염려하지 않는다. 나는 코멘트에 오타를 수정했다.

* (master) Merge feature-branch into master 
|\ 
| * (feature-branch) Add feature task 3 
| * Add feature task 2 
| * Add feature task 1 
|/ 
* Older commit on master 

분기 역사의 관련 비트는 여전히 명백하고, 나머지는 숙청있다 : 나는 보통 내가 밀어 넣기 전에 (rebase -i와) 같은 무언가로 첫 번째 예를 켜십시오.

Answer 2

자신에 대한 내역이없는 경우 단점이없는 것보다. 사실 많은 개발자가 별도의 지점 (feature/1234)에 새 기능을 만든 다음 병합하는 대신 develop -branch에 rebase/squash하고 기능 분기를 삭제합니다. 그 이유는 일반적으로 기능을 구현하면 대개 나중에 모든 단일 구현 단계에 관심이 없지만 기능 전체에 관심이 있기 때문입니다. 그러나 커밋을 저장하기 때문에 공통점이없는 커밋을 피해야합니다. 커밋이 많으면 단점도 없습니다.

Answer 3

생산 품질 코드를 관리하는 것 외에도 전체 제품 글로벌 무제한 가단성 실행 취소로 git를 처리 할 수 ​​있습니다. '게시되지 않은 기록'에는 오타, 실험을 펼치지 않은 실험, 당시에 그 자리에 있었으므로 나중에 나눌 수있는 사소한 관련이없는 수정 사항 등이 포함될 수 있습니다. 나는 실행 취소에 싫은 생각을 결코 이해하지 못했습니다.

다시 작성한 내용을 다시 작성한 내용과 비교하십시오. 새 버전이 귀하의 필요를 더 잘 충족 시키면 더 좋습니다. 원본의 내용이 새로운 버전의 요구 사항을 충족시키지 못하면 단점입니다. 특히 자신의 레포에 남아있는 게시되지 않은 항목의 경우, 사용자가 원하는대로 할 수있는 항목이 있습니다.