프로젝트가 소스 제어에 처음 커밋하기에 충분한 지 확신 할 수 없습니다. 나는 프로젝트가 '프레임 워크 완료'가 될 때까지 커밋을 미루는 경향이 있으며, 그 때부터는 주로 기능을 커밋합니다. (핵심 프레임 워크가 너무 클 수있는 개인 프로젝트를 수행하지 않았습니다.) 이것이 잘못 될 수 있는지 잘 모르겠지만 이것이 최선의 방법은 아니라고 생각합니다.

예를 들어 단일 코드 파일로 구성된 프로젝트가 있다고 가정 해 봅시다. 프로젝트가 매우 기본적인 기능 (1 또는 2 기능)으로 작동하려면 약 10 줄의 상용구 코드와 100 줄이 필요합니다. 먼저 체크인해야합니까 :

1. 빈 파일?
2. 상용구 코드?
3. 첫 번째 특징?
4. 다른 시점에서?

또한 특정 시점에 체크인해야하는 이유는 무엇입니까?

합리적인 "단위"를 완성하자마자 커밋해야합니다.

단위는 무엇입니까? 그것은 당신이하고있는 일에 달려 있습니다. 예를 들어 Visual Studio 프로젝트를 생성하는 경우 솔루션이없는 경우에도 생성 직후 솔루션을 커밋하십시오.

그런 다음 가능한 한 자주 커미트하고 여전히 완료된 "장치"(예 : 클래스, 구성 등) 만 커미트하십시오. 그렇게하면 어떤 일이 잘못되면 삶이 더 쉬워지고 (작은 변화를 되돌릴 수 있음) 갈등이 줄어 듭니다.

내가 아는 한, 소스 제어 저장소는 기본 프로젝트 설정의 일부이므로 빈 프로젝트를 생성 한 직후 커밋합니다.

어제

대안으로, 시간 여행을 할 수 없다면 ...
(어쩌면 자동차가 88mph에 도달하지 못하거나 플럭스 커패시터가 잠겼을 수도 있습니다)

지금

새로운 프로젝트가 피 묻은 자리에서 최선을 다하고해야한다, 그렇지 미친, 그리고 현대 DVCS 시스템은 커밋을 피하기 위해 모든 possibile 변명 제거 : git init . ; git add * ; git commit -m initial-commit이미 수 있습니다대로, 너무 늦기 전에, 지금을.

또 하나의 현명하고 논쟁의 여지가있는 질문은 " 확정 된 프로젝트 의 팀 관리 저장소에있는 커밋을 공유 소스 컨트롤에 언제 병합 해야 합니까?" (형용사, 형용사 중요합니다) 그리고 나는 대부분의 다른 답변들이 실제로 그것에 답하려고 노력하고 있다는 느낌을 받았습니다.

당신의 개인 지부는 취침 전에 적어도 하루에 한 번 , 미친 듯이 행동 해야합니다 . 그냥 아침에 일어나서 전날 밤에 무슨 일이 있었는지 전혀 알지 못할 수도 있습니다. VCS는이를 방지해야하며, 잘 컴파일되고 원활하게 실행되거나 테스트를 통과하는 최신 하위 버전으로 롤백 할 수있는 기회가 가장 좋습니다.

가능한 빨리 커밋이라고 말하고 싶습니다. 소스 제어의 주요 목적은 문제가 발생했을 때 되돌아 갈 수 있도록하는 것이며, "초기 커밋하기"연습과 공명합니다.

개인적으로, 첫 번째 커밋에는 일반적으로 Python 코드의 * .py [co] 와 같이 필요한 필터가 거의없는 .gitignore 파일 (또는 이와 동등한 파일) 만 포함 됩니다 . 기본 프로젝트 설정 및 / 또는 가장 간단한 프로토 타입은 일반적으로 다음과 같습니다.

첫 번째 커밋은 프로젝트를 한 줄로 요약하거나 프로젝트의 첫 번째 이정표에 대한 충분한 정보가있는 README 파일 일 수 있습니다. 광범위한 주제는 다음을 포함 할 수도 있습니다.

• 소개
• 프로젝트 설명
• 프로젝트 구조
• 코딩 규칙
• 방법에 대한 지침 :
  • 짓다
  • 테스트
  • 전개하다
