힘내 준비 : 언제 무대에? 나중에 수정이 발생하면해야 할 일

나는 Git의 넓은 세계에 익숙하지 않다. 나는 매뉴얼을 읽었고 연습을 해왔지만 검색 한 후에는 이해할 수없는 몇 가지 측면에 대해 혼란 스럽습니다.

궁금하네요:

• 프로젝트 (첫 번째 커밋 이후)에서 소스 파일을 준비하는 적절한 시점은 언제입니까? 커밋 직전에? 추가 / 삭제 또는 수정 직후?

• 두 커밋 사이에 파일이 스테이징되고 수정되면 Git은 어떻게됩니까? 내용이 발표되었을 때와 그 이후의 내용 변경에주의해야합니까?

• 새 파일을 만들고 준비한 다음 삭제하려고하면 Git에서 "-f"플래그를 사용하도록 요청하고 간단한 "git -rm file.ext"가 작동하지 않는 이유는 무엇입니까?

나는 "무엇이 의미 하는가"와 Git에 대한 매뉴얼 및 기타 튜토리얼의 다양한 주제를 읽었지만 말했듯이 여전히 위의 문제를 이해하지 못합니다.

따라서 가능하다면 자신의 말과 예를 들어 질문에 대답하여 이해하기 쉽도록하십시오.

감사합니다.

준비 영역의 목적은 커밋을위한 유연한 공간을 확보하는 것입니다. 하위 버전과 같이 중앙 집중식 버전 제어 시스템과 git을 대조하면 이것이 더 명확해질 것이라고 생각합니다.

파괴

Subversion에서는 작업 복사본의 특정 파일을 커밋하도록 선택할 수 있습니다. 그러나 완전한 파일 만. 이제 : 당신이 단계의 파일을 원하는 경우에는 어떻게 A하지 파일 B및 파일의 일부 C파일과 관련 A아직 파일의 변경에 따라 부품 B(그 이후로 당신이 일관성을 커밋에 문제가있는 것입니다).

힘내

Git은 준비 작업을 두 번째 작업 복사본으로 제공하여이 문제를 해결합니다. 준비 영역 내에서 커밋 할 스냅 샷을 작성합니다 (대략 말하기).

따라서 준비 영역 내에서 의 변경 사항 만 포함 된 스냅 샷 A과 변경 사항 C만 반영하는 파일 버전을 만들 수 있습니다 A.

구체적인 질문

• 원하는 시점에 무대를 꾸밀 수 있습니다. 나는 개인적으로 커밋을 시작하기 직전에 무대를 선호합니다.

• 파일을 단계별로 변경 한 다음 작업 복사본에서 해당 파일을 변경하면 준비된 파일은 변경되지 않았습니다. 이들을 스테이징 할 것인지 또는 토스 변경을 스테이징 할 것인지를 결정할 수 있습니다. 즉, 실행 git gui citool하면 단계별 및 비단 계화 버전이 다양합니다 (선별 준비 및 커밋을위한 훌륭하고 간단한 도구).

• Git은 여기서주의 할 것입니다. 아마 좋은 것입니다.

일반 커밋 전략 : 세분화 된 커밋

"무엇을 준비해야합니까?"라는 질문에 대해 이야기 할 때 커밋 습관에 대해서도 이야기해야한다고 생각합니다.

중앙 집중식 VCS

중앙 서버에 커밋하는 중앙 집중식 버전 제어 시스템에서는 커밋이 완전하고 잘 테스트 된 것이 동료에게 중요했습니다. 따라서 사람들은 종종 그렇지 않은 커밋을 시도한 다음 완전한 파일 상태를 커밋하여 오류 가능성을 최소화합니다. 따라서 커밋은 많은 수정 사항을 포함하는 상당히 큰 청크 경향이 있습니다 (간단한 수정이 아닌 경우). 커밋의 변경 사항은 완전히 관련이 없습니다.

힘내

Git에서 커밋은 로컬로 수행되며 서버로 푸시하면 공개됩니다. 따라서 커밋은 의미 가 저렴 합니다. 서브 버전 의미의 커밋은 몇 개의 git commit뒤에 오는 것과 비슷하다 git push. 이 차이가 중요합니다.

