저는 정부 기관에서 일하고 있습니다. 여기서 사용되는 기술과 소프트웨어 개발 방법은 매우 구식입니다.

여기에는 많은 저장 공간이 있지만 여기에서 대부분의 작업을 자동화하는 데 사용되는 응용 프로그램을 유지하고 유지할 수있는 적절한 공간이 없습니다.

기관에서는 GIT 또는 SVN과 같은 SCM 소프트웨어를 사용할 수 없습니다.

코드 품질을 유지하고 나중에 앱에 새로운 기능을 추가 할 수있는 가장 좋은 방법은 무엇입니까?

코드를 변경하지 않고 변경 한 내용을 어떻게 기억합니까?

편집 : 언급 한 것을 잊어 버렸습니다. 각 컴퓨터마다 네트워크 드라이브가 있으며이 네트워크 드라이브는 백업을 주기적으로 만들거나 저장합니다. 그러나 작업을 저장하고 기존 코드를 손상시키지 않고 새로운 기능을 추가 할 수있는 자체 계획을 만들지 않으면 SCM 솔루션보다 큰 이점이 없습니다.

편집 : 많은 사람들이 휴대용 Git을 제안했기 때문에 더 많은 정보를 추가해야합니다. Visual SVN 서버를 설치하려고했지만 설치할 관리자 권한이 없기 때문에 실패했습니다. 또한 일반 Git 셸을 다운로드하려고 시도했지만 방화벽 또는 네트워크 설정으로 Git 다운로드 페이지에 액세스 할 수 없었습니다. 휴대용 Git을 내 이메일 인 Gmail로 보내려고 시도했습니다. Google은 패키지에서 exe 파일을 감지했으며 직장 컴퓨터에서 휴대용 Git 버전을 다운로드 할 수 없었습니다. 내가 언급해야 할 또 다른 것은 기관이 USB 저장 장치 사용을 허용하지 않는 컴퓨터에 적용되는 네트워크 정책입니다. USB 포트를 사용하여 스마트 폰을 충전하거나 소형 스피커와 같은 일부 장치에 전원을 공급할 수 있습니다. 또한 일부 사람들이 언급했듯이 인터넷조차 허용되지 않는 컴퓨터가 있습니다.

다음 세 가지 간단한 도구를 사용하여 역할 소스 제어 기능을 느슨하게 복제 할 수 있습니다.

• 백업 소프트웨어 (커밋 / 체크인)
• 폴더 (지점)
• KDiff3 (분기 병합)과 같은 도구를 사용하여 두 디렉토리 사이에서 디렉토리 병합 수행

기본적으로 워크 플로는 다음과 같습니다.

1. 새 폴더 만들기 (새 분기)
2. 기존 폴더 (기존 지점)에서 새 폴더 (새 지점)로 파일 복사
3. 해당 폴더를 백업합니다 (새 지점 만들기 완료)
4. 일 좀해라
5. 새 폴더를 백업합니다 (커밋)
6. 한 폴더에서 다른 폴더로 디렉토리 병합 (병합)
7. 다른 폴더에서 다른 백업을 수행하십시오 (병합 커밋)

SVN 또는 TFS와 같은보다 모 놀리 식 소스 제어 시스템은 기본적으로이를 지원합니다.

이제 현실은 버스 회사와 같이 배터리가있는 버스를 운전할 수 없다고 말하고, 버스를 내리기 위해 운전자가 버스를 내리막 고 클러치를 밟도록 강요하는 것입니다. 현재 경영진이 버스 차고를 운영하는 것에 대해 전혀 모른다는 것을 나타냅니다. 내 애도.

그러나 적어도 버스를 시작할 수 있습니다.

컨센서스는 확실히이 회사에서 일하지 않는 것이지만, 이것이 귀하의 질문에 실제로 답한다고 믿지는 않습니다.

실제로 SCM을 대체 할 수는 없습니다 .

본격적인 시스템의 일반적인 종소리와 휘파람이 필요하지 않을 수 있습니다. 예를 들어 회사는 서버 요청을 거부하지만 로컬 SCM 사용을 허용 할 수 있습니다. 그들은 git를 싫어할 수 있지만 Subversion (또는 다른 버전 관리 시스템)을 허용합니다.

