버전 제어 커밋이 너무 큰 경우는 언제입니까? [닫은]

여러 곳에서 "대량 커밋하지 마십시오"라고 들었지만 실제로 "대형"커밋이 무엇인지 이해하지 못했습니다. 관련 파일이 있어도 많은 파일을 작업 할 경우 크기가 큽니까? 한 번에 몇 개의 프로젝트 부분을 작업해야합니까?

나에게 "작은 커밋"을 만드는 데 어려움을 겪고 있습니다. 다른 것을 만드는 무언가를 만드는 것을 잊거나 만듭니다. 그런 다음 다음과 같은 것들로 끝납니다.

맞춤 발신 대기열을 만들었습니다.

봇
-단일 필드 실행기에 지나지 않는 새로운 필드 msgQueue
-sendMsg는 메시지가 전송 될 때까지 차단하고 메시지가 도착할 때까지 대기를 추가합니다.
보냄
-adminExist 호출 업데이트 (컨트롤러 참조)
sendMessage에 대한 호출 제거

제어 장치
-새 필드 msgWait는 메시지 간 대기 시간을 나타냅니다.
-서비스 플러그인 시작이 reloadPlugin으로 이동 됨
-admin 전역 관리자로 인해 서버에서 이동했습니다. 채널을 확인하고
서버 및 글로벌 수준

관리자
적절한 객체 Admin을 얻는 새로운 메소드 getServer 및 getChannel
에 속한다

봇 이벤트
-toString () 또한 extra 및 extra1을 표시합니다.

채널
-채널 필드가 이름으로 변경되었습니다
채널의 오타 수정 (int)

섬기는 사람
-관리자에게 컨트롤러로 이동

플러그인
-사소한 테스트 추가, 나중에 제거됩니다

JS 플러그인
-프레임 워크 변경 사항으로 업데이트
-InstanceTracker.getController ()를 Controller.instance로 대체했습니다.
-VLC는 이제 자신의 파일로 대화

다양한 NB 프로젝트 업데이트 및 변경

---

영향을받는 파일
/trunk/Quackbot-Core/dist/Quackbot-Core.jar 수정
/trunk/Quackbot-Core/dist/README.TXT 수정
/trunk/Quackbot-Core/nbproject/private/private.properties를 수정하십시오.
/trunk/Quackbot-Core/nbproject/private/private.xml 수정
/trunk/Quackbot-Core/src/Quackbot/Bot.java 수정
/trunk/Quackbot-Core/src/Quackbot/Controller.java를 수정하십시오.
/trunk/Quackbot-Core/src/Quackbot/PluginExecutor.java 수정
/trunk/Quackbot-Core/src/Quackbot/info/Admin.java를 수정하십시오.
/trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java 수정
/trunk/Quackbot-Core/src/Quackbot/info/Channel.java를 수정하십시오.
/trunk/Quackbot-Core/src/Quackbot/info/Server.java를 수정하십시오.
/trunk/Quackbot-GUI/dist/Quackbot-GUI.jar 수정
/trunk/Quackbot-GUI/dist/README.TXT 수정
/trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar 수정
/trunk/Quackbot-GUI/nbproject/private/private.properties를 수정하십시오.
/trunk/Quackbot-GUI/nbproject/private/private.xml 수정
/trunk/Quackbot-GUI/src/Quackbot/GUI.java 수정
/trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.java 수정
/trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.java 삭제
/trunk/Quackbot-Impl/dist/Quackbot-Impl.jar 수정
/trunk/Quackbot-Impl/dist/README.TXT 수정
/trunk/Quackbot-Impl/dist/lib/Quackbot-Core.jar 수정
/trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar 수정
/trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar 수정
/trunk/Quackbot-Impl/lib/javarebel.stats 수정
/trunk/Quackbot-Impl/lib/jrebel.info 추가
/trunk/Quackbot-Impl/nbproject/private/private.properties를 수정하십시오.
/trunk/Quackbot-Impl/nbproject/private/private.xml 수정
/trunk/Quackbot-Impl/nbproject/project.properties를 수정하십시오.
/trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js 수정
/ trunk / Quackbot-Impl / plugins / CMD / Operator / hostBan 추가
/trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.js 수정
/trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js 수정
/trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomode.js 수정
/trunk/Quackbot-Impl/plugins/listeners/onJoin.js 수정
/trunk/Quackbot-Impl/plugins/listeners/onQuit.js 수정
/trunk/Quackbot-Impl/plugins/testCase.js 수정
/trunk/Quackbot-Impl/plugins/utils/whatsPlaying.js 추가
/trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.java를 수정하십시오.
/ trunk / Quackbot-Impl / vlc_http 추가
/trunk/Quackbot-Impl/vlc_http/current.html 추가
/trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar 수정
/trunk/Quackbot-Plugins/dist/README.TXT 수정
/trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar 수정
/trunk/Quackbot-Plugins/nbproject/private/private.properties를 수정하십시오.
/trunk/Quackbot-Plugins/nbproject/private/private.xml 수정
/trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.java를 수정하십시오.
/ trunk / Quackbot-Plugins / vlc_http 추가
/trunk/global-lib/jrebel.jar 추가

