커밋 메시지를 작성해야하는 이유는 무엇입니까?

커밋 메시지를 작성해야하는 이유는 무엇입니까? 나는 싫어하고 매번 바보 같은 생각합니다.

명명되지 않은 GUI 프론트 엔드를 사용하면 강제로 수행하게됩니다. 커맨드 라인에서 VCS를 사용하더라도 매번 다른 사람들이하는 것을 들었습니다.

하루에 여러 번 커밋하고 기능을 완료하지 않은 경우 무엇에 대해 쓰고 있습니까? 나는 많은 커밋 후에 메시지를 작성하고 미니 태그가 필요하거나 실제 태그를 수행 할 때라고 생각합니다.

내가 맞습니까, 아니면 뭔가 빠졌습니까? 또한 분산 시스템을 사용하고 있습니다

"유용하고 잘 작성해야 할 메시지가 있고 기능이 100 % 완료되고 단위 테스트가있을 때만 커밋하십시오"라고 말하는 모든 사람들에게, 나는 여전히 SVN 사고 방식에 있다고 말합니다. .

git을 사용하는 경우 이것이 스마트 워크 플로라고합니다.

1. 원하는만큼 커밋하십시오 . 거기에 오래된 빠른 메시지를 쓰십시오. 어쨌든 아무도 그것을 볼 수 없습니다.
2. 10 개의 커밋이 끝나면 작업중인 기능을 완료 한 것입니다. 이제 테스트를 작성하고 테스트를 커밋하십시오. 또는 당신이 원하는 다른 무엇이든. 당신이 TDD를 좋아한다면, 먼저 테스트를 작성하십시오.
3. git rebase -i첫 번째 '지저분한'커밋에서 최근 기록을 스쿼시, 편집, 생략 및 정리하여 멋진 메시지가있는 논리적이고 깨끗한 커밋으로 정리 하여 로컬 기록을 추가하고 수정했습니다 .
4. 청소 후 누군가에게 물러나도록 요청하십시오.
5. 헹구고 반복하십시오.

3 단계는 당신이 겪은 멋진 커밋으로 끝나고 SVN을 사용하면 처음 두 단계를 완료 할 때까지 커밋하지 말아야한다는 것을 알 수 있습니다. IOW, 테스트되지 않은 반으로 작성된 코드를 다른 사람에게 적용하고 싶지 않으므로 기능이 완료 될 때까지 일주일 동안 커밋하지 마십시오. 버전 제어 기능을 최대한 활용하고 있지 않습니다.

또한 1 단계와 3 단계 사이에서 git push노트북 HDD가 죽으면 서버의 개인 저장소 미러를 변경하여 무료 백업을받을 수 있습니다.

일부 불쌍한 관리자가 버그를 사냥 할 때 버그에 추가 된 것을 발견하기 때문입니다. xyz, 그는 어떤 개정을 알고 싶어합니다. xyz는하기로되어있었습니다.

당신은 당신의 소스 코드를 코멘트?

당신은 최고의 주석, 말 것과 쓰는 이유 코드로 만 말을 어떻게 ?

커밋 메시지는 이와 같은 주석이므로 매우 중요하며,이를 제대로 받아들이는 것에 대한 생각이 많을수록 향후 소프트웨어 관리자에게 더 유용합니다.

모든 활성 소프트웨어에 대해이 특정 의견은 다음과 같이 표시됩니다.