물론 동료가 무엇을 사용하고 있습니까, 아니면 이전에 일했던 직원이 있습니까? 소프트웨어 개발자가 처음 인 경우 필요한 리소스를 매우 열심히 사용해야합니다.

결국, 회사가 귀하의 역할과 경험을 존중하지 않고 필요한 도구를 허용하지 않으면 소스 제어 부족보다 더 심각한 (더 스트레스가 많은) 문제가 발생할 수 있습니다.

기본적으로 최소한의 현재 워크 플로, 방법론 및 도구를 사용할 수 없다는 명백한 관리 문제 (조직이 V- 모델 과 같은 소프트웨어 개발 프로세스 의 기본 사항을 이해 하지 못함)가 있습니다. 이것은 일반적입니다 ( 피터의 원칙 에 대해 읽어보십시오 ).

^{BTW, 2017 년 말 파리에서 최근 발생한 SNCF 철도 사건 은 비슷한 원인이 있습니다 (높은 관리 수준에서 소프트웨어 문화의 부족으로 인해 하루 이상 파리 주요 기차역이 막혔습니다. 물론 매우 유능합니다) SNCF의 IT 팀은 주요 결정에 대해서는 상담하지 않습니다). 소프트웨어 문화가 완전히 부족한 여러 유럽 산업의 이름을 지정할 수 있으며 미국에서도 비슷한 것을 찾을 수 있습니다.}

주요 문제는 코드 기반에서 혼자 일하고 있습니까, 아니면 동료들과 함께 일하고 있습니까?

혼자 작업하는 경우 컴퓨터에서 로컬로 git 을 사용 하고 .git주기적으로 (외부 저장 공간에) 코드 (및 저장소)를 백업 할 수 있습니다 . 반나절 이상의 작업을 잃어 버리지 않도록하십시오 (따라서 데이터를 정기적으로 안정적으로 백업하십시오).