네....

질문이 있으시면 :

• 커밋이 너무 커질 때 ( 비 명확한 사항 ) 몇 가지 요소는 무엇입니까 ?
• 그러한 커밋을 어떻게 방지 할 수 있습니까? 구체적인 내용을 알려주십시오
• 일이 빠르게 진행될 때 개발 초기 단계에있을 때는 어떻습니까? 거대한 커밋은 여전히 ​​괜찮습니까?

나에게 "작은 커밋"을 만드는 데 어려움을 겪고 있습니다. 다른 것을 만드는 무언가를 만드는 것을 잊거나 만듭니다.

문제입니다. 작업을 더 작고 관리하기 쉬운 덩어리로 나누는 법 을 배워야 할 것 같습니다 .

커밋이 큰 문제는 다음과 같습니다.

• 여러 사람이 참여하는 프로젝트에서 커밋이 다른 개발자의 충돌을 일으킬 가능성이 높아집니다.
• 로그 메시지에서 수행 된 작업을 정확하게 설명하기가 더 어렵습니다.
• 변경 순서를 추적하기가 어렵 기 때문에 문제의 원인을 이해하는 것이 어렵습니다.
• 커밋되지 않은 작업을 많이 잃을 가능성이 높아집니다.

때때로 큰 커밋은 피할 수 없습니다. 예를 들어 주요 API를 변경해야하는 경우 그러나 일반적으로 그렇지 않습니다. 그리고이 상황에서 자신을 발견하면 아마도 작은 커밋으로 분기를 만들고 거기에서 작업을하는 것이 좋습니다. 완료되면 다시 통합하십시오.

(또 다른 경우는 초기 가져 오기를 수행하는 경우이지만 위에 나열된 문제의 관점에서 문제가되지는 않습니다.)

단일 책임 원칙.

모든 소스 제어 커밋은 하나의 목적으로 만 사용해야합니다. 요약에 "and"또는 "also"라는 단어를 넣어야 할 경우이를 분리해야합니다.

작업 사본에서 별도의 비 관련 또는 반 관련 변경이 많이 발생하는 것이 매우 일반적입니다. 이것을 "얽힌 작업 복사 문제"라고하며, 훈련 된 개발자조차도 피하기가 매우 어렵습니다. 그러나 Git과 Mercurial은 각각 git add -p 또는 chunk selection과 TortoiseHg의 Mercurial Queues 를 해결하는 도구를 제공합니다 .

클라이언트가 특정 변경을 요청했다고 가정합니다 (예 : "어떤 날짜"일로부터 2 일 이내에 어떤 것을 수행 할 수 없다는 규칙 추가). 그런 다음 변경 한 후에는 마음이 바뀝니다. 커밋을 롤백하고 싶을 것입니다. 관련없는 보고서의 정렬 순서를 변경하는 것과 관련하여 문제가 발생하면 인생은 불행입니다.

하나의 작업 항목, 하나의 변경 세트. 클라이언트의 요청 하나, 변경 세트 하나. 당신이 마음을 바꿀 수있는 한 가지, 하나의 변경 세트. 때로는 이것이 한 줄의 코드임을 의미합니다. 때로는 데이터베이스 스키마를 포함하여 10 개의 서로 다른 파일이 있습니다. 괜찮아.

큰 커밋은 실제로 동일한 버킷에 들어 가지 않는 많은 변경 사항이있는 경우입니다. 컨트롤러 로직을 변경하면 데이터베이스 연결 모델과 기타가 있습니다. 스크립트를 사용하여 한 번의 커밋으로 묶어서는 안됩니다.

예방은 완료 한 내용에 따라 커밋을 수행합니다. 위의 예제에서 나는 컨트롤러 로직 이후, 데이터베이스 작업 후 및 스크립트 후에 커밋합니다. 때문에 단순히 짓는 연기하지 마십시오 당신이 변경된 것을 알고있다. 다른 사람들이 당신의 "변경된 것들" 커밋 로그 메시지를 되돌아보고 당신이 무엇을 흡연하고 있는지 궁금해 할 것입니다.

