자식 커밋 빈도

자식 커밋 빈도

---

svn에서 git로 전환했기 때문에 다시 컴파일하고 테스트를 통과 할 때마다 더 많은 커밋을 만들기 시작했습니다. 결국 나는 기능별로 기능을 커밋합니다.

나는 또한 emacs, wordpress 등과 같은 git을 사용하여 다른 프로젝트를 추적합니다. 나는 그들이 그렇게 자주 커밋하지 않는다는 것을 알았습니다. 그래서 나는 당신이 어떻게 커밋합니까?

---

Git 프로젝트 자체 (및 Linux 프로젝트, AFAIK)에 대한 지침은 "논리적으로 분리 된 변경 집합"당 하나의 커밋입니다.

이것은 약간 모호하지만 프로젝트에서 지속적으로 작업하는 경우 며칠마다 커밋하고 싶지 않을 것이며 , 함수가 변경 될 때마다 커밋하고 싶지 않을 것입니다 -여러 함수를 편집 한 경우 여러 개의 다른 파일이있는 경우, 가능한 경우 관련된 모든 기능을 함께 커밋하고 유용한 커밋 메시지를 제공 할 수 있습니다. 각 커밋에서 수정 된 모든 코드는 관련되어야하지만 확실히 여러 파일에 걸쳐있을 수 있습니다.

염두에두고 싶은 것은 코드 리뷰입니다. 누군가가 여러분의 작업을 병합해야하는지 결정하려고한다면, 각각의 커밋이 논리적으로 포함되고 서로 분리되어 있다면 도입되는 작업을 처리하는 것이 훨씬 쉽습니다. 이를 통해 효과적으로 체리 선택 작업을 수행 할 수 있습니다. 하나의 기능이 각각 수정 된 세 개의 커밋이 있지만 모두 어떻게 든 결합되어있는 경우 코드베이스를 깨지 않고 다른 두 개없이 하나를 적용 할 수 없습니다. 하나의 커밋으로 스쿼시됩니다.

---

나는 또한 emacs, wordpress 등과 같은 git을 사용하여 다른 프로젝트를 추적합니다. 나는 그들이 그렇게 자주 커밋하지 않는다는 것을 알았습니다.

git의 좋은 점 중 하나는 원하는만큼 자주 커밋 할 수 있다는 것입니다. 그런 다음 업스트림 커밋을 수행하고 싶을 때 여러 관련 커밋을 git-rebase.

---

결국 나는 기능별로 기능을 커밋하게됩니다.

git add함수별로 " "기능을 수행하여 하나의 커밋 만 만들 수 있다는 것을 잊지 마십시오 .

• 주어진 작업에 대해 모든 함수가 작성되거나 수정되면
• 또는 현재 함수가 너무 크거나 복잡해서 조만간 커밋의 일부가 될 수 없음을 알게되면 현재 "단계에있는"( "git added") 작업에 현재 수정 사항을 포함하지 않는 커밋 할 수 있습니다. 예배 규칙서.

그런 다음 커밋 수를 분기의 목적과 관련시킬 수 있습니다.

• 로컬 브랜치 : 미쳐 가고, 언제든지 커밋
• "공개"브랜치 (푸시 할 것) :
  • 로컬 저장소의 경우 (선택된 사용자 그룹 용) : 최소한 매우 작은 "중간"커밋을 다시 그룹화 할 수 있습니다.
  • 공용 저장소의 경우 (모든 개발자 또는 다른 프로젝트를 볼 수 있음) : "활동"또는 "작업"별로 커밋을 다시 그룹화하여 더 읽기 쉽게 만들기 위해 대화 형 리베이스를 만들 수 있습니다.

간단히 말해서, " 공개 고려 사항"은 D VCS ( "분산"에서와 같이)에서 올바른 이유로 적절한 수의 커밋을 수행하도록 안내 할 수 있습니다.

---

커밋할수록 git bisect로 버그를 찾기가 더 쉽습니다.

---

테스트가 통과되거나 기능 단위가 추가 / 삭제 / 수정되는 즉시

---

정말 다릅니다.

내가하는 일은 당신이하는 것처럼 들리기 때문에 로컬에서 자주 커밋하지만, 영향력있는 몇 가지 변경 사항이 발생한 경우에만 변경 사항을 푸시합니다.

이렇게하면 작업 내용을 저장할 수 있지만 다른 사용자의 저장소를 복잡하게 만들지 않습니다.

---

우리의 비즈니스 요구 사항은 프로그램이 컴파일 될 때 불안정한 브랜치에 커밋하고 단위 테스트를 통과하고 고객이 검토 한 경우 (불안정 브랜치에있을 때) stable 브랜치에 커밋해야합니다.

---

기능을 추가하거나 변경 한 후 커밋하고 테스트를 성공적으로 마쳤습니다. 또는 데스크톱에서 노트북으로 전환 할 때 코드를 풀다운하고 싶을 때 커밋하고 푸시합니다.

---

당신이하는 일은 나에게 옳은 일로 들립니다. 무언가를 엉망으로 만들면 되돌릴 수 있는 작업 설정이있을 때마다 커밋하기에 좋은 시간입니다. 회귀 테스트를 빠르고 쉽게 실행할 수있는 좋은 설정이 있다면 상당히 자주 볼 수 있습니다. 저에게는 일주일에 한 개씩 만들어서 운이 좋을 것입니다.

---

1- 커밋은 빈번해야합니다. 코드를 원격 저장소 (로컬뿐만 아니라)에 커밋하는 작업을 자주 수행하여 코드가 손실 된 경우를 대비하여 백업해야합니다. 이는 예상했던 것보다 더 자주 발생하므로 잠재적 인 재 작업을 방지하고 원격 저장소를 항상 최신 상태로 유지하려면 하루 종일 변경 사항을 푸시해야합니다.

2- 커밋은 세분화되어야하므로 코드베이스에 너무 많은 변경 사항을 포함해서는 안됩니다. 변경 사항이 너무 많은 커밋은 되돌리기가 더 어렵고 전체 범위를 다루기 위해 커밋 메시지가 너무 길어야하므로 "기록"관점에서 참조로 사용할 수 없습니다.

3- 커밋에는 적절한 제목이 있어야합니다. 제목은 대문자로 시작해야하며 마침표로 끝나서는 안됩니다. 일반적으로 제목은 짧고 간결해야합니다.

4- 커밋 설명은 선택 사항이지만 가지고 있으면 좋습니다.

---

나는 꽤 멀리 떨어져 있습니다. git은 코드를 "백업"하기위한 것이 아닙니다. 코드를 잃어 버리지 않도록 tarball이나 dropbox 등을 사용해야합니다.

자주 커밋하지 않으면 어떤 커밋에 무엇이 들어가야하는지 정확히 알 수 있으며 50 개 커밋보다 더 부드러운 히스토리를 제공합니다.

"죄송합니다", "젠장", "그 파일을 잊어 버렸습니다"

리베이스 할 수 있지만 처음에 스테이징 / 커밋을하지 않으면 작업을 취소 할 필요가 없습니다.

참조 URL : https://stackoverflow.com/questions/1039817/git-commit-frequency