^{(난 당신이 적어도 모두 알고 있다고 가정 git및 svn당신이의 기술적 우수성을 알고 git, 당신은 심지어 같은 몇 가지 도구를 설치할 수없는 경우 git작업 컴퓨터에 당신이 그 문제에 대한 당신의 상사와 심각한 대화를해야합니다 당신이 필요로하는 외부 오픈 소스 도구를 설치하는 능력 및 권한 부여 ( 알려진 취약점 없이 현명하고 신중 하게 선택, 구성 및 설치해야 할 책임 )}

여러 동료들과 함께 일하고 있다면 (수십 명도 채되지 않는 것 같습니다) 모든 사람들 이 버전 관리 시스템을 사용 하도록 설득 해야 할 것입니다. 그는 일부 컴퓨터 (아마도 오래된 데스크탑, 아마도 자신의 데스크탑조차도)가 git 서버로 사용되도록 결정할 수도 있습니다. git 저장소가 적어도 1 시간마다 백업되도록 해당 서버를 설정해야합니다. 한 시간 이상의 팀 작업을 잃을 여유가 없으며 상사와 이야기 할 필요가 없습니다.

^{BTW, 나는 리눅스를 좋아하고 git서버 역할을하는 머신에 리눅스를 설치하는 것을 추천 한다. 그런 다음 git정기적 인 백업 (일부 crontab작업 포함) 설치 및 구성 은 매우 쉽습니다. 통지 git서버를 사용하여 Windows 클라이언트와 리눅스를 실행할 수 있습니다. 가능하다면 개발 머신을 리눅스로 바꾸는 것이 좋습니다. "저렴한"이며 훨씬 개발자 친화적입니다.}

그러나 SCM을 사용해야합니다. 상사에게 다른 질문을 할 수도 있습니다. 팀이 기존 SCM을 사용해야합니까, 아니면 바퀴를 재발견하고 자신의 SCM을 만들어야합니까? 보스는 일반적으로 바퀴를 재발 명하려는 생각에 위배됩니다. 휠을 재발 명할 수있는 경우, 상사에게 최소 1 년 동안 상근직이라고 말하고 (아마도 상사가 울고 분명한 방법을 받아 들일 것) 자신의 SCM을 만드는 것이 즐겁습니다. 그런 경우가 아니라면 기존 SCM 시스템 을 연구하고 SCM 시스템을 다른 소프트웨어 팀에서 사용하고 개선 할 수있는 무료 소프트웨어 도구로 만드십시오.

당신은해야 할 수도 있습니다 준비 (몇 일 동안) 정확한 및 특정 SCM의 필요성에 대한 논쟁을 먼저 동료를 위해, 다음 즉시 상사 :. 구체적인 솔루션을 제안하십시오 (일부 데스크탑에서 일부 git 서버를 실행하거나 "구식"서버를 실행하고 작업을 통해 매시간 백업하는 것과 같이 ).crontab

소프트웨어를 설치하지 마십시오 (외부에서, 심지어 오픈 소스) 허가없이 작업 컴퓨터에 허가없이 소프트웨어가 법적으로 범죄 설치, 특히 국가 민감한 IT 작업을 위해, 대부분의 국가에서 (, 당신은 잃을 수도 당신의 직장을 구하거나 감옥에 가면 .... 그렇게하도록 허가를 받으십시오; 아마도 서면으로 허락을 구하거나 적어도 이메일로 엉덩이를 가리십시오).

^{(사건별로 사례를 요청하거나 업무용 컴퓨터에 법률 소프트웨어 (주로 오픈 소스 또는 무료 소프트웨어) 를 설치할 수 있도록 조직의 신뢰를 얻어야 합니다).}

추신. (무료 소프트웨어 소스 코드에서) 기술적으로 빌드, 구성, 설치 및 사용하는 방법git (또는 관리자 권한이없는 컴퓨터)에서 대부분의 다른 무료 소프트웨어 VCS 는 다른 질문 입니다. 그리고 git충분한 리소스 (시간, 디스크 공간, 일부 C 컴파일러 등)가 있다면 관리자 권한없이 설치하고 사용할 수 있습니다.

Visual SVN 서버를 설치하려고했지만 설치할 관리자 권한이 없기 때문에 실패했습니다.

이것은 당신의 일부 특정 구성 및 편집에 의해 풀 수 있습니다 git또는 svn로부터 무료 소프트웨어 소스의 코드 git또는 Subversion을 -not 단지 바이너리 패키지 - (또한 소스 코드 의 의존성 ); 기술적 인 방법은 다른 질문입니다 (그러나 그러한 기술적 질문은 다른 곳 에서 가야합니다 ). 물론 소스 코드를 컴파일 git하기 전에 사장에게 권한을 요청해야 합니다. 그는 소스 코드를 외부에서 업무용 컴퓨터로 전송하는 것과 관련된 실제적인 세부 사항 (그러한 해결책을 받아 들인 경우)에 대해 알려줄 것입니다.

가장 먼저해야 할 일은 정부 기관 (아마도 IT 부서)이 반대하는 것을 구체적 으로 식별 하는 것입니다. 스토리지 공간이 있지만 서버용 VM을 호스팅 할 수있는 방법이 없다면 IT 부서가 SVN 또는 GIT 서버에 아니요라고 말하고 큰 차이가있을 수 있습니다. 문제가 원산 국인 경우 (즉, 외국 기관이 만든 도구를 신뢰하지 않는 경우)는 다른 문제입니다.

파일 시스템 내에서 GIT를 완전히 실행할 수 있습니다. 파일 시스템에서 아무것도 할 준비가되기 전에 영아 프로젝트에서 수행 한 작업입니다. GIT는 설치하기 위해 관리자 권한이 필요하지 않습니다.

어떤 이유로 든 Git을 절대 사용할 수 없다면 몇 가지 옵션을 사용할 수 있습니다.

• 교육 : 버전 관리를 허용하지 않으면 상당한 위험이 발생합니다. 더 문제가있는 것으로 판명 된 변경 사항을 철회 할 수있는 능력이 필요합니다. 정부의 돈과 시간을 절약 할 수있는 능력이 필요하며 SCM이이를 수행합니다. 방법을 명확하게 설명 할 수 있어야합니다. 또한 요점을 실제로 이끌어 내기 위해 대안에 대한 분석을 수행해야 할 수도 있습니다.
  • 하나의 대안은 힘내 호스팅
  • 다른 파일 시스템 Git
  • 대체 SCM 도구를 하나 이상 선택하십시오.
  • 마지막으로 버전 관리없이 작동하는 것
• 70 년대 시대의 개발을 이동 이유가있다 patch그리고 diff너무 오래 전에 (80) 만들었다는. 버전 관리가 가능한 기술이었습니다.

70 년대의 발전은 어떤 모습입니까? 예쁘지는 않지만 우리가 시작한 방법입니다. 응용 프로그램이 훨씬 작습니다. 본질적으로 그들은 몇 가지 공통점이 있습니다.

• 금본위 제라는 개념이있었습니다 . 기능이 완료된 마스터 소스 코드입니다.
• 구성 관리 (CM) 팀이있었습니다. 그들의 책임은 개발에서 금본위 제로 올바르게 변화시키는 것이었다. 이곳은 팀 을 필요로 patch하고 diff대신 할 곳 입니다.
• 소스 코드의 로컬 사본에서 작업했습니다. 전체 기능을 완료 한 후 통합 할 수 있도록 CM 팀에 제출하십시오. 일반적으로 새 파일이 생성되고 더 이상 사용되지 않는 파일이 삭제되는 등의 첨부 문서가 있습니다.
• 그런 다음 통합 프로세스의 오류를 수정하십시오.
• 다른 기능이나 버그 수정을 즐기기 전에 새로운 골드 표준 사본을 받으십시오.

본질적으로 오류가 발생하기 쉬운 프로세스이므로 문제가 발생할 가능성이 많습니다. "분기"라는 아이디어는 구현하기 쉽지만 관리하기에는 악몽입니다. 가장 큰 문제는 소스 코드 사본이 너무 많으면 프로덕션의 올바른 기준이 무엇인지 이해하기 어렵다는 것입니다. 실용성을 위해 싱글 스레드가되어야합니다.

이것이 대안 분석에 포함해야하는 것입니다.

의견에 언급 한 제약 조건 (예 : Git 다운로드 페이지, Windows 플랫폼 및 Visual Studio 2005 사용 불가능)를 감안할 때 비슷한 상황에서 이전에 사용한 두 가지 옵션을 볼 수 있습니다.

1. 의견에서 Emerson이 제안한대로 Visual SourceSafe 를 사용하십시오 . 몇 년 전에 VS 2005를 사용하는 팀과 함께 일했지만 회사의 나머지 대부분은 Linux / Unix에서 표준 버전 제어를 사용했으며 CM에 Visual SourceSafe를 행복하게 사용했습니다. 이 시점에서 그것은 구식이지만 아무것도 아닌 것보다 낫습니다.
2. 아무것도 아닌 것보다 낫다고 말하면, 나는 비슷한 결속에 빠져 있습니다. VSS를 사용할 수없는 경우 (아마 플러그인이 설치되지 않았습니까?) 사용 가능한 스토리지 공간이 충분하다고 말하면 일부를 사용할 수 있기를 바랍니다. 수동 파일 기반 버전 제어 프로토콜을 구현했습니다. 매일 업무가 끝나면 코드베이스를 새로운 날짜 스탬프 디렉토리에 복사합니다. 이전 작업으로 돌아가거나 롤백해야하는 경우 이전에 날짜가 지정된 디렉토리를보고 필요한 변경 사항을 찾습니다. 몇 시간 내에 Visual Studio를 사용할 수 있으므로 VS 2005를 사용하여 디렉터리 생성 및 파일 복사를 자동화하는 간단한 도구를 작성할 수 있습니다.

그들은 많은 저장 공간을 가지고 있습니다

당신의 결정에 그것을 사용할 수 있습니까?

그렇다면 아무 것도없는 파일 시스템 원격 저장소를 만들 수 있습니다 . 단점은 git변경 사항을 찾기 위해 전체 저장소를 다운로드해야하기 때문에 프로젝트가 성장하는 동안 추진 속도가 느려진다는 것입니다 ...

지금까지 컴퓨터는 일반 사용자처럼 동작하여 타사 소프트웨어를 설치하지 못합니다.

git또한 $ HOME 또는 % USERPROFILE % 경로에 설치할 수 있도록 휴대용 앱 으로 제공됩니다 .

결론적으로 : 나는 그들이 SCM ¹ 사용을 금지시키지 않을 것 입니다. "비공개"로 사용하겠습니다. 결국 아무도 코드를 개발했는지 여부와 상관없이 코드가 개발되었는지 알 수 없습니다 ...

¹ ) 내가 사용하기 시작했을 때 git내 고객이 매우 느리고 신뢰할 수 있었다 다른 SCM 선호 몇 년 전에 년의 (a SCM에 대한 NOGO의 일종이다 결국 (O) 내가 사용. git다른 SCM의 상단에 "개인적으로" 네트워크 공유에서 "파일 기반"원격을 사용하고 새 버전의 제품이 출시 된 후에 만 ​​SCM에 체크인했습니다.

당신의 환경

우선, 나는 많은 의견과 답변에 표시된 것처럼 비관적이지 않을 것입니다. 그렇습니다. 이것은 "석기 시대"이지만 훨씬 더 나쁜 환경이 있습니다. 전반적인 작업 환경 (동료, 위치, 급여, 흥미로운 프로그래밍 작업 등)이 훌륭하고 취향에 맞는다면 반드시이를 준수하십시오. IT에 관해서는 그것이 바로 그것입니다. 이것은 정부 기관뿐만 아니라 은행, 보험 또는 보안 또는 매우 오래된 구조에 중점을 둔 곳에서도 발생합니다.

USB 스틱을 삽입하고 거기에서 일부 .exe를 실행하면 다른 장소에서 즉시 종료 될 수 있으므로 아무것도 우회하지 않는 것이 좋습니다.

git 다시 한번 시도하십시오

지금 당신의 선택에. svn 대신 git을 강력히 권장합니다. 어쨌든 1 인 프로젝트를 수행하는 경우 git은 .git응용 프로그램 루트 내의 로컬 디렉토리 일뿐 입니다.

보스 / IT에 "SCM"을 요구하지 말고, git기계 에 설치하도록 특별히 요청하여 보다 빨리 고품질로 개발할 수 있도록하십시오. 당신이 그들에게 분명히 확인 되지 는 않는, 다른 곳으로 코드를 추진하고자 하지 어딘가에 실행하는 서버가 필요하고, 그것은 것입니다 하지 중요한 공간이나 유지 보수 시간을 사용합니다.

Git은 변경 사항을 취소 할 수 있기 때문에보다 자신감있게 작업 할 수 있고 동시에 여러 지점에서 작업 할 수 있기 때문에 속도와 품질이 향상됩니다. 즉, 대규모 작업을하고 있는데 즉시주의를 기울여야 할 것이 있으면 새 지점으로 전환하여 신속하게 수정 한 다음 장기 실행 작업으로 돌아갈 수 있습니다.

수동으로하기

전혀 가능하지 않은 경우 물론 수동 소스 제어를 수행 할 수 있습니다. 코드를 직접 복사하여 수동 "태그"를 작성하십시오 (날짜 / 시간 및 변경된 사항에 대한 간단한 설명이 포함 된 새 디렉토리를 작성할 수도 있음). 변경 사항뿐만 아니라 변경 한 파일 및 더 자세한 내용을 자세하게 나열한 변경 로그를 보관하십시오.

작업을 복사하여 "브랜치"를 다시 만들고 병합 할 시간이되면 임의의 "diff"또는 "diff3"도구를 사용하여 창의성을 발휘하십시오. 사용 가능한 도구가 있는지 모르겠습니다. 찾아.

이 모든 것이 시간이 많이 걸리면 SCM을 에뮬레이트하는 것이 실제로 가치가 있는지 잘 살펴보십시오. 당신이 찾아내는 경우 입니다 가치, 다시 당신의 상사와 이야기. 그에게 매뉴얼 SCM의 이점을 보여주십시오 ( "모든 이전 작업의 사본이 있습니다"뿐만 아니라 "버그 XYZ가 발생했을 때 즉시 5 가지 이유를 찾을 수있었습니다"). 그런 다음이 속도가 얼마나 빠를 지 알려주세요 git.

분명히, 이것이 당신을 미치게한다면, 일자리를 찾는 것이 항상 선택입니다.

여기에 많은 사람들이이 질문의 "정부 기관"이 빠져 있다고 생각합니다. 일부 정부 네트워크에는 허용되는 소프트웨어에 대해 매우 엄격한 규정이 있으며 이러한 규칙을 어기는 것은 심지어 범죄 일 수 있습니다. 소프트웨어를 설치하는 과정에서 승인 된 움직임을 얻을 수 있는지 확인하기 위해 관리 과정을 진행했습니다. 나는 카우보이로 가서 물건을 직접 설치하지 않을 것입니다. Linux / UNIX를 실행중인 경우 RCS (ci / co 명령) 또는 SCCS (sccs 명령)가 설치되어 있는지 확인하십시오. 이것들은 상당히 표준이었던 오래된 SCM 도구입니다. 내가 쓰려고하는 것보다 예쁘지 않지만 낫습니다. :)

