소스 제어없이 여러 사람과 함께 응용 프로그램을 개발하는 가장 효과적이고 효율적인 방법은 무엇입니까?

내 상황 소개

소규모 웹 개발 회사에서 일합니다. 저를 포함하여 4 명의 ASP.NET 개발자로 구성된 팀이 있습니다. 거의 모든 프로젝트 (> 98 %)는 완료하는 데 약 1-4 주가 소요되는 1 인 프로젝트입니다. 우리는 소스 또는 버전 관리를 사용하지 않습니다. 우리가 가진 유일한 것은 모든 프로젝트의 최신 소스 (== 라이브 응용 프로그램의 소스)를 포함하는 로컬 서버의 공유 폴더입니다.

드문 경우지만 둘 이상의 사람과 동일한 프로젝트에서 작업해야하는 경우에는 ... Beyond Compare를 사용합니다. 개발자는 하루에 한두 번 컴파일하는 버전이 있는지 묻고 Beyond Compare를 사용하여 코드를 동기화합니다. 두 사람 만 프로젝트를 진행할 때는 "아주 잘"작동하지만 세 번째 개발자가 프로세스를 시작하자마자 관리 할 수없는 쓰레기가됩니다. 특히 모든 사람들이 데이터베이스를 변경하기 시작할 때.

저 (그리고 동료 개발자 중 한두 명)는 이미 Git, Mercurial 또는 TFS와 같은 소스 및 버전 제어 형식을 사용해야한다고 이미 여러 번 상사에게 말했습니다. 불행히도 상사는 소스 및 버전 제어 시스템으로 전환하는 이점을 보지 못합니다. 그의 눈에는 모든 것이 잘 작동하고 새로운 시스템을 설정하고 모든 사람을 확인하는 데 시간과 돈을 투자하고 싶지 않기 때문입니다. 사용 방법을 알고 있습니다. 그에게 장점 (간단한 협업, 다른 버전의 응용 프로그램, 코드를 변경하는 안전한 방법 등)을 설명한 후에도 그는 여전히 그것이 우리에게 필요한 것이라고 생각하지 않습니다.

4 명의 개발자 중 2 명 (나 포함)만이 소스 제어 (Git)에 대한 경험이 있습니다. 그리고 그 경험은 매우 제한적입니다. 내 컴퓨터에 Github 저장소를 복제하고 변경하고 커밋 한 다음 Github에 다시 푸시하는 방법을 알고 있습니다. 그게 다야.

내 문제에 대한 설명

몇 주 안에 우리는 표준을 위해 다소 큰 프로젝트를 시작할 것입니다. 완료하는 데 2-3 개월의 개발자가 필요할 것입니다. 저는 프로젝트 책임자 (프로젝트 관리자 및 책임 개발자)가되며 모든 것에 대한 책임을집니다. 나는 Beyond Compare 접근 방식에 문제가 있었으며,이 큰 프로젝트를 수행하고 싶지는 않습니다.

우리가 할 수 있을지 의심되기 때문에

• 자체 Git 서버를 설정하고
• Git과 함께 일하도록 모든 사람을 가르치고
• 이 큰 프로젝트에서 Git을 성공적으로 사용하고

여러 사람이 소스 또는 버전 제어를 사용하지 않고 동일한 프로젝트에서 협업 할 수있는 좋은 방법을 알고 있다면 관심이 있습니다.

최신 정보

답변과 의견을 보내 주셔서 감사합니다. 계획은 다음과 같습니다.

1. 모든 기술 담당자가 소스 제어 구현에 대해 동일한 방식으로 느끼도록 개발자와 회의를 갖습니다. 모든 사람이 배후에있을 때 우리는 더 강력한 지적을 할 것입니다.
2. 상사에게 아이디어를 제시하고 실제로 소스 제어 가 필요하다고 말하십시오 .
3. 가능한 빨리 구현하십시오.

버전 관리를 설치하고 프로젝트의 모든 사람들에게 사용하도록 가르치려면 하루가 걸립니다. 그렇게 어렵지 않습니다. 개인적으로 Git을 사용하지는 않았지만 다른 버전 제어 시스템을 설정하고 사용했으며 작동하기가 어렵지 않습니다. 개발 환경과 통합되는 것을 선택하십시오. 이렇게하면 거의 매끄럽게 사용할 수 있습니다.