( http://longair.net/blog/2009/04/25/a-few-git-tips/에 있음 ). 이것은 새 눈의 볼 수 있는 소프트웨어에 근무하고있다 할 때 , 그리고 어떻게 그들이 한을.

참고 이 "말 즉 이러한 목록에 표시하는 코멘트를 저지하기위한 궁극적 인 목표이며, 무엇 당신의 미래의 자신이나 동료, 그리고 그하려면"당신은 좋은 서면으로 알아서 메시지를 저지해야하는 이유입니다.

커밋 메시지가 어리석은 것처럼 보이면 커밋을 잘못 사용하는 것처럼 들립니다.

커밋은 정당한 이유가 있어야합니다. 작업중인 기능에 대해 분류 한 작업과 관련이 있어야합니다. 이러한 작업이 공식적인 것이 든 마음 속에 있든 관계없이 커밋 할 때마다 어느 정도 작업을 완료해야하며 어떤 방식 으로든 기능해야합니다.

그러면 커밋 메시지가 훨씬 더 나은 목적을 제공합니다. 완료 한 작업과 다른 곳에서 추적되지 않은 경우 해당 작업이 필요한 이유 또는 어떤 용도로 사용되는지 설명하십시오.

• 더 나은 캡슐화를 위해 사용자 클래스를 리팩토링했습니다.
• 컨트롤러 클래스에서 인터페이스를 사용할 수 있도록 API 스텁 생성
• 테스트 케이스에서 모의 ​​데이터베이스를 사용할 수 있도록 데이터베이스 클래스를 추상 클래스로 변환

그런 다음 귀하 또는 다른 개발자는 저장소 또는 파일 히스토리를 탐색하고 특정 진화가 발생한 위치와 이유를 상당히 쉽게 확인할 수 있습니다. 또는 특정 개정판에 버그가있는 것으로 판명 된 경우, 커밋 메시지는 해당 라인이 삽입 된 이유에 대한 단서를 제공하므로 해당 내용을 제거하지 않고 생각했던 내용을 다시 만들 수 있습니다. 대신 올바른 방법으로 수정할 수 있습니다.

커밋 의견은 모든 것을 해결하지 못합니다. 특히 개발자가 입력해야하는 것에 대해 화가 났을 때 도움이되는만큼 오해 할 가능성이 항상 있습니다. 이것을 시도하십시오 : 숲의 빵 부스러기 흔적이나 등산 웨이 포인트 또는 추적 총알처럼 생각하십시오. 올바르게 수행하면 혼란스러운 경로를 개설 할 수 있습니다.

그들에게서 큰 거래를하지 마십시오. 솔직하게 :

• "기능 X를 처리하기 위해 편집 된 공간 색인 엔티티, Daos 및 UI"
• "기능 요청 # 1234 및 버그 # 5678에 대한 증분 체크인"
• "마지막 빌드를 깨뜨 렸습니다.이 파일들은 내가 놓친 파일입니다."

짧고 "큰 그림"으로 유지하십시오. 가능하면 기능 / 버그 시스템의 문제 번호를 참조하십시오. 일부 버전 제어 UI에는 이러한 종류의 필드가 포함되어 있습니다.

그것은 WTF / 분의 수를 줄입니다.)

더 행복한 팀 (당신을 미워하지 않는 팀)으로 전환하고 잠재적으로 더 낮은 비용으로 더 나은 팀 출력

따라서 나머지 팀은 프로젝트 트리 변경을 확인하는 WTF를 알고 있습니다.

적절한 커밋 메시지 입력을 연습하지 않으면 다음과 같은 메시지를 입력하는 내 동료처럼 끝날 것입니다.

no changes

또는

testing

백 개가 넘는 변경된 파일로 커밋하십시오 (여기서는 농담이 아닙니다 !!).

그러한 개발자가되면 메시지를 입력하는 것이 아무리 어리석은 지에 상관없이 다른 세계 사람들의 눈에는 어리석게 보일 것입니다.

변경 사항이 의미가 없다면 왜 커밋합니까?

의미가있는 변경 사항을 커밋하십시오. 예를 들어, 나는 다른 주에 다소 큰 리팩토링을했는데 약 3 일이 걸렸습니다. 그 시간 동안 나는 많은 커밋이 필요할 것입니다. 일부는 약간의 변화 ( '새로운 책임을 반영하기 위해 클래스 X에서 Y로 이름 바꾸기'또는 '클래스 Q로 이동 된 메소드 Z ()')였으며 다른 것들은 실제로 큰 규모였습니다. 기능 / 리팩토링을 마쳤을 때 커밋이 찌그러 질 수 있는지 확인합니다 (적어도 git 지원, 다른 도구에 대해 알지 못함). 보통 나중에 도움이되기 때문에 그대로 둡니다.

줄을 편집하는 동안 커밋하지 않을 것이므로 의미가 있어야합니다. 마지막 커밋 이후에 한 일만 설명하십시오.

팀이 몇 차례 커밋 한 후 변경하여 시스템을 중단 할 때의 상황을 상상해보십시오. 변경된 내용은 기억 나지 않지만 기능 X를 향상 시키거나 모듈 Y에서 파일을 제거 할 때 문제가 발생할 수 있음을 기억합니다.

그러나 불행히도 개정 번호는 X 또는 Y를 변경했을 때 알려주지 않으므로 마지막 N 일 동안 커밋 된 모든 코드를 읽거나 작성한 커밋 메시지를 읽습니다 (code보다 훨씬 읽기 쉽습니다).

따라서 커밋 메시지에 동일하고 지루하고 쓸모없는 관련없는 텍스트를 작성하면 커밋 메시지보다 더 해 롭습니다. 버그의 근본을 찾는 대신 잘못된 메시지가 잘못 안내되기 때문입니다.