• 알려진 문제 및 해결 방법
• 할 일 목록
• 이용 약관

프로젝트를 변경하기 전에 README를 업데이트하는 방법을 Readme 중심 개발 이라고하며 이러한 변경 작업에 시간을 투자하기 전에 변경 사항을 고려할 수 있습니다.

이 소프트웨어에 기여하거나 사용하고자하는 사람이라면 누구나 README부터 시작하십시오.

잃고 싶지 않은 작업을 수행 한 경우 소스 제어 시스템에 있어야합니다.

이것은 Git과 같은 분산 시스템에 확실히 적용됩니다. 당신이 중앙 집중식 시스템, 그리고 그것을 볼 수 있도록하는 것입니다 뭔가를 확인하는 유일한 방법은 사용하는 경우 모두 , 당신은 할 수 보류 할 - 또는 당신은 당신의 자신의 지역 Git 저장소를 설정하는 것을 고려하고, 중앙에 복종 할 수 준비가되면 시스템.

내 경험에 따르면 내 솔루션 파일 (또는 다른 빌드 스크립트 조각)에 비어있는 파일이 몇 개 포함되어 있어도 체크인하는 것이 좋습니다. 둘 이상의 사람이 프로젝트에서 작업하는 경우에 좋습니다. 이 파일은 사람들이 프로젝트에 항목을 추가 할 때 초기에 최악의 병합 문제를 일으키는 경향이 있으므로 조기에 자주 커밋해야합니다.

프로젝트에서 작업하는 유일한 사람이고 파일이 하나 뿐인 경우에도 동일한 워크 플로를 따르고 문제에 대한 생각을 쉽게 저장할 수 있습니다.

그것이 언급 되었는지 확실 하지 않습니다 .

그러나 커밋 한 것이 실행 / 컴파일 되는지 확인하십시오 ! 따라서 구문 오류 등이 없습니다.

고장난 코드를 체크 아웃하는 것보다 더 실망스러운 것은 없습니다.

새로운 테스트 사례가 녹색으로 나 오자마자 소프트웨어 테스트 (TDD 방식)와 관련된 다른 관점이 커밋됩니다. 이것은 새로운 코드 단위가 완성되었음을 의미합니다.

어리석은 일을하기 직전에

마법의 힘이없는 우리에게는 그 의미가 적습니다.

혼자서 일하는 경우 음료를 마실 때마다 또는 무엇이든 할 수 있습니다.

팀에서 일하는 경우 다른 사람이 최신 정보를 얻는 경우 오류가 발생하지 않도록 컴파일해야합니다. 하지만 그 외에는 할 수있는 한 많이 있습니다.

프로젝트에 약 2 ~ 3 시간.

농담이야. 모든 상황에 적합한 답은 하나도 없습니다. 우선, git 또는 Mercurial과 같은 분산 버전 제어 시스템을 사용하는 경우 지역 저장소에 커밋해도 치명적인 오류가 발생하더라도 데이터가 보존되지 않습니다. 그러나 개인 원격 저장소는 github와 같은 비용이들 수 있습니다. 커밋 히스토리를 유지하지만 내 경험상 프로젝트가 약간 발전하기 전까지는 필요하지 않습니다.

또한 파일을 옮기는 경우 특히 처음에 너무 많은 이탈을 원하지 않을 것입니다. 작은 경우에만 변경 사항을 커밋하는 것이 부담이됩니다. 물건을 버릴 수도 있습니다. 그러나 복제하기 쉽지 않은 변경 사항을 잃어 버리면 백업 사본을 만들지 못하고 버전 관리 시스템은 매우 유용한 백업 시스템을 만듭니다.

오늘날 일부 사람들은 코드를 저장하기 위해 DropBox 등을 사용합니다. 설정하는 데 아무런 노력이 필요하지 않으므로 프로젝트 시작시 좋은 타협이 될 수 있습니다. 그러나 특히 여러 사람이 동시에 코드를 만지는 경우 심각한 소프트웨어 개발에서 야만적 인 습관입니다.

따라서 귀중한 것, 즉 복제하기가 쉽지 않은 것이있을 때마다 버전 제어를 설정하는 경향이 있습니다. 가치는 주관적이며 자신의 능력에 달려 있기 때문에 스스로 판단해야합니다. 그 시점에서 외부 디스크 또는 공개 프로젝트 인 경우 github에 두 번째 저장소를 저장하거나 유료 계정으로 저장합니다.