디스크 공간이 "많이"있으므로 소스 트리를 작성하십시오. 소규모 SCM의 기본 사항은 무엇입니까? 변경 사항을 체크인하고, 변경된 사항을보고, 태그를 지정하고, 필요한 경우 이전 버전으로 돌아갈 수 있습니다. 소스 트리 위의 한 레벨에서 사용 가능한 항목에 따라 다음을 수행하는 Makefile 또는 스크립트를 작성하십시오 (Linux / UNIX 버전, Windows 명령은 다름).

체크인-cp -source-tree 소스-트리-날짜 (source-tree-20171205115433과 같이 최소한 2 분이 아닌 최소 1 분)

상태 확인-diff -R 소스 트리 소스 트리 날짜 | 적은 것 (여기에 약간의 논리가있을 것입니다. 기본값은 최신 백업이거나 버전과의 차이점을 나타냅니다)

태그 만들기-ln -s source-tree-date release1.0 (특정 버전으로 연결)

되돌리기-rm -r 소스 트리 && cp-소스 트리 날짜 소스 트리

그들에게 판매

이 의견을 남겼습니다 .

그들은 어떻게 모르지만 네트워크 백업을 정기적으로 백업합니다. 예. 나는 그것을 사용하고 거기에 내 앱을 저장합니다.