따라서 커밋 할 때마다 의미있는 커밋 메시지를 작성하여 유지 관리자에게도 도움이 될 수 있습니다.

다른 사람과 함께 일하는 경우 다른 사람이 실제로 한 일을 확인하기 위해 커밋 메시지가 매우 중요합니다. 각각의 차이점을 찾는 것이 훨씬 더 많은 일이며 다른 사람이 그 일을 한 이유를 얻지 못할 수 있습니다. 예를 들어 이전 버전 이후의 동작이 예기치 않은 방식으로 어떻게 변경되었는지 추적하기 위해 다른 사람 (아마도 당신이 아닌)과 실제로 작업해야하는 경우 ... 메시지.

혼자서 일하는 경우 ... 주로 '있는 그대로'(예를 들어 단일 간단한 웹 사이트 또는 스크립트)로 코딩 된 프로젝트에서 나는 어디에서 왔는지 거의 볼 수 있습니다. 그런 식으로 작업하면 작업을 계속할 때 날짜 / 시간 또는 가장 최근의 변경 사항에만 관심이 있습니다 (복원 할 시점이 있지만 구현 중이 아니라 개발 중에 만 중요합니다). 버전 관리는 몇 가지 장점만으로 백업을 수행하는 방법 일뿐입니다. 시스템을 완전히 사용하지는 않지만 일부 소규모 프로젝트에서는 필요하지 않을 수도 있습니다.

Version Control이 프로젝트의 변경 사항을 문서화하는 것과 다른 하나는 개발자에게 도움을주기위한 두 가지 방법으로 사용되기 전에 생각이 들었습니다. 그리고 그 두 가지는 서로 완전히 다릅니다. 커밋 메시지는 한 가지 방법으로 매우 중요하며 다른 방법으로는 거의 쓸모가 없습니다.

뭔가 빠졌습니다. 커밋을 수행 해야 할 이유 가 있어야 합니다. 그렇지 않으면 수행하지 않을 것입니다.

의견에서해야 할 일은 이유가 있더라도 이유를 말로 표현하는 것입니다. wip: adding new state objects

다른 많은 사람들과 마찬가지로, 나는 여가 시간에 약간의 코딩을하고 개정 관리 시스템을 사용하여 개발과 변경 사항을 모두 추적합니다. 내가 이용할 수있는 여가 시간의 양은 주마다 그리고 달마다 크게 다릅니다. 몇 주 또는 몇 달 동안 프로젝트를 코딩 할 시간이 없을 때가 많았으며, 일반적으로 10 분 (일반적인 날)에서 40 분 (좋은 날)까지의 시간이었습니다. 특히 좋지 않은 조건, 특히 문제 디버깅에 적합합니다.

길을 잃지 않고 쉽게 검색 할 수있는 메모를 유지하는 것이 중요했습니다. 각 세션이 끝날 때 세션 작업은 자세한 메시지와 함께 커밋됩니다. 그런 다음 커밋 기록을 살펴보고 진행 상황과 사고 과정을 추적 할 수 있습니다. 이로 인해 지난 주 또는 지난 달에 귀중한 시간을 최소한으로 잃어 버릴 수있었습니다.

내가 설명하려는 요점은 좋은 커밋 메시지는 당신과 (그리고 당신을 따르는 다른 사람들이) 무슨 일이 있었는지, 무슨 일이 있었는지, 무슨 일이 일어나고 있는지, 무엇보다 왜 그런지를 알아내는 데 도움이된다는 것입니다.

논리적으로 잠시 생각하십시오. 커밋 할 때 무언가가 완료되었음을 의미합니다. 메시지를 남기지 않으면 다른 사람들이 어떻게했는지 알 수 있습니까?

커밋에 대해 언급하지 않으면 소스의 변경 사항에 대해 의견을 말하고 싶을 수도 있습니다. 시간이 지나면 소스가 복잡해질 수 있습니다.

커밋 메시지는 체크인에 무슨 일이 일어나고 있는지 알 수 있는 빠른 방법이며 , 팀의 다른 개발자가 코드의 어떤 부분이 어떤 개정판에서 변경되었는지를 알고 싶어 할 때 도움이 될 것입니다 (이유로 인해).

관련 메모 에서 커밋 메시지에 버그 추적기 사례 번호 (사용하고 싶습니다)를 지정하여 나중에 쉽게 추적 할 수 있도록 도와줍니다.

따라서 1 년 후 해당 코드의 관리자는 그 끔찍한 코드를 찾아야 할 사람을 알 수 있습니다. :)