초기 수입품은 아마도 가장 큰 커밋 일 것입니다. 처음부터 시스템을 설정 하시겠습니까? 물론 몇 가지 큰 커밋이 있습니다. 일을 정리 한 후에는 수평을 유지 한 후에.

미리 많은 양의 코드 작업을 수행 할 것임을 알고 있다면 특정 기능에 대한 분기를 만드는 동안 정기적으로 코드를 메인 라인에서 가져와 코드가 동기화 상태를 유지하도록하는 것이 좋습니다. 지점에서 작업을 마치면 모든 변경 사항을 다시 메인 라인에 병합하십시오. 이런 식으로 다른 팀원들은 큰 커밋을 볼 때 놀라거나 짜증나 지 않을 것입니다. 또한, 물건을 깰 가능성이 훨씬 적습니다. 일을 더 작은 커밋으로 나누는 연습을 계속하십시오. 시간이 지남에 따라 그것은 두 번째 자연이 될 것입니다.

이 예는 너무 큰 커밋을 보여줍니다.

일반적으로 한 문장 또는 한 줄의 텍스트 변경을 설명하십시오. 이 규칙에 따라 커밋은 10-15 개의 작은 커밋으로 나뉩니다. 커밋을 한 줄에 적절하게 설명 할 수 없으면 이미 너무 큽니다.

더 작은 커밋을 연습하려면 이미 변경했거나 추가 한 내용을 메모장 또는 메모장에서 메모하십시오. 긴 목록이되기 전에 또는 메모장에서 이미 가지고있는 것과 관련이없는 코드 변경을하기 전에 커밋하십시오.

내 분야 (물리 모델링)에서 6 개월 전 현재 저장소에 없었던 출력의 버그를 발견했습니다. 이 일이 발생하면 개정판에서 이진 검색을 수행합니다.

1. 3 개월 전부터 모델 실행
2. 버그가 여전히 출력되면 4.5 개월 전부터 모델을 실행하십시오.
3. ... 나쁜 결과가 나오는 커밋을 찾을 때까지 반복하십시오.

버그가 괴물처럼 커밋되었을 때 문제의 원인을 찾기 위해 톱니가 달린 빗으로 앉아야합니다. 커밋이 적은 수의 파일을 만지면 문제를 일으킨 코드 줄을 추적하는 것이 덜 고통 스럽습니다.

문제를 일련의 작은 작업으로 나누는 것이 좋습니다 (이상적으로 각 작업을 버그 추적기에 넣습니다). 각 작업을 완료 할 때 커밋하고 버그 추적기에서 해당 버그 / 기능을 닫습니다.

실제로 중요한 것은 커밋의 크기가 아니며, 커밋의 구성 방식을 결정해야하는 변경 의 범위 입니다.

당신은, 예를 들어 모든 인스턴스를 변경 될 수 있습니다 __macro1에 __macro2200 개 파일을 변경하는 큰 코드베이스에. 이 경우 200 개의 약속은 제정신이되지 않습니다.

당신이 끝내고 싶은 것은 단일 개정에서 저장소를 가져올 수 있고 빌드 작업을하는 것입니다. 에서 libfoo로 변경 했습니까 libbar? 변경 사항에는 빌드 스크립트 및 Makefile 업데이트 (또는 적용 가능한 모든 항목)가 포함되기를 바랍니다.

때로는 한 가지 작업을 수행하는 일련의 실험적인 변경이 필요할 수 있습니다.이 경우 나중에 되돌려 야 할 경우 어떤 범위가 더 중요한지 결정해야합니다. 하나는 다른 것에 의존합니까? 한 번의 수정으로 한 번에 모두 커밋하십시오. 그렇지 않으면이 경우 변경 당 하나의 커밋을 제안합니다. 어쨌든 다른 지점이나 다른 리포지토리에서 이와 같은 일을해야합니다.

예, 단일 파일을 이전 수정본으로 되돌릴 수 있습니다 (따라서 큰 파일에서 하나의 파일을 백업 함). 이렇게하면 나중에 이분법과 같은 도구를 망쳐 놓고 역사를 오염시킵니다.

당신이 멈추고 "좋아요, 테스트는 통과한다고 생각합니다. 나는 이것이 효과가 있다고 생각합니다. 그러나 그것이 나빠지면, 쉽게 철회 할 수 있습니까?" .. 당신은 현명한 약속을하게 될 것입니다.