많은 사람들이 이미 "Right away"에 답변했으며 100 % 동의합니다. 또한 Xion의 제안 이 VCS의 무시 패턴 (즉, .gitignore또는 이와 동등한 것)으로 시작하는 것이 좋습니다.

초기 커밋에 대한 단점이 거의 없다는 데 동의 한 것 같습니다. 거꾸로 추가하고 싶습니다 :

• 당신은 당신이 버리기로 선택한 것들을 저지를 가능성은 적지 만 여전히 남아 있습니다. 새로운 개발을 시작하면 빠르게 코딩하고 내용을 공개하고 나중에 커밋 할 때 이미 많은 파일이있을 때 실수로 커밋하여 다음 커밋에서 삭제하기 만합니다. 작거나 비어있는 커밋과 달리 이것은 역사상 진정한 소음입니다.
• 체계적인 유형이고 프로젝트에서 일반적인 첫 번째 단계가있는 경우 커밋 지점으로 사용하는 것이 자신이나 다른 사람에게 도움이 될 수 있으며 특정 지점에서 분기하여 재사용 가능한 프로젝트 스텁을 만들 수도 있습니다. 나는 Maven 프로젝트를 설정하는 몇 가지 작은 첫 단계는 이미 꽤 상당한 기반을 정의 할 수 있기 때문에이 (유용 메이븐 기반 프로젝트에 참여했고, 그 단계는 훨씬 없지만 음주 , 그들은 충분히 요구할 수있다 생각을 보증하는 재사용 성).

사용중인 VCS에 따라 다를 수 있습니다.

Git을 사용하면 빈 디렉토리 (또는 거의 빈 README 파일)를 커밋합니다. 요점은 개발 프로세스 초기 단계에있는 동안 (업스트림을 추진하기 전에) 완전히 다시 시작하려는 경우 돌아가서 분기를 빈 상태로 재설정 할 수 있다는 것입니다. 그런 다음 "생성 된"파일 (예 : Visual Studio 솔루션)을 커밋합니다. 그런 다음 실제로 코딩 할 때 평소와 같이 각 단위를 커밋하기 시작합니다.

SVN을 사용하면 각 커밋마다 업스트림을 추진하므로 Git과 마찬가지로 처음부터 다시 시작할 수 없습니다. 이 경우 프로세스 초기에 대대적 인 개선 작업을 수행 할 것이라고 생각하면 일찍 커밋하는 것이 유리하지 않을 수 있습니다. 그래도 코딩하는 사람에게 달려 있습니다.

새 프로젝트를 시작할 때 일반적으로 코드를 추가하기 전에 커밋을 시작합니다. 내가 항상 따라야 할 일반적인 규칙은 다음과 같습니다. PC가 충돌하여 모든 데이터를 지우면 메모리에서 쓸 필요가없는 코드가 무엇입니까? 10 년 전 TDD와 더 나은 프로그래밍 실습 전에 나는 내가 기억할 수있는 것에 대해 낙관적이었다. 이제는 더 신중한 경향이 있습니다. 다른 많은 포스터들이 일찍 커밋하고 자주 커밋한다고 말했습니다. 그렇게함으로써 아무것도 잃지 않습니다.

나는 대부분의 시간 동안 스스로 일하고 있으므로 느슨해지고 있다고 고백해야하지만 집에 가기 전에 일반적으로 노력합니다. 그런 식으로 내일 만들지 않으면 동료들이 내가 그만 둔 곳을 찾을 수 있습니다.

현재 직장에서 Tortoise / SVN을 사용하고 있습니다.

빈 프로젝트를 즉시 커밋 하십시오. 한 시간에 여러 번 커밋하여 프로젝트 작업에 소비합니다. 코드가 컴파일되지 않더라도 커밋하십시오. 커밋 마사지에서 이러한 커밋을 "WIP"로 표시하여 추적합니다.

또한 수동 커밋을 잊어 버린 경우를 대비하여 모든 프로젝트를 10 분마다 자동으로 백업 저장소에 커밋하는 스크립트가 있습니다. 클라우드 기반 실행 취소 버퍼라고하겠습니다.

