배경

git과거에 VCS (주로 )를 사용하여 많은 기존 프로젝트를 관리했으며 훌륭하게 작동했습니다. 일반적으로 기존 프로젝트를 사용하면 전반적인 기능을 최적화하거나 변경하는 코드를 변경할 때마다 변경 사항을 확인합니다 (변경하는 모든 한 줄이 아니라 적절한 단계에서 의미하는 바를 알 것입니다).

문제

내가 연습하지 않은 한 가지는 새로운 프로젝트를 만드는 것입니다. 나는 아마 매우 커질 것입니다 내 자신의 새로운 프로젝트를 시작하는 과정에있어,하지만 난이 있다는 것을 찾는거야 많이 수행하고 처음 몇 일 / 시간 / 주 변화 많은 / 기간까지가 제품이 실제로 가장 기본적인 형태로 작동 할 때까지

기존 프로젝트에서와 같이 프로세스의 각 단계에서 확인할 점이 있습니까? 아직 작동하지 않으므로 변경 사항으로 프로젝트를 중단하지 않습니다. 지금은 매일 컴퓨터를 떠날 때 VCS를 백업으로 사용했습니다.

처음 커밋은 "기본 디렉토리 구조"및 "DB 테이블 생성"과 같은 것들이었습니다. 새 프로젝트를 시작할 때 VCS를 어떻게 사용해야합니까?

간단한 시작

git init

체크인 일찍, 종종 체크인

특정 작업이나 작업 그룹과 관련된 모든 변경 사항에 대해 "체크인" 하는 프로젝트에서 일반적으로 수행 하는 작업을 수행하십시오. 이슈 트래커를 사용하는 경우 안정적인 상태 에있을 때마다 작업과 관련된 변경 사항 을 커밋합니다 (커밋 빈도에 대한 이 SO 질문 참조 ). 소프트웨어가 실행되지 않거나 사이트가 렌더링되지 않는 안정적인 상태 일 수 있습니다. Jeff Atwood 가 다음과 같이 말합니다.

코드가 소스 제어로 체크인되지 않은 경우 존재하지 않습니다. [...]

개발자가 깨진 코드를 체크인하도록 제안하지는 않지만 깨진 코드와 불완전한 코드에는 큰 차이가 있다고 주장합니다.

커밋, 완벽하게, 나중에 게시

제품이 작동 가능한 상태에 가까워지지 않으면 올바른 판단 과 상식 을 사용하여 그룹화 하여 적절하다고 생각되는 변경 사항을 계속 확인하십시오 . 모든 단일 파일의 행 변경을 하나씩 커밋 할 필요는 없지만 모든 것을 큰 청크로 커밋하면 필요한 경우 롤백하기가 더 어려워집니다.

결국, VCS가 도와 드리겠습니다 . VCS를 도와주세요 !!

그것을 너무 생각하지 마십시오

첫 커밋은 괜찮 았습니다. 너무 생각하지 마십시오. 가장 중요한 것은 체크인 된 것입니다. 기존 코드베이스가 아닌 처음부터 새로 시작한 기존의 모든 오픈 소스 프로젝트를 살펴보면 다음과 비슷한 첫 번째 개정판이 있습니다.

디렉토리 구조를 만들었습니다 (yay!)

습관을들이십시오

하루가 끝나면 커밋 로그를 기반으로 수행 한 작업에 대한 로그를 생성하십시오. 당신이에서 얻을 출력하는 경우 git shortlog와 git log하지 않는 만족스러운 봐 유용 , 아직 낮에는 프로젝트에 상당한 노력에 넣어 그때는 아마하지 않았의 변경 사항을 확인 한 바로 그것을 할 .

• git shortlog당신이 한 일에 대한 광범위한 개요 처럼 읽어야 합니다.
• git log프로젝트 의 역사 와 이야기 처럼 읽어야 합니다.

당신이하고있는 일은 올바른 접근법입니다.

첫날부터 소스 제어를 사용하고 있습니다. 이렇게하면 소스 제어에 필요한 모든 것이 갖추어져 있고 말할 수있는 지점이 없습니다.

소스 컨트롤을 사용해야하지만 처음 으로이 모든 것을 체크인하는 데 너무 오래 걸릴 것입니다.

사람들이 사용하기에 너무 어렵다고 생각하기 때문에 소스 제어에 늦게 오는 사람들에게는 이것이 가장 큰 장애물입니다. 일찍 시작하고 변경 사항을 자주 적용하면 그 장애물을 작은 단계로 줄일 수 있으며 프로젝트에 참여한 다른 사람은 곧바로 일할 수 있습니다.