이것은 시간 낭비가 아닙니다.

시간은 당신 것입니다 누군가 덮어 쓰기 또는 삭제가 일부 코드가 훨씬 더 많은 비용을 것입니다 때 잃게됩니다.

버전 관리 기능이 없다면 프로젝트를 백업하고 모든 사람이 가지고있는 버전과 서버에있는 버전 등에 대해 걱정하는 데 상당한 시간이 소요됩니다.

상사에게 확신을 줄 필요가 있다면 비 버전 제어 솔루션을 설정하고 모니터링하는 데 걸리는 시간을 추정하고 며칠 손실 된 작업을 다시 작성하는 비용을 추가하십시오. 동일한 소스 파일로 작업하는 3 명의 개발자가 편집 한 내용을 수동으로 병합하는 비용과 병합이 잘못되는 데 따른 추가 비용을 추가하는 것을 잊지 마십시오. 훌륭한 버전 관리 기능으로 무료 제공

그런 다음 버전 제어를 얻는 비용-nil (오픈 소스로 갈 경우)과 3 일-설정 비용.

프로젝트의 후반부에 오류가 발생하면 조기에 하나 이상의 비용이 발생한다는 것을 잊지 마십시오. 실수로 인해 전체 프로젝트를 다시 실행해야 할 경우 재 작성 시간보다 훨씬 많은 비용이 소요될 수 있습니다.

폴더에서 소스를 공유하면 해당 저장소도 공유 할 수 있습니다. 보스는 .git 폴더가 있다는 것을 제외하고는 그것에 대해 알지 못합니다.

Seth Godin-당신은 당신의 일을 올바르게하기 위해 허락을 요구할 필요가 없습니다.

소스 제어를 설정하고 사용법을 배우고 상사에게 알리지 마십시오. 나는 일반적으로 불순종 한 경영진을 옹호하지는 않지만이 경우에는 상사가 바보입니다. git이 배우는데 너무 오래 걸릴 것이라고 생각한다면 svn과 같은보다 단순화 된 버전 제어 시스템으로 시작하십시오 .git 이하는 멋진 일을 모두 수행하지는 않지만 기본적인 이해를 얻는 것이 더 쉽습니다.

무언가를 구현하기 전에 그 중간에 올 때까지 기다리지 말고 심각하게 곤경에 처하십시오. 그냥하고 일을 끝내십시오.

추가 편집 : 귀하의 질문에 실제로 묻는 것은 '소스 제어 시스템을 사용하지 않고 소스 제어를 어떻게합니까?'입니다. 당신은 그 필요성을 알고 있으며, 여기있는 모든 사람들이 당신에게 똑같은 것을 말하고 있다고 생각합니다. 소스 제어 시스템없이 소스 제어를 할 수있는 방법은 없습니다.

나는 당신의 요약 만 살펴볼 것이지만, 그것은 당신의 상사가 시간과 돈을 주장하고 있고, 당신은 기술적 우월성을 주장하는 것처럼 보입니다. 당신은 시간과 돈을 주장해야합니다. 일을하는 git 방법을 배우고 저장할 수있는 시간 동안 추적 한 다음 "3/28/2011과 Joe가 컴파일 가능한 빌드로 돌아 오기 위해 30 분을 기다려야했다. 마지막 커밋에 대한 git merge 명령은 약 5 초가되었을 것입니다. "

서버 교육 및 설정이 비즈니스로드 블록 인 경우 실제로 서버를 공유하는 폴더가있는 git을 사용하는 팀 구성원 한 명만 포함하여 git 워크 플로를 설정하는 방법에는 무한한 방법이 있습니다.

공유하기에 적절한 시점에 동료에게 코드를 지정된 공유 폴더에 복사하도록 지시하십시오. 각각의 저장소를 유지하고 모든 소스 제어 작업을 직접 수행 할 수 있으며 자신을 훈련시킬만큼 자신감을 가지면서 점점 더 많은 소스 제어 책임을 전달할 수 있습니다. 그것은 이상적인 방법과는 거리가 멀지 만 현재의 것과 비교하면 병합 시간을 절약 할 수 있습니다. 적은 팀 학습 곡선으로 상사를 설득하는 것이 더 쉬우 며 원하는 모든 롤백 및 버전 관리 이점을 얻을 수 있습니다.