상사에게 가서이 정맥에서 무언가를 말하십시오.

보스, 우리는 우리가 네트워크 드라이브에 앱을 넣는 시스템이 있고 어떤 종류의 서비스가 백업을하고 기록을 추적하는 시스템을 발견했습니다. 이 작업을 수행하여 자체 소스 제어 시스템을 구현하는 것처럼 보입니다. SVN 또는 git과 같은 전용 소스 제어 관리 시스템으로 전환하면 공간을 많이 확보하고 전체 시스템을 훨씬 간단하게 만들 수 있습니다. 우리는 과거 버전의 간단한 백업, 시간이 지남에 따라 파일 변경 사항을 이해하는 도구 (디버깅에 매우 유용한 정보), 실수를 쉽게 취소 할 수있는 방법, 다른 사람의 변경 사항을 결합하는 더 쉬운 방법 등 많은 이점을 얻습니다.

이전에 이러한 종류의 시스템을 사용해 왔으며 사용자 지정 설정이 수행하는 작업에 매우 능숙합니다. 현재 시스템보다 실수를 저지르기가 훨씬 어렵습니다. 또한 매우 성숙하고 널리 사용되는 기술입니다. 이 도구는 20 년 이상 널리 사용되었습니다. 또한 라이센스 라이센스를 지불하지 않고도 가장 인기있는 소프트웨어를 사용할 수 있습니다.