여기서 이해해야 할 것은이 문맥에서 "대형"은 커밋의 물리적 크기가 아닌 숫자가 다른 변화에 관한 것입니다 (일반적으로 두 가지가 손을 잡고 있지만).

그 때문에의 질문으로 "큰 커밋을하지 않는다"아니 이렇게 작은 커밋을 - 작은 자신을 커밋되는 이상적인 변경이 포함되어 있습니다.

변경 로그에서 별도로 (그리고 안전하게) 커밋 할 수있는 일련의 것들을 얻었으므로 너무 크다는 것이 명백합니다.

이것이 문제가 될 수있는 이유는 마지막 커밋이 현재 변경 사항에 대한 참조 지점이기 때문에 예를 들어 첫 번째 비트를 올바르게 얻은 다음 다음 비트를 잘못 얻는 경우 쉬운 방법이 아닙니다. 실수하기 시작한 지점으로 작업을 롤백합니다 (BTDTGTTS).

물론 때로는 변경 사항이 대규모 리팩토링 일뿐입니다. 다른 사람들이 제안한 것처럼 분기별로 분기해야합니다. 개별 커밋은 개념적으로 주요 개발 트렁크에서 분리 된 것을 깨뜨릴 수도 있지만 문제가 발생하면 조기에 자주 커밋해야합니다.

한 가지 더-즉각적인 관심이 필요한 작업 중에 무언가가 발생하면 별도로 (이상적으로 완전히 다른 폴더 세트에서) 변경하고 별도로 커밋해야합니다.

이 모든 것의 진정한 도전은 메커니즘의 사고 방식이 아닙니다. 커밋은 지금 만드는 백업 복사본이 아니라 각 커밋이 길을 따라 1 인치의 조약돌이며 많은 문제가 없다는 것입니다. 작은 커밋과 mob 커밋에서 서로 다른 것들을 함께 녹이는 것은 코드 덩어리에서 모호하게 관련된 기능성 비트가 함께 나쁜 것입니다.

최소한 지금까지 자신의 생각을 할 때마다 최선을 다하도록 훈련하십시오. "지금까지의 진전이 마음에 듭니다. 변경하려고하는 것이 재앙이더라도 잃고 싶지 않습니다." 그런 다음 VCS를 활용하여 시도한 막 다른 골목이나 문제를 추적하기 위해 추가 한 특수 디버깅 코드를 제거 할 수 있습니다. (예로 git reset --hard또는 rm -rf *; svn update)

단단하고 빠른 규칙이 없으며 커밋이 너무 큰 구분선이 없습니다.

이 이다 작은 커밋 더 나은 것을 지침은 이유로 내에서 (즉, 모든 라인을 짓는 것은 probaby 과도), 그러나.

이러한 종류의 지침을 명심하십시오.

• 한 번의 커밋에는 하나의 버그 수정에 대한 변경 사항 만 포함되어야합니다.
• 한 번의 커밋에 반나절 이상의 작업이 포함되어서는 안됩니다
• 단일 커밋은 빌드를 중단해서는 안됩니다

물론-이것들은 내가 명심하는 것입니다-YMMV. 개발자마다 다른 수준의 세분성을 선호합니다.

커밋이 작을수록 잠재적 인 회귀가 어디에서 오는지를 쉽게 찾을 수 있습니다.

이상적으로 커밋은 코드베이스에 대한 작은 일관성있는 변경 (버그, 기능 등 관련)이라는 의미에서 원자 적 이어야합니다 .

커밋 크기를 작게 유지하는 특정 팁은 VCS와 설정 방법에 따라 다릅니다. 로컬로 커밋하거나 서버의 자체 분기에서 작업 할 수 있어야합니다.

핵심은 원자 변경을 수행 할 때마다 "개인"브랜치를 커밋 한 다음 매주와 같이 브랜치를 정기적으로 병합 할 수 있습니다.

dvc를 사용하면 워크 플로가 다음과 같이 보일 수 있습니다.

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git push         // push your previous commits to the team server

중앙 집중식 vc 사용 :

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch

당신은 아마 더 이상 아무것도 가져갈 수 없을 때 완벽이라는 말을 들었을 것입니다. 커밋 크기에 대한 표준도 설명해야합니다.

"완벽한"크기의 프로젝트에 따라 다릅니다. 외부 고객에게 배송하는 경우 다음 번에 배송을 완료하지 않은 경우 크기가 작을수록 편안하게 배송 할 수 있습니다. 내부에 자주 배포되는 응용 프로그램을 구축하는 경우 가장 좋은 크기는 가장 작은 단위로 아무 것도 손상하지 않으며 원하는 위치에 더 가까이 갈 수 있습니다.

