답변:
나는 보통이 규칙을 따릅니다.
master지점이 있어야 작업 상태에서 프로젝트를두고;develop분기 해야 작동하는 상태에서 프로젝트를 떠나 (그리고 적어도 구축해야한다);개발하는 동안 편안하게 사용할 수 있도록 저장소의 로컬 복제본을 사용하십시오.
깨진 코드를 정기적으로 커밋하고 다른 개발자가 코드를 사용할 수있게되면 다음과 같은 훌륭한 기능을 사용합니다.
git rebase -i HEAD~4
이를 통해 중간 (이 경우 4)을 압축하여 하나의 좋은 커밋으로 커밋 할 수 있습니다. 커밋을 압축하는 방법을 선택할 수있는 편집기가 제공됩니다. 일반적으로 첫 번째 커밋을 'pick'커밋으로 표시하고 다른 커밋을 '스쿼시'로 표시했습니다.
그런 다음 하나의 원자 커밋을 푸시하거나 실제로 새로운 기능이 실제로 준비된 경우 'git cvsexportcommit'을 사용하여 기존 CVS 저장소에 작업을 가져 오는 것입니다.
rebase: 상당히 논란이있는 네가하지 거짓말을 : 자식 REBASE를, 스쿼시, 수정, 및 기타 거짓말
버전 관리의 가장 큰 장점 중 하나는 개발자가 이전 버전의 작업을 복구 할 수 있고 개발자가 서로 다르고 충돌하는 변경 사항을 동시에 시도 할 수 있다는 것입니다. 버전 관리를 통해 개발자는 실패 할 수있는 아이디어를 자유롭게 시도 할 수 있습니다.
개발자는 빌드 여부에 관계없이 정기적으로 작업을 분기하고 커밋해야합니다. 분기 또는 깨진 커밋을 허용하지 않으려면 개발자를 현혹시키고 도구를 제대로 사용하지 않는 것입니다.
즉, 특정 브랜치에 대한 커밋이 항상 빌드되도록 요구하는 것이 좋습니다. 많은 조직이 더 나아가 개발자가 특정 지점에 전념하는 것을 금지합니다. 예를 들어 개발자는 자신의 작업을 기본 개발 지점으로 다시 병합해야하지만 주요 개발자 만 이러한 변경 사항을 개발에서 프로덕션 지점으로 병합 할 수 있습니다.
우리는 일반적으로 두 가지 접근 방식을 모두 따릅니다. 내 상자의 로컬 저장소에서 원하는 모든 것을 커밋합니다. 팀의 중앙 리포지토리로 푸시 할 때가되면 먼저 대화식 리베이스를 수행하고 커밋을 논리 패키지로 만듭니다. 일반적으로 스토리 당 하나의 커밋이 있으며 댓글에 스토리 (또는 결함) ID가 포함됩니다 (우리는 칸반 기반 상점입니다).
그런 다음 중앙 재현에서 Jenkins가 듣고 빌드와 모든 테스트를 시작합니다. 문제가 발생하면 일반적으로 사람들이 다른 커밋으로 빌드를 시도하고 수정하도록 허용합니다. 잘 보이지 않으면 잘못된 커밋을 되 돌리는 것이 쉽습니다.
이후 git commit에만 저장소의 자신의 복사본에 영향을 미치는 모든 커밋 후 프로젝트가 작업 상태에 대한 필요가 없습니다. 작업을 저장하고 싶을 때마다 커밋하십시오. 어림짐작에 대한 좋은 규칙은 커밋 메시지에서 변경 한 내용을 설명 할 때 커밋이 적절하다는 것입니다.
그것은 git push다른 사용자들에게 영향을 미칩니다. 추진해야 할 사항에 대한 정책은 개발 팀이 결정해야 할 문제입니다. 작동하지 않는 코드를 메인 브랜치에 푸시하는 것은 아마도 아니오입니다. 그러나 작동하지 않는 코드를 별도의 브랜치에 푸시하는 것이 좋습니다 (아무도 그 브랜치에서 빌드를 시도하지 않는 한).
우리는 직장에서 git flow 를 사용 하고 있으며 특정 문제를 위해 만들어진 로컬 또는 원격 지점에만 도착하므로 완료되지 않거나 깨진 코드를 커밋합니다. 작업이 완료된 후에 만 개발 브랜치 (플로우 모델의 현재 작업 사본을 나타냄)로 병합됩니다. 그렇게하면 코드 공동 작업 (일부 동료는 프로젝트 리더를 포함한 다른 도시에 있음)을 통해 서로 도울 수 있습니다.
그러나 그것은 당신과 당신의 동료들이 어떻게 생각하고 있는지에 달려 있습니다. 개인적으로 브랜치 커밋은 괜찮습니다. 리 팩터가 크거나 비슷한 변경 기록이 필요할 수 있습니다.
git은 규칙을 강요하지 않기 때문에 궁극적으로 그것은 당신과 당신과 함께 일하는 사람들에게 달려 있습니다.
내 의도는 의도적으로 시스템을 심각하게 악화시키는 커밋을 피하는 것입니다. 각 커밋은 리팩토링하거나 일부 요구 사항을 구현해야합니다. 내가 잘못된 커밋을하고 그것을 밀기 전에 그것을 발견하면, 나는 그것을 히스토리에서 제거하기 위해 수정하거나 리베이스 할 것입니다.
각 커밋은 리팩토링 또는 일부 요구 사항의 구현으로 자체적으로 서 있어야하기 때문에 풀 요청에서 git 로그를 쉽게 읽을 수 있다고 생각합니다. 가까운 장래에 생생하게 될 죽은 코드를 추가하면 리팩토링으로 간주됩니다. 이것들은 나의 '논리적 덩어리'입니다.
커밋을 구성하는 방법에 여전히 유연 할 수 있습니다. 예를 들어 테스트를 미리 작성하지만 첫 번째 커밋에서 모두 건너 뛴 것으로 표시하여 테스트 스위트가 실패를보고하지 않고 구현이 완료되면 건너 뛰지 않도록 할 수 있습니다.
브랜치와 좋은 커밋 메시지를 사용한다고 가정하고, 커밋 메시지가있는 브랜치에서 "손상된"코드를 커밋한다고 가정하면 팀이 좋은 작업 관행에 동의하는 한 괜찮을 것입니다.
또한 git 저장소를 로컬로 복제하기 때문에 "깨진"코드를 커밋하는 로컬 커밋이있는 로컬 브랜치가있을 수 있습니다. 그런 다음 모든 작업이 완료되면 마스터 또는 다른 지점으로 병합하고 다양한 "손상된"커밋으로 작업 지점을 삭제할 수 있습니다.
나에게, 그것은 당신의 팀에 동의하는 것에 관한 것입니다. 일부 팀은 지점에서도 깨진 코드를 허용하지 않으며 다른 팀도 허용합니다.