클라이언트와 서버를 선택하고 설정하는 데 도움을 드리겠습니다. [insert estimate here]기계를 구할 수 있다면 설치하는 데 몇 시간 밖에 걸리지 않을 것으로 예상됩니다 . 네트워크를 통해 액세스 할 수있는 한 모든 컴퓨터, 심지어 오래된 데스크톱도 폐기 될 것입니다.

여기서 높은 수준의 요약은 이해하고 가치가 있다고 생각할 수있는 용어로 작성해야한다는 것입니다.

• 다른 목적으로 리소스 (하드웨어 및 사람) 확보
• 위험 감소 (인적 오류, 안정적인 기술)
• 생산성 향상
• 적은 비용으로 구현

당신의 상사는 기술적 인 사람이 아니며 기술적 인 문제에 관심이 없습니다. 그러나 돈 과 돈 이 드는 면에서 문제의 틀을 잡을 수 있다면, 귀가 조금씩 올라갈 수 있습니다.

질문과 의견을 많이 읽은 후에는 다음과 같은 제약 조건 / 시나리오가 있음을 이해했습니다.

• 프로젝트 당 1 명;
• 프로젝트에 Visual Studio 2005 이외의 외부 도구를 사용할 수는 없습니다. GIT 또는 다른 SCM을 사용할 수 없습니다.
• 로컬에서 작업하는 동안 때때로 자동 백업을 수행하고 항상 작동하도록해야하므로 프로젝트를 깨진 상태로 둘 수 없습니다.
• 변경 사항을 추적하려면 몇 가지 기록이 필요합니다.