최신 버전 제어 시스템을 사용하면 간편한 분기, 대화식 리베이스, 준비 영역 등을 사용하여 커밋을 효과적으로 만들 수 있습니다.

커밋 메시지는 한 줄로만 이루어져야합니다 (git 최대 60 자). 커밋되는 코드의 양은 설명 메시지를 해당 제한 내에 유지할 수있을 정도로 작아야합니다.

나는 매번 커밋하는 경향이있다. (이제 우리는 이제 git으로 바꿨다.) 이런 식으로 "왜"일을했는지 ​​파악할 수 있도록 덩어리를 만들었다.

때때로 당신은 여러 다른 논리적으로 구별되는 샴페인에서 하루 종일 일하고 있었고 그 사이에 코드를 커밋하는 것을 잊어 버렸습니다. 사용 git citool당신이 작업하는 동안 당신이 하루 동안 너무 조심하지하더라도, 하루의 끝에 좋은 한입 크기의 조각으로 작업을 나누는 매우 도움이 될 수 있습니다.

git citool 특정 커밋에서 커밋 할 파일의 특정 덩어리 (또는 특정 행)를 선택할 수 있으므로 동일한 파일에 대한 변경 사항 (중첩되지 않은)을 여러 커밋으로 나눌 수 있습니다.

(Subversion을 사용하는 것 같습니다. Subversion 에이 작업을 수행하는 도구를 모르지만 git-svngit의 Subversion 어댑터 인을 사용 하면 삶을 바꿀 수 있습니다.)

커밋이 클수록 빌드를 중단하고 나머지 팀이 지불 할 가능성이 높아집니다. 나는 하루에 두 번 변경 사항을 커밋하려고합니다. 점심 직전과 집에 가기 전에. 그래서 @ 12pm and 4:30 pm 나는 모든 것이 작동하고 커밋 할 준비를하려고 노력합니다. 이 연습이 저에게 효과적이라고 생각합니다.

질문에 대답하려면 :

1) 나를 위해 표준 커밋은 하나 이상의 일을하는 경우 큰 것으로 간주됩니다. 사실 나는 버그를 수정하거나 기능을 추가하는 것을 의미합니다.

2) 당신이 무언가를 마칠 때마다 그것을 저지르는 습관과 규칙으로 그러한 커밋을 방지하십시오.

3) 개발 초기 단계에서 커밋이 나중에 사용할 파일의 첫 번째 생성을 포함하도록 허용합니다.

완료되면 식별 할 수있는 모든 버그가 수정되었으며 커밋하여 빌드를 중단하지 않는다는 것을 의미합니다.

예, 이것은 많은 커밋을 생성하지만 변경 사항 중 하나만 문제를 일으키는 동시에 커밋 된 일련의 변경 사항을 롤백하는 대신 문제가 발생한 것을 정확하게 롤백 할 수 있습니다.

또한 규칙은 Mercurial 및 Git과 같은 분산 버전 제어 시스템 (DVCS)의 경우 약간 변경된다는 점을 지적하고 싶습니다. 그중 하나를 사용하는 경우 변경을 할 때마다 아직 테스트하지 않았지만 작동 할 때 중앙 저장소로 푸시합니다. 빌드를 중단 할 염려없이 코드 변경 내용을 더 많이 수정할 수 있기 때문에이 방법이 바람직합니다.

필자의 경우 서버의 파일을 저장소 시스템 (SVN)에 커밋하려고합니다. 이것은 초기 커밋이며 실제로 큰 프로젝트 (몇 GB)이므로 다운로드하지 않고 클라이언트 서버에서 초기 커밋을하고 싶습니다.

문제는 클라이언트가 공유 서버에 있고 svn 클라이언트가 1 분 이상 실행되면 종료됩니다 (또는 다른 소프트웨어).

한 가지 대안은 내 컴퓨터에 프로젝트를 다운로드하고 거기에서 초기 커밋을 수행하는 것이지만 SVN에 큰 커밋을 더 많은 트랜잭션 방법으로 나누는 옵션이 있는지 알고 싶습니다.

저의 개발자는 버전 제어 시스템을 사용한 적이 없습니다.

내가 일하는 회사는 모든 커밋마다 피어 코드를 강제로 검토합니다. 따라서, 동료가 적절한 시간 내에 진행 상황을 파악하고 검토하는 것을 어렵게 만드는 커밋은 너무 큽니다.