나는 데이터베이스 작업을 많이하지 않지만 데이터베이스 스키마 변경에 대한 병합은 소스 제어로 잘 처리되지 않습니다. 이러한 병합이 어려운 경우 모든 데이터베이스 변경이 단일 게이트 키퍼를 통과하는 프로세스 변경을 고려할 수 있습니다.

이건 미친 짓이야 직접 작업하더라도 VCS를 사용해야합니다. 회사에서 VCS를 사용하지 않는 것은 금지되어야합니다. 그냥 해. 지금! 정말 ... 처음부터 고급 기능이 필요하지 않습니다. GitHub와 GitLab은 사용하기 매우 간단하지만, Windows에서 Git을 설정하고 사용하는 것이 어렵지는 않지만 상사가 주장하는 경우 더 많은 Windows 호환 호스팅 서비스를 찾을 수 있다고 확신합니다.

당신이 묻는 생각은 불가능 합니다. 여러 사람이 어떤 소스 컨트롤을 사용하지 않고 동일한 프로젝트에서 작업하는 경우, 당신은 신속하게 문제를 많이해야합니다, 당신이 리드 개발자가되기 때문에, 당신은 그들과 거래를해야합니다.

개인적인 경험을 통해 두 명의 개발자는 소스 제어없이 프로젝트를 수행 할 수 없습니다 . 셋이 아닙니다. 넷이 아닙니다. 두. 예외적 인 상황 에서 두 명의 개발자와 상황을 관리 할 수있을 것입니다 . 개발자가 매우 체계적이고 전문적인 경우, 상호 작용이 잘되고 쉽게 교환 할 수있는 경우 (매일 같은 시간에 같은 방에 위치 할 때마다) 다른 사용자가 동시에 수정 한 파일을 실수로 수정 ​​한 후이 사람이 변경 한 내용을 지우는 등의 실수를 피할 수있는 경우).

필자의 경우 두 사람이 버전 관리없이 프로젝트에 참여하게하는 것은 언제나 재난 이었다. 가장 좋은 경우, 한 사람이 변경된 파일을 두 번째 사람에게 보내고,이 두 번째 사람은 diff 도구를 사용하여 변경 사항을 수동으로 적용했습니다. 최악의 경우 한 사람이 자신이 수행 한 변경 사항을 추적 한 다음 두 번째 사람이 소스 코드를 수정할 때마다 다시 적용했습니다. 결과 : 시간, 비용 및 생산성이 크게 손실됩니다.

이제 내 관점과 내 경험에 비추어 볼 때이 문제에 대한 세 가지 해결책이 있습니다.

• 사용하기 쉬운 버전 관리를 설치하십시오 . CollabNetSubversion을 SVN 서버로 설치했지만 보안에 전혀 신경 쓰지 않으면 매우 빠르고 쉽게 설정할 수 있습니다 . Visual Studio를 사용하는 경우 개발자가 Visual Studio 내에서 소스 코드를 쉽게 업데이트 / 커밋 할 수 있도록 AnkhSvn을 설치할 수 있습니다.

• 상사 에게 Joel 테스트는 자신의 직업을 잘 아는 사람이 작성했으며 Joel 테스트에서 버전 제어 기능이 있다고 제안하면 그 뒤에 이유가 있습니다. 결국 개발자는 코드를 작성하기 위해 IDE / 구문 강조 도구가 필요하지 않다고 결정할 수도 있습니다. Windows 메모장은 괜찮습니다. 또한 왜 인터넷에 접속할 수 있습니까? Windows 3.1을 실행하는 매우 오래된 PC 만 있으면됩니다.

• 버전 관리를 제외한 모든 것이 완벽하고 전문적이라는 의심이 있기 때문에이 회사를 종료하십시오 .

큰 프로젝트에서 VCS를 사용하지 않는 것은 하나의 설정 시간을 투자하고 싶지 않기 때문에 맨발로 긴 여행을하는 것과 같습니다. 신발을 신는 시간을 투자하고 싶지 않기 때문입니다.

모든 VCS는 전혀없는 것보다 훨씬 좋습니다.

