git deps
1.0.0
git-deps 는 GIT 저장소에서 커밋 간의 종속성에 대한 자동 분석을 수행하기위한 도구입니다. 스크린 캐스트 데모는 다음과 같습니다.
git-deps 및 관련 도구에 대해 블로그를 작성 했으며이 도구에 대해 여러 번 공개적으로 말했습니다.
단일 repo 내에서 두 개의 git 커밋이 동일한 파일을 변경하지 않거나 동일한 파일의 일부 부분을 변경하지 않으면 특정 의미에서 서로 "독립적"으로 간주 될 수 있음이 상당히 분명합니다.
대조적으로, 커밋이 라인을 변경할 때, 그것은 마지막으로 변경 한 커밋뿐만 아니라 주변 컨텍스트 라인을 제공하는 커밋에도 "의존적"에 의존합니다. 이전 버전의 라인과 컨텍스트가 없으면 커밋의 차이가 깨끗하게 적용되지 않을 수 있기 때문입니다 (코스의 적용 방법에 따라). 따라서 커밋 변경을 라인에 실행하여 커밋의 모든 종속성을 프로그래밍 방식으로 추론 할 수 있지만,이 특정 종속성 분석의 사용 사례에 대한 많은 컨텍스트 라인이 적합합니다.
따라서 종속성 계산은 "퍼즈"요소 매개 변수 (CF Patch (1))에 의해 영향을받습니다.
많은 의존성 관계와 마찬가지로, 이러한 종속성은 노드가 커밋에 해당하는 DAG (Difrated Acyclic Graph)에서 가장자리를 형성합니다. 노드는 조상의 하위 집합에만 의존 할 수 있습니다.
git-deps 에 의해 추론 된 모든 의존성 그래프가 의미 적으로 불완전 할 수 있음을 알고 있어야합니다. 예를 들어, Commit A와 Commit A의 코드 변경을 반영하기 위해 문서 또는 테스트를 변경하는 COMMIN A CONMING B를 변경하는 A 사이의 종속성을 자동 검출하지 않습니다. 따라서 git-deps 맹목적인 신앙으로 사용해서는 안됩니다. 자세한 내용은 아래의 텍스트 대 의미 론적 (In) 의존성 섹션을 참조하십시오.
때로는이 종속성 그래프의 일부의 특성을 이해하는 것이 유용합니다. 그 특성은 병합, Rebase, Cherry-Pick 등을 포함한 운영의 성공 또는 실패에 영향을 미치기 때문에 더 자세한 내용은 USE-CASES.md 파일을 참조하십시오.
INSTALL.md 파일을 참조하십시오.
USAGE.md 파일을 참조하십시오.
Astute 독자들은 git-deps 에 의해 감지 된 텍스트 독립성이 시맨틱 / 논리적 독립성과 동일하지 않다는 점에 주목할 것입니다. 텍스트 독립성은 충돌이 발생하지 않고 어떤 순서로든 변경 될 수 있음을 의미하지만 이는 논리적 독립성의 신뢰할 수있는 지표가 아닙니다.
예를 들어, 함수로의 변경 및 해당 기능에 대한 테스트 및/또는 문서에 대한 해당 변경은 일반적으로 다른 파일에 존재합니다. 따라서 이러한 변경 사항이 지점 내에서 별도의 커밋에 있으면 커밋에서 git-deps 실행하면 논리적으로 관련되어 있어도 다른 파일 (또는 동일한 파일의 다른 영역)의 변경 사항이 텍스트가 독립적이기 때문에 논리적으로 관련되어 있어도 종속성을 감지하지 못할 것입니다.
따라서이 경우 git-deps 우리가 원하는 방식으로 정확하게 행동하지 않을 것입니다. 그리고 AI가 해결되지 않은 문제 인 한, 완전히 신뢰할 수있는 행동을 개발할 가능성은 거의 없습니다. 그렇다면 git-deps 쓸모가 없다는 것을 의미합니까? 절대적으로!
첫째, 커밋 구조화를위한 모범 사례가 준수되는 경우, 논리적으로 관련된 변경 사항은 어쨌든 동일한 커밋 내에 배치되어야합니다. 따라서 위의 예에서는 함수로의 변경 및 해당 기능에 대한 테스트 및/또는 문서에 대한 해당 변경 사항이 모두 단일 커밋 내에 있어야합니다. (이것은 유일한 유효한 접근법은 아니지만,보다 진보 된 메타 역사 그룹화 메커니즘의 경우 git-dendrify 참조하십시오.)
둘째, 텍스트 독립성은 논리적 독립성을 암시하지는 않지만 대화는 더 일반적으로 예상됩니다. 논리적 독립성은 종종 텍스트 독립성을 암시합니다 (또는 다른 방법으로, 텍스트 의존성은 종종 논리적 의존성을 의미합니다). 따라서 git-deps 논리적으로 관련된 변경 사이의 종속성을 감지하지 못하는 것은 드문 일이 아니지만 논리적으로 관련이없는 변경 사항 간의 종속성을 잘못 유추하는 것은 드물어야합니다. 다시 말해, 그 잘못된 부정은 일반적으로 오 탐지보다 더 일반적 일 것으로 예상됩니다. 결과적으로 상한보다 의존성에 대한 하한을 결정하는 데 더 유용 할 수 있습니다. 이에 대한 더 많은 연구가 필요하다고 말했습니다.
셋째, 완전한 퀘스트를위한 퀘스트가 선의의 적이되도록하는 것은 종종 도움이되지 않습니다. 도구는 유용하기 위해 완벽 할 필요가 없습니다. 도구없이 동일한 작업을 수행하는 것보다 낫습니다.
이 포인트 중 일부에 대한 추가 논의는 Git 메일 링리스트의 오래된 스레드에서 찾을 수 있습니다.
그러나 궁극적으로 "증거는 푸딩에 있습니다"이므로 시도해보고보십시오!
CONTRIBUTING.md 파일을 참조하십시오.
HISTORY.md 파일을 참조하십시오.
이 소프트웨어의 개발을 부분적으로 후원 해 주신 SUSE에게 특별한 감사를드립니다. 코드, 버그 보고서 및 기타 피드백에 기여한 모든 분들께 감사드립니다.
git 의 라이센스와 일치하기 위해 GPL 버전 2에 따라 출시되었지만 설득력있는 이유가 있다면 이중 라이센스에 대한 아이디어에 열려 있습니다.