Git을 사용하면 같은 파일에서 다른 행을 변경 한 경우에도 한 줄의 코드를 커밋 할 수 있습니다. 예를 들어 줄 300-350에 새 기능을 도입하면서 줄 100과 같은 보안 버그 수정을 커밋 할 수 있기 때문에 많은 이점이 있습니다.

• 다른 커밋에서 다른 변경 사항을 분리 할 수 ​​있습니다. 이것은 당신의 버전 기록에서 그것들을 멋지게 분리하고 심지어 당신이 다른 것을 되돌릴 수는 없습니다.
• 커밋이 작업 복사본의 "컴파일"상태를 반드시 반영 할 필요는 없습니다.

그렇다면 서브 버전 사용자가 기대하는 커밋에서 "품질 관리"와 빌드 보증은 어디에 있습니까? git의 다른 동작으로 이동합니다. 여전히 공용 저장소에서 프로그램의 기능 상태를 푸시하려고합니다. 따라서 변경 사항을 적용하기 전에 테스트가 성공하고 프로그램이 작동하는지 확인하십시오.

또한 분기를 최대로 활용하십시오. 많은 작은 변경 사항을 커밋하면 꽤 큰 버전 기록이 생깁니다. 지점에서 작업 하는 경우 지점 이름별로 세부 커밋을 분류 한 다음 다시 병합 할 수 있습니다 (옵션 --no-ff은 이러한 기능이 고유 지점에 존재 함을 유지함).

즉 master, 지점이 양호한 상태 인 경우에만 지점 에 병합하는 습관을 유지할 수 있습니다 . 태그를 사용하여 마일스톤 및 릴리스를 추적 할 수도 있습니다.

이제 다시 스테이징으로 돌아갑니다. 커밋 당 몇 줄을 커밋하면 커밋하기 전에 직접 스테이징됩니다. (적어도 그것이 내가하는 방법입니다).

당신이 너무 진지하게 받아들이고 있다고 생각합니다. 스테이징은 다음 커밋에 포함 할 항목을 선택하는 것입니다. 언제 또는 어떻게 스테이징을 수행하는지는 매우 중요하지 않습니다. 특정 시점에 많은 단계적 및 비 단계적 변경이있는 경우 개발 프로세스를 수정해야합니다.

프로젝트 (첫 번째 커밋 이후)에서 소스 파일을 준비하는 적절한 시점은 언제입니까? 커밋 직전에? 추가 / 삭제 또는 수정 직후?

나는 일반적으로 커밋 직전에 수행합니다 (오타가 발견되지 않는 한 마지막 순간 수정하고 준비해야합니다). 프로세스는 다음과 같습니다 : 편집, 테스트 실행, 준비, 커밋. 테스트 전에 준비를하면 테스트가 실패 할 가능성이 있으며 변경을 수행하고 준비해야하므로 커밋 시간까지 테스트를 떠나지 않겠습니까?

두 커밋 사이에 파일이 스테이징되고 수정되면 Git은 어떻게됩니까? 내용이 발표되었을 때와 그 이후의 내용 변경에주의해야합니까?

레포의 현재 상태와 (마지막 커밋 + 단계적 변경) 사이의 차이점을 보여줍니다. 새로운 변경 사항 중 일부를 준비하면 (마지막 커밋 + 단계적 변경) 상태 만 다시 계산됩니다.

새 파일을 만들고 준비한 다음 삭제하려고하면 Git에서 "-f"플래그를 사용하도록 요청하고 간단한 "git -rm file.ext"가 작동하지 않는 이유는 무엇입니까?

이제 여기에서 추측하고 있지만 아마도 단계 정보가 중요하지 않을 수도 있기 때문에 (아직 단계적으로 단계를 세우지 않을 것임) 아직 버전 제어 상태가 아닙니다 (예를 들어 제거 할 수있는 파일 git -rm). 그래서 git당신이하고있는 일을 알고 싶어합니다.