VS 2005에서 작동하는 플러그인이있는 Visual Source Safe를 사용할 수없는 경우 다른 방법을 사용할 수 있습니다.

위의 항목을 기반으로 다음과 같은 프로젝트 폴더를 구성하는 것이 좋습니다.

trunk           //last functional version of the app. IMPORTANT: YOU DON'T WORK WITH THIS FOLDER
    UnitTests   //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln
temp              //your working folder; has structure similar to trunk; changes will be commited to trunk;
    UnitTests     //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln  
build
    .history    //folder to contain changes in files and your comment (like commits in git)
    build.bat   //calls MSBuild to build temp\YourProject.sln, and run all unit tests
    save_on_trunk.bat   //if build is working, saves info from "diff.bat" in folder within ".history" with timestamp, and also overrides "trunk" with content from "temp"
    diff.bat         //compares files from "temp" and "trunk", using "dir" and "fc" commands
    history.bat  //outputs content from .history folder (contains file changes and comments)

여기에 따라야 할 기본 규칙 :

• 코드 제어는 프로젝트 폴더 내에서 수행됩니다.
• 당신은 "트렁크"에서 일하지 않습니다;
• "temp"에서 작업하고 , 유닛 테스트를 구현하고 , build.bat를 호출 한 다음 save_on_trunk.bat를 호출 하십시오 .
• 중요 : 완전히 격리 된 단위 테스트를 구현하십시오. 새 코드가 트렁크를 손상시키지 않도록하려면이 기능이 필요합니다.
• 자동 백업이 있으므로 코드를 잃을 가능성이 줄어 듭니다. 따라서 항상 "트렁크"코드를 작동 상태로 만들어야합니다.

기술 솔루션이 부족합니다. 정치적 해결책 만이 남아있다.

1) 개발자 연합. 이미 노조가 있다면, 개발자 인 종업원을 공정하게 대표하지 않는 입장에 도전하십시오. 개발자 연합을 구성하는 것이 개발자의 절반을 지원하지 못하면 GO. 당신은 적합하지 않습니다.

2) 신문 광고. 정부가 법률로 인정 된 언론의 자유를 보장하지 않으면 해고 당할 것입니다.

Windows 용 Git에는 "휴대용"버전이 있습니다. 실제로 아무것도 설치할 필요없이 이것을 PC에 복사하거나 메모리 스틱에 유지할 수 있습니다. 문제가 단순히 설치 인 경우이 문제를 해결할 수 있습니다.

SCM과 완전히 반대되는 경우 ISO-9001, DO-178B 또는 기타 관련 소프트웨어 개발 표준에 대한 질문을 할 수 있습니다.

서버가 전혀없는 베어 디렉토리에서 git을 실행하십시오. 디렉토리를 버전 제어 할 수 있기 때문에 다른 사람이 버전 제어를 사용하는 것은 전혀 중요하지 않습니다. Git은이 불량 SCM 도입 시나리오를 위해 설계되었으며 제대로 작동합니다.

두 번째 사람이 그것을 사용하기 시작하면 공룡이 양동이를 걷어차 기까지 기다려야하더라도 영웅이됩니다. 현재 SCM없이 큰 코드 기반을 관리하는 것은 무능합니다. 실제로 감사없이 비즈니스를 운영하는 것과 같습니다.

실제로 코드 개발자, 버전 기록 및 변경 요청 추적과 같이 전문 개발자로서 주장하고자하는 세 가지가 있습니다.

변경 요청을 직접 추적 할 수 있습니다. 올바른 도구만큼 좋지는 않지만 가능합니다. 두 번째 부분은 코드 검토입니다. 이를 위해서는 코드의 이전 사본과 diff 도구가 필요합니다. 변경이 준비되었다고 생각되면 이전 버전과 신중하게 비교하여 변경 내용을 검토 한 다음 이전 버전을 새 버전으로 교체하십시오.

버전 관리의 경우 직장에서 적절한 솔루션을 허용하지 않으면 쓰기 가능한 DVD 상자가 필요합니다. 다시 돌아올 수있는 버전이있을 때마다 새 DVD를 만듭니다.

(이 모든 것이 OP와 같이 정말로 나쁜 직장에 있지 않는 한 취해야 할 조언은 아닙니다).