보스는 새 프로젝트에 버전 관리 시스템을 사용하는 것에 회의적입니다. 어쨌든해야합니까?

참조 /software/109817/superior-refusing-to-use-subversion를

내 질문은 비슷하지만 내 시나리오의 주요 차이점은 다음과 같습니다.

• 우리는 PHP와 웹 기술을 사용하여 처음부터 새로운 프로젝트를 시작하고 있습니다. 내 길을 가졌다면 처음부터 그것을 채택 할 것이기 때문에 개발에 다운 타임이 없을 것입니다.

• 내 개발팀은 나와 상사로 구성됩니다. 우리는 비교적 작은 회사의 "IT"부서입니다.

웹 응용 프로그램은 기존 응용 프로그램을 소스 제어없이 완전히 대체합니다. 지리적 법적 요구 사항이 다양하기 때문에 (임직 전) 각 버전에 대해 완전히 별도의 7 개의 디렉토리에 앱을 포크하기로 결정했습니다. 다른 개발자들은 그 후 다른 시간에 다른 장소에서 다른 일을했습니다. 그들 사이의 변화를 패치하는 것은 글쎄, 나는 그것이 더 잘 될 수 있다고 생각합니다. 그것이 내가 게시하는 이유라고 생각합니다.

이메일에서 직접 붙여 넣은 상사의 제안 :

• 업데이트는 SUBMISSIONS 폴더에 패키지로 제출해야합니다. 패키지에는 업데이트 관련 설명, 포함 된 모든 새 파일 목록 (설명 포함) 및 수정 세부 정보가 포함 된 모든 수정 된 파일 목록이 포함 된 'UPDATE.NFO'파일뿐만 아니라 모든 관련 파일이 포함되어야합니다.

• 업데이트 패키지는 개별 요소에 중점을 두어야하며 의도 된 목적을 벗어나지 않아야합니다. 코드는 가능하면 모듈 식으로 재사용 할 수 있도록 설계해야합니다.

• 제출 된 모든 패키지는 제출 직후 각 개발자의 테스트 환경에 설치해야합니다. 각 개발자는 새로운 추가 사항을 검토하고 프로덕션 환경으로의 설치에 대한 모든 우려 사항을 알려야합니다. 프로덕션 환경에로드하기 전에이 검토 프로세스에 대해 최소 3 일 (영업일 기준) 동안 표준 패키지 업데이트를 유지해야합니다. 우선 순위가 높은 업데이트 / 수정은이 요구 사항을 건너 뛸 수 있습니다.

소스 제어가 발명 된 이유는 자동으로 수행하는 것입니다. 대학에서 사용한 것이기 때문에 전복을 제안했습니다. 보스는 "코드를 엉망으로 만들기"때문에 서브 버전을 좋아하지 않습니다 (즉, 이진법을 사용하고 읽을 수는 없습니다). 한 번 시도했지만 Windows에서 사용하려고하면 이상한 소문자 / 대문자 오류가 발생하여 파일을 확인할 수 없었습니다. 나는 그것이 Subversion인지 또는 불쾌한 모든 소스 제어 제품인지 여부를 모르겠습니다.

그래서 상사에게 어떤 종류의 논쟁을해야합니까? 아니면 그가 맞습니까? 그리고 이상한 버그로 모든 작업을 잃을 위험이 있습니까?

아니면 내가 잘못 되었습니까? 내 상황에서 소스 제어가 정말로 필요한가? 이것이 우리가 말하는 비즈니스 크리티컬 소프트웨어이므로 의심 할 여지가 없습니다. 그러나 현재 개발자는 2 명뿐입니다.

또한, 내가 그를 설득 할 수 없다면, 나 자신만을 위해 그것을 사용할 어떤 점이 있습니까? 나는 실제로 svn을 사용하는 경험이 매우 제한된 사람으로 말하고 있습니다. 내가 정말로 아는 것은 결제와 커밋입니다. 개인 개발 노력에 도움이되는 소스 제어의 기능 (svn 이외의 다른 제품을 포함 할 수 있음)은 무엇입니까?

"다른 직업을 구하십시오"라는 의견은 없습니다. 토론에 도움이되지 않습니다.

물어 보지마 말하지 마 그를 보여줘.

svn 또는 git 또는 추가 시스템에 원하는 것을 설치하십시오. 사용하는 것뿐만 아니라 설명 할 때까지 편안하게 사용하십시오. 새로운 시스템에 익숙해 지려면 자신보다 더 편안해야합니다. 그가 합병을 조이거나 잘못된 장소에 무언가를 점검 할 때 쉽게 회복 할 수 있도록 도와 주어야합니다.

당신이 준비되면, 당신이 말하는 것을 정확하게 그에게 보여주십시오. 그에게 어떤 것도 "엉망으로 만들지 않음"을 보여주십시오. 이전 버전의 코드를 쉽게 검색 할 수있을뿐만 아니라 두 버전 사이에서 변경된 내용을 정확하게 알 수 있습니다.