VCS를 설정하는 쉬운 방법은 TortoiseSVN 을 얻는 것입니다 (C #을 사용하는 것처럼 보이기 때문에 Windows를 사용한다고 가정합니다). 선택한 로컬 폴더에 저장소를 작성하십시오 (이로 이동하여> TortoiseSVN> 여기에 저장소 작성을 클릭하십시오). 네트워크 에서이 폴더를 공유하고 (항상 사용할 수있는 컴퓨터에 있어야 함) url로 체크 아웃하십시오 file://computername/path/to/that/repository. 다운로드가 제외되었습니다. 설정하는 데 1 분 이상 걸리지 않습니다.

귀하의 답변은 상사와의 간단한 링크입니다.이 페이지를 그 / 그녀에게 메일로 보내고 전문가에게 "quit"이라는 단어가 나타나는 횟수를 강조하십시오.

"덤"이라는 단어가 여러 번 나타날 수 있지만, 당신의 상사가 아닌 것 같습니다. 그에게 절대적인 가치는 분명하지 않습니다. 그에게 묻는 질문은 어떤 비즈니스 관련 질문이 동일한 응답을 초래할 것인지에 대한 것입니다. 아마도 "이 건물이 최대 금액에 구속되어 있다는 것을 보증하지 말고 몇 달러를 절약 할 수 있습니다!"

소스 제어는 프로젝트의 개발자 수가 0보다 큰 경우에만 필요합니다. 지속적인 통합에 대해 똑같이 말할 수 있다고 생각하기 시작했습니다 ...

(-:

ASP.NET 개발자는 Subversion, TFS 또는 Mercurial 중 하나를 사용하고 싶지만 솔직히 말해서 무언가를 다루는 한 중요하지 않습니다. 버전 관리없이 개발하는 것은 아무 의미가 없습니다. 툴을 어느 정도 자유롭게 배포 할 수 있고 툴 사용에 대한 오버 헤드가 최소화 된 경우에는 더 적습니다.

TFS는 놀라운 수준의 통합을 제공합니다. DVCS (수은 또는 자식)는 아마도 가장 유연성과 기능을 제공 할 것입니다. 이것을하지 말아야 할 이유는 없습니다.

내가 처음부터 시작했다면 머큐리얼과 거의 같을 것입니다.

버전 제어가 완료되면 빌드 서버 (TFS, TeamCity)로 진행하여 거기서부터 지속적으로 통합 할 수 있으며 그 시점에서 핸드 오버 (hand over fist)를 받기 시작합니다.

시작 지점으로 돌아가려면

프로젝트 책임자 (프로젝트 관리자 및 책임 개발자)가되며 모든 것에 대한 책임을집니다.

그래서 오른쪽, 당신은 책임 당신은 당신이 (당신이 있기 때문에), 버전 제어를 필요로 결정 당신이 (당신이 있기 때문에) 당신이 서버를 구축해야한다는 결정, 당신은 당신이 매우 첫날부터 프로젝트에서 배포 출력을 가질 필요가 있다고 결정 (항상 배포 할 수 있고 더 많은 테스트를 용이하게 할 수 있고 배포가 고도로 자동화 될 수 있기 때문에) 프로젝트의 성공을 위해 수행해야 할 단계 (책임자)

위에서 언급했듯이 이미 공유 폴더에 리포지토리를 배치 할 수 있습니다. Git, Mercurial 또는 Bazaar와 같은 분산 소스 제어 시스템을 사용하는 경우 서버를 구성하는 데 시간을 소비하지 않아도됩니다.

이미 경험이 있으신 Git 또는 Visual Studio와 잘 통합 된 Mercurial을 사용하는 것이 좋습니다.

앞으로 상사가 TFS로 전환하라고 지시하면 버전 관리가 전혀없는 것보다 낫습니다.

Powerbuilder 시절에 우리는 전체 팀이 소스 제어를 사용하지 않고 일련의 응용 프로그램을 작업했습니다. 아, Powerbuilder 는 소스 제어 기능을 가지고 있었지만 실제로 는 그것을 사용 했습니다. 파일을 체크 아웃하는 동안 PB가 충돌하고 LOT이 충돌하면 해당 바이너리 바이너리 코드 파일에 액세스 할 수 없었습니다. 일부 플래그가 파일에 설정되었으며 다른 PB 사본이로드 할 수 없었으며 체크 아웃 한 사람도로드 할 수 없었습니다.

우리가 한 일은 매우 간단했습니다. "야, 톰, xyz.pbl 작업을해볼 게. 그래서 아무 것도 바꾸지 마라" 사물의 제도에서 우리는 거의 문제가 없었습니다.

팀이 버전 제어를 채택하도록 설득 할 수 없거나 상사가 하위 패배를 감수하고 팀이 중지한다고 주장한다고 가정하면 최적의 접근 방식이 될 수 있습니다.

자신의 컴퓨터에 Git 또는 Mercurial을 설치하십시오. 자신의 작업을 버전 화하십시오. 팀이 Beyond Compare 프로세스를 통해 작업을 동기화하면 변경 내용을 새로운 커밋으로 로컬 리포지토리에 추가하십시오. 팀의 동기화에서 문제가 발생하면 항상 로컬 리포지토리에서 이전 작업 버전을 검색 할 수 있습니다.

DVCS를 사용하면 서버가 없어도되고 복잡한 설정 프로세스가 필요하지 않습니다. Mercurial을 설치하고 기본 사항을 시작하고 실행하는 데 걸리는 시간은 약 30 분입니다.

이상적인 솔루션은 아니지만 아무것도 아닌 것보다 낫습니다.

이것에 대한 나의 초기 반응은 버전 관리없이 이상적인 작업 프로세스를 이미 가지고 있다는 것입니다. 당신은 모두 병합을 관리하는 좋은 방법을 가지고있는 것 같습니다. 관리적인 관점에서 이것은 좋은 상황 인 것 같습니다. 버전 관리를 사용하는 팀을 만났지만 개발 프로세스 자체에 어려움을 겪고 있습니다.

따라서 그 버전 관리에 대한 당신의 주장에만 전적으로 상사를 설득하는 것은 "더 나은 프로세스"를 만들어내는 것은 무의미합니다. 그러나 왜 버전이나 소스 컨트롤을 사용해야하는지에 대한 또 다른 중요한 논거 가 있는데, 이는 돈으로 쉽게 계산할 수 있습니다. 그리고 그것은 :

위험

문제는 소스 제어를 사용하여 개발 프로세스를 개선하는 것이 아닙니다. 소스 컨트롤이 없으면 어떻게 될까요? 위험은 무엇입니까?

누군가 코드 또는 전체 파일에서 실수로 함수를 삭제한다고 가정합니까? 수리 비용은 얼마입니까? 바라건대 누군가가 그것을 다루었으므로 수정은 거의 없습니다.

그러나 시체가 손실 된 파일의 백업을 가지고 있지 않으면 어떻게됩니까? 얼마나 많은 인건비를 고칠 수 있을까요? 아마도 며칠이 걸릴 수 있으며 평균 인적 시간으로 쉽게 계산됩니다. 회사에 너무 많은 것입니까? 어떻게 든 더 빨리 해결할 수 있습니까?

예, 일종의 소스 제어가 있습니다. 대조적으로 : 버전 제어를 설정하고 백업하는 데 시간이 얼마나 걸립니까? git 또는 mercurial과 같은 대부분의 오픈 소스는 설정하는 데 많은 시간이 걸리지 않습니다. 사람들에게 사용 방법을 가르치는 것은 이미 Beyond Compare와 병합하는 방법을 알고 공유 폴더에 "체크인"한다는 것을 고려하면 어렵지 않습니다. 이것은 일회성 설치 비용입니다. 이 인력 시간이 위험이있는 시간보다 적습니까? 이것이 사실이라면 소스 제어를 사용하는 것이 우선 순위가되어야합니다.

소스 제어를하는 것이 유용한 비즈니스 이유를 제시 할 수 있다면 리스크 관리가 가장 큰 요인으로 작용하여 대부분의 보스를 설득 할 수 있습니다.

git과 같은 분산 버전 제어 시스템을 사용하고 공유 폴더 시스템을 사용하여 참조 저장소를 저장하십시오. 이유는 다음과 같습니다.

각 클론은 백업입니다

서버 하드 드라이브가 충돌하면 모든 사람이 새 드라이브 나 서버에 배포 할 수있는 사본을 갖게됩니다. 회사가 버전 관리에 대해 진지하지 않기 때문에 백업과 거의 동일하다고 생각합니다.

공통 참조

마스터 브랜치가있는 기본 리포지토리를 사용하면 마지막 단어가있는 버전을 알 수 있습니다. "프랑크 버전에 대해 변경 사항을 테스트했지만 존 버전도 있었습니까? 어떻게 병합 했습니까?"

보다 편안하게 전달

고객이 오늘 알파 버전을 원하십니까? 마스터가 충분히 안정적인지 테스트하고 배송 할 수 있습니다. 그렇지 않은 경우 고칠 시간이 없다면 시간을 거슬러 올라가고 더 오래되었지만 더 안정적인 버전을 얻으십시오. 최신 버전 만있는 경우에는 그렇게 할 수 없습니다.

시간을 거슬러 올라가 실수를 고치세요

수동 병합에 며칠 후에 만 ​​문제가 발생했지만 이미 공유 폴더의 내용을 덮어 쓰셨습니까? VSC가 없으면 기록이 없으므로 실수를 확인하고 수정할 수있는 지점으로 쉽게 돌아갈 수 없습니다. 코드는 그림이 아니라 영화와 같습니다. 시간이 지남에 따라 진화합니다. 영화에서 사진을 추출 할 수 있습니다. 사진에서 동영상을 추출 할 수 없습니다.

더 쉽게 버그 찾기

버그가 나타 났지만 도입 당시에는 실제로 눈치 채지 못했기 때문에 코드가 "핫"한 동안에는 수정할 수 없었습니다. 이제 어떤 변경이 도입되었는지 알지 못하므로 코드의 여러 위치에서 발생할 수 있습니다. 어디를 볼지 찾기까지 몇 시간이 걸립니다. git을 사용하면 버그가 특정 버전에서 발생하는지 테스트하고 버그 git bissect를 도입 한 정확한 커밋을 찾기 위해 테스트를 개발했을 수 있습니다 . 수천 줄의 코드를 찾는 대신 이제 10 줄이 바뀌는 것을 알았으며 테스트 스위트에서 테스트를 유지하여 버그가 다시 발생하지 않도록 할 수 있습니다.

각 개발자는 자신의 작업에 책임이 있습니다.

당신이 팀 리더이고 VCS가 없다면, 아마도 더러운 일을해야 할 것입니다. 직접 수행하면 모든 변경 사항에 대해 모든 것을 알지 못하고 오류가 발생할 수 있습니다. 반대로, 코드를 작성하는 사람들에게 항상 코드를 병합 할 때마다 수집하도록 요청하면 새 코드를 생성하는 데 사용하지 않는 시간입니다.

VCS를 사용하면 간단한 워크 플로우에서 개발자는 자신의 작업과 외부 변경 소스 인 마스터 브랜치 만 처리하면됩니다. 마스터 브랜치에는 1 명 또는 100 명이 참여할 수 있습니다. 변경 사항을 적용하려면 다른 사람이 수행 한 최신 변경 사항에 맞게 변경해야합니다. 코드를 푸는 데 시간이 더 걸리는 것처럼 보이지만 어쨌든 시간이 걸리는 병합을 수행하기 때문입니다.

차이점은 변경을 수행 한 사람이 코드를 작성했기 때문에 해당 코드를 가장 잘 아는 사람이 병합을 수행한다는 것입니다.

누가 그 코드를 작성 했습니까?

여기에 그 버그가 있지만 누가 특정 코드 줄을 작성 했습니까? 특히 프로젝트가 sevral 개월 지속되는 경우 기억하기 어렵습니다. git blame그 줄이 누구와 언제 쓰여 졌는지 알려 주었으므로 올바른 사람에게 물어볼 수 있으며 "그것을 기억하는 것은 기억 나지 않습니다".

프로젝트가 커지고있다

고객이 더 많은 기능을 원하고 너무 작은 팀이므로 다른 개발자가 필요합니다. VSC없이 증가 된 병합 복잡성을 어떻게 관리합니까?

긴급한 변화

고객이 프로덕션에 대한 중요한 버그 수정을 요청하고 요청했지만 현재 새 기능을 개발 중입니다. 그냥 git stash옆으로 변경 사항을 넣어, 또는 새로운 지점에 커밋하고 변경 사항을 밀어 당신은 당신의 보류중인 작업을 잃을 두려움없이, 긴급 수정 작업을 시작할 준비가 된 것입니다.

10 분 전에 일했습니다

로컬에서 일부 변경을 수행 중이며 10 분 전에 작동 한 작업이 중지되었습니다. VCS가 없으면 코드를 쳐다 보거나 참조 버전을 복사 한 후 변경 내용을 확인하십시오. 잠깐, 일을 시작한 이후에 참조가 바뀌 었으므로 더 이상 벗어날 수 없습니다. 그리고 변경 사항을 기반으로 한 코드의 깨끗한 사본을 유지하려고 생각하지 않았습니다.

VCS를 사용하면 바로 같은 작업을 수행 git diff하고 기반 코드의 올바른 버전과 비교하여 변경 사항을 적용 할 수 있습니다.

디버그 로그를 유지해야합니다

그래서 당신은 나쁜 사람이고 로깅을 사용하지 않습니까? printf그 불쾌한 버그를 모두 찾을 때까지 모든 코드베이스에 s 를 뿌려야 했습니까? 이제 하나를 찾아서 고쳤지만 나머지 문제를 해결하기 위해 신중하게 제작 된 디버깅 코드를 유지하려고합니다.

VCS가 없으면 파일을 복사하고 디버깅 코드를 삭제하여 (편집 오류가 발생할 수 있음)이를 푸시 한 다음 백업 된 파일을 다시 넣어야합니다. 어쨌든 디버깅 코드가 들어간 것 같습니다.

자식과 함께, 당신은 git add --patch당신이 당신의 커밋에 넣어 원하는 코드 몇 줄을 선택하고 커밋 할 수 있습니다 만 그. 그런 다음 작업을 재개하고 여전히 디버깅 코드가 있습니다. 코드를 건드릴 필요가 없으므로 복사 / 붙여 넣기 오류가 없습니다.

진흙의 큰 공

VCS가 없으면 사람들은 자신의 편에서 일하며 때로는 관련이없는 여러 가지 변경 사항을 제공합니다. 확인할 코드가 너무 많으면 버그를 찾기가 어렵습니다.

VCS를 사용하면 작은 증분 변경을 수행하고 변경 로그를 제공 할 수 있습니다. 변경 로그가 필수적이다 : 사람들이 말할합니다 왜 그들이 변화를하고있는, 아니 어떤 변화가합니다 ( 어떤 질문 alredy 코드 변화 그 자체로 대답한다). 이는 예를 들어 새로운 기능의 일부 코드를 검사 할 때 관련이없는 버그 수정과 같이 관련이없는 여러 가지 변경 사항을 읽을 필요가 없음을 의미합니다. 이를 통해 관심있는 코드에 집중할 수 있습니다.

내가 당신에게 100 개 감자를 1 개씩주고 하나가 썩 으면, 당신은 즉시 그것을 찾을 것입니다. 이제 당신 앞에 100 개의 감자를 버리고 썩은 것을 찾아달라고 요청한다면 그것은 같은 일이 아닙니다.

들여 쓰기

코딩 스타일 정책이 좋기를 바랍니다. 그렇지 않으면 들여 쓰기를 변경하면 손으로 병합하면 미치게됩니다. 물론 변경 사항에서 공백을 무시할 수 있습니다 (그러나 파이썬과 같이 들여 쓰기가 중요한 언어는 아닙니다). 그러나 읽기 어려운 코드가 생길 것입니다.

당신은 프로젝트 리더입니다

당신이 지도자라면, 일이 잘되지 않으면 책임을지게 될 것입니다. 상사가 올바른 작업에 적합한 도구를 사용하는 것이 그만한 가치가 있음을 이해하지 못해 상황에 익숙해지지 않으면 최소한 예측 가능한 실패의 리더가되는 것을 거부합니다.

보관 용 계정을 사용하면 자동 버전 기록이 있습니다. 여러 사용자간에 보관 용 폴더를 공유 할 수 있습니다.

편집하다

TortoiseSVN-client를 다운로드하고 네트워크 드라이브에서 "로컬 리포지토리"를 생성 할 수도 있습니다. 그러면 사람들은 네트워크 폴더 위치별로 소스 코드를 체크 아웃 할 수 있습니다.