팀에서 코드를 확인해야 할 때 프로젝트를 팀 저장소에 체크인 (일명 푸시 )하십시오. 나 같은 사람이라면 팀이 코드를 볼 준비가되기 전에 아마 것입니다.

당신이 당신의 팀에 좋은되고 싶다면, 커밋을 스쿼시 하기 전에 팀 레포로 밀어 넣으십시오.

나는 모든 기사를 살펴 보았고 이미 좋은 해결책이 많이 있다고 생각하지만 내 방법론을 당신과 공유하고 싶습니다.

프레임 워크 작성 (처음부터 바로 작성) 작업을 수행하는 동안 모듈이 완료되거나 완료 될 때까지 각 모듈에 대해 많은 변경이 이루어집니다. 그래서 항상 2 개의 위치가 있는데 하나는 DYNAMIC으로, 다른 하나는 STATIC입니다. 변경이 진행되고 프레임 워크가 아직 마무리되지 않은 경우 DYANMIC 위치에 커밋되고 완료되고 완료되면 STATIC 위치로 이동합니다. 그래서 완전한 소스 컨트롤이 있습니다.

감사

어떤 응용 프로그램을 사용하든 구성 요소를 설계하는 데 시간을 할애합니다. 네임 스페이스, 프로젝트, 외부 참조, 타사 라이브러리 등을 대략 또는 자세히 알고 있어야합니다.

팀원이라면 기본 프로젝트를 만들고 종속성을 설정하고 골격 (프로젝트가 구축 될 기반)을 확인하기 위해 리드 또는 선택한 사람을 제안하는 것이 좋습니다.

또한 프로세스가 제대로 진행되도록 체크인하기 전에 작업, 릴리스, 트렁크 등 분기가 지정되어 있는지 확인하고 싶습니다.

이미 진행중인 프로젝트에 대해 새 "작업"을 수행하고 있고 자체 작업 지점에있는 경우 야간 체크인을 수행하여 작업을 보존하십시오.

일반적으로 새로운 것을 추가 할 때마다 체크인하지만 개별 커밋으로 물건을 분리하려고합니다.

즉, 새로운 의존성을 추가하면 컴파일 될 때까지 변경하거나 처음부터 다시 할 시간을 잃을 정도로 충분히 변경됩니다. 더 큰 작업을 수행하는 경우 의미가있을 때 여러 번 커밋하려고합니다 (함수 당 한 번, 컴파일하고 성공적으로 실행할 때마다).

나는 또한 백업 포인트를 원할 때 (즉, "지금 시도하는 것이 작동하지 않거나 너무 복잡해지면 지금처럼 코드로 돌아오고 싶다") 또는 누군가 내가 원하는 것을 삭제하도록 요청할 때 커밋합니다. 긴급한 문제를 해결하고 수정).

중앙 집중식 소스 제어 시스템을 사용하는 경우 컴파일 / 작업이 아닌 커밋이 팀의 모든 사람에게 영향을 미치기 때문에 백업 포인트에 대해 임의로 커밋 할 수 없습니다.

일반적으로 상용구 코드를 추가하기 시작하면 (예 : django 웹 사이트에 새 웹앱 추가) 모든 작업을 커밋합니다.

튜토리얼을 따라 코드를 생성 / 작성하는 경우 튜토리얼에서 커밋 메시지에 단계 이름을 사용합니다. 이렇게하면 나중에 수정 사항을 확인하고 자습서 단계가 수행 한 작업을 볼 수 있습니다.

예를 들어 단일 코드 파일로 구성된 프로젝트가 있다고 가정 해 봅시다. 프로젝트가 매우 기본적인 기능 (1 또는 2 기능)으로 작동하려면 약 10 줄의 상용구 코드와 100 줄이 필요합니다.

물건을 추가하는 것이 얼마나 어려운지에 달려 있습니다.

• 보일러 플레이트 코드를 추가하는 것이 사소한 경우 추가하고 다른 코드를 시작하기 직전에 커밋합니다 (이 방법으로 실수를하거나 나중에 이상한 버그가 발생하면 간단히 상용구 코드로 되돌리고 시작할 수 있습니다 다시).

• 코드가 사소한 것이 아니라면 새로운 코드를 추가 할 때마다 (두 줄의 코드가 변경 될 때마다 백 정도 정도) 커밋합니다.