서버에 심각한 문제가 발생하면 (심각한 버그, 바이러스, 해커, 디스크 충돌 등) 필요한 버전을 즉시 재구성 할 수 있다면 모두 영웅처럼 보일 것 입니다. 당신이 생산할 수 있다면 당신은 좋은 배 보일 것이라는 점 역시 지적 모든 요구에 버전. 이전 전자 메일을 검색하고 지난 1 년 동안 버전 관리로 피할 수 있었던 문제 목록을 작성하십시오.

버전 관리 시스템을 쉽게 사용할 수 있도록 치트 시트를 제공 하십시오.

마지막으로 몇 가지 옵션을 제안 하지만 결정은 그에게 맡깁니다 . 당신은 당신의 자신의 서버를 설정하거나 많은 호스팅 서비스 중 하나를 사용해야 합니까? svn, git 또는 다른 것을 사용해야합니까? 7 개의 프로젝트를 모두 시스템으로 마이그레이션해야합니까, 아니면 처음에는 한두 가지로 시도해야합니까?

소스 제어의 이점은 여러 개발자가 단일 코드에서 작업 할 수 있도록하는 것 이상입니다. SourceGear 의 창립자 인 Eric Sink 는 소스 컨트롤을 단독 개발자로 사용해야 하는 몇 가지 강력한 이유를 나열합니다 .

- It's an undo mechanism.
- It's a historical archive.
- It's a reference point for diff.
- It's a backup.
- It's a journal of my progress. 
- It's a server. 

Eric은 또한 초보자에게 좋은 소스 제어 방법을 제공합니다 . Joel Spolsky 가 제공하는 무료 온라인 Mercurial 튜토리얼 이 있으며 Mercurial은 널리 사용되는 분산 버전 제어 시스템입니다.

다음 단계로 단독 개발자로서 머신에서 로컬로 소스 컨트롤을 사용하는 것이 좋습니다. 곧 상사는 몇 분 안에 몇 초 안에 초 임계 버그가 얼마나 멀리 돌아가는지를 알려주는 등 마법을 깎을 수 있다는 것을 알게 될 것입니다. 지옥이 풀린다. 또는 CEO가 변경 한 모든 변경 사항을 취소 할 수있는 것은 매우 빠릅니다.

그리고 마지막으로 상사를 설득하기 전에 이의 제기 처리 주제를 탐구하고 싶을 수도 있습니다 . 101의 판매입니다.

실패한 경우-가능한 한 빨리 진행하여 풍차에서 시간을 낭비하지 마십시오.

예, 소스 컨트롤을 사용하는 것만으로도 가치가 있습니다. 예를 들어 Git은 독립형 개발자에게 매우 효과적이며 분기 및 병합 (가능한 최저 비용으로)과 같은 작업을 수행하고 변경 사항을 버전화할 수 있습니다.

SVN 또는 다른 버전 제어 시스템을 사용하면 실제로이 작업을 수행 할 수 있지만 병합은 약간 더 문제가됩니다.

내가 그를 설득 할 수 없다면, 나 자신만을 위해 그것을 사용할 어떤 점이 있습니까?

예. 직접 사용하는 것이 좋습니다. 변경 내역을 확인하여 다른 사항을 확인할 수 있습니다.

아닙니다. 상사가 프로젝트를 파기하여 많은 무의미한 재 작업으로 파산했기 때문에 아무런 이점이 없습니다.

git을 사용하기 전에 언급 한 것처럼, # 1은 재난이 발생할 경우 모든 VCS가 안전망이기 때문에 강력히 권장합니다. “화재의 경우 : 자식 커밋, 자식 푸시, 건물을 떠나십시오”스티커를 찾으십시오. 코드는 다른 곳에 저장 될 수 있지만, 도난 당하거나 도난 당할 수있는 랩톱에는 없습니다. 심지어 로컬 네트워크 서버조차도 코드만큼 가치있는 곳이 가장 안전한 곳은 아닙니다.

번호 2. 변경 사항, 누가, 언제, 무엇을했는지 등 ... 합병, 실행 취소. 3 번, 그리고 더 많은 경우를위한 마법의 도구를 습격하십시오. 번호 4. 지점 번호 5. 버전, 릴리스 등 태그 지정

가장 일반적인 git 워크 플로 중 하나에 대한 자세한 내용은 https://nvie.com/posts/a-successful-git-branching-model/을 참조 하십시오.

나는 git을 사용하는 것이 처음에는 위협적 일 수 있다는 것을 알고 있지만 기술에 대한 좋은 투자이며 모든 개발 팀에 필수적입니다.

텍스트 케이스 관련 문제에 대해 Tortoise 사용을 피하십시오. SVN에서 매우 일반적이기 때문에 대부분의 사람들이 git 용 GUI로 사용한다는 것을 알고 있습니다. 또는 Atlasian의 SourceTree입니다.