소규모 회사 (15 개발자)가 관리되는 소스 / 버전 제어를 사용하지 않는 것이 드문 일입니까? [닫은]

실제로 기술적 인 질문은 아니지만 소스 제어 및 모범 사례에 대한 몇 가지 다른 질문이 있습니다.

내가 일하는 회사 (익명으로 유지됨)는 네트워크 공유를 사용하여 소스 코드와 릴리스 된 코드를 호스팅합니다. 릴리스 여부와 버전 및 버전에 따라 소스 코드를 올바른 폴더로 수동으로 이동하는 것은 개발자 또는 관리자의 책임입니다. 파일 이름과 버전을 기록하는 위치와 변경된 사항에 대해 다양한 스프레드 시트가 점선으로 표시되어 있으며, 일부 팀은 각 파일의 맨 위에 다른 버전의 세부 정보도 표시합니다. 각 팀 (2-3 개 팀)은 회사 내에서 다르게 수행하는 것으로 보입니다. 당신이 상상할 수 있듯이, 그것은 "올바른 사람들"이 물건의 위치를 ​​알고 있기 때문에 조직적인 혼란입니다. 모든 것이 다르기 때문에 혼란스럽고 한 번에 무엇을해야 하는지를 기억하는 사람들에 의존합니다.

한동안 일종의 관리되는 소스 제어를 시도했지만 회사 내에서 충분한 지원을받을 수없는 것 같습니다. 내 주요 주장은 다음과 같습니다

• 우리는 현재 취약합니다. 어떤 시점에서든 누군가 우리가해야하는 많은 릴리스 작업 중 하나를 잊어 버릴 수 있습니다. 이는 전체 버전이 올바르게 저장되지 않았 음을 의미 할 수 있습니다. 필요한 경우 버전을 다시 구성하는 데 몇 시간 또는 며칠이 걸릴 수 있습니다.
• 버그 수정과 함께 새로운 기능을 개발하고 있으며 아직 일부 작업이 완료되지 않았기 때문에 릴리스 릴리스를 지연시켜야하는 경우가 종종 있습니다. 또한 버그 수정이 필요한 경우에도 고객이 새로운 기능이 포함 된 버전을 가져와야합니다. 실제로 우리가 작업중인 버전이 하나뿐이기 때문입니다.
• 여러 개발자가 같은 프로젝트를 동시에 사용하고 있기 때문에 Visual Studio에 문제가 있습니다 (동일한 파일은 아니지만 여전히 문제가 발생 함).
• 개발자는 15 명에 불과하지만 우리는 모두 다르게 행동합니다. 우리 모두가 따라야하는 표준 회사 차원의 접근 방식을 갖추는 것이 낫지 않습니까?

내 질문은 :

1. 이 크기의 그룹에 소스 제어가없는 것이 정상입니까?
2. 지금까지 소스 제어가없는 모호한 이유에 대해서만 설명했습니다. 위의 정보를 감안할 때 소스 제어를 구현 하지 않은 경우 어떤 이유를 제안 할 수 있습니까?
3. 무기고에 추가 할 수있는 소스 제어에 대한 더 이상의 이유 가 있습니까?

나는 왜 내가 그렇게 많은 저항을 받았는지에 대한 느낌을 얻기 위해 주로 요청하고 있으므로 정직하게 대답하십시오.

가장 균형 잡힌 접근 방식을 취했으며 세 가지 질문에 모두 답변했다고 생각하는 사람에게 답변을 드리겠습니다.

미리 감사드립니다

1. 정상 이 아닐 수도 있지만 Treb가 말한 것처럼 아마도 비정상적이지 않을 것입니다.

2. 다른 사람들이 말했듯이, 규모가 큰 회사에서 소스 제어를하지 않는 유효한 이유는 없습니다. 따라서 잘못된 이유 를 식별하고 공격해야합니다 .

   a) 주된 현상 은 " 현상이 깨지지 않으면 고치지 마십시오"라는 현상입니다. 이 방법은 어렵습니다. 작동하지 않고 작동하지 않는 모든 항목을 지적하기 시작하거나 ( '네거티브 사람'으로 빠르게 표시 될 수 있음) 폭발 할 때까지 기다릴 수 있습니다 ( 또는 잘못 될 수있는 모든 것을 강조 할 수 있습니다. 불행하게도 작은 회사를 담당하는 사람들은 실제로 때까지 '잘못 될 수있는 것들'비교적 불 침투성 있습니다 할 잘못 ...

   b) 무지 / 두려움 / 불확실성 : "우리는 실제로 소스 제어가 무엇인지 이해하지 못합니다. 사용 방법을 모릅니다. 어떤 도구를 선택해야할지 모르고, 우리의 스타일이 무너질 것입니다 . " 이것이 내가 여기에 보내지 않을 이유 중 하나입니다.! 그것은 당신에게 꽤 큰 주문 일지 모르지만 너무 많은 변형이나 대안이 아닌 '턴키'솔루션을 제시해야 할 가능성을 극대화하려고 생각합니다. 주어진 도구로 작업하기 위해 작업 프로세스를 어떻게 맞추고 변형시키려는 지; 기존 코드를 백 포트하는 방법 / 방법; 얼마나 빨리 사용자를 '훈련'하고 실행할 수 있다고 생각하는지; 전환 기간을 관리하는 방법 (있는 경우); '비용'이 될 확률 (달러가 아닌 경우 몇 시간)

   c) 다른 이유 (예를 들어, VSS에 대한 이전의 나쁜 경험 또는 지나치게 복잡한 도구에 대한 '공포 이야기'를 읽음)가있을 수 있지만 이러한 도구를 발견 할 때 개별적으로 배팅해야합니다.

3. 다른 답변에 요약 된 소스 제어에 대한 충분한 이유가 있습니다 . 저의 조언은 귀사를 실질적으로 변화 시킬 수있는 2 번 또는 3 번 주를 골라 내고 다듬어 가능한 많은 동료들과의 회의에서 발표하는 것입니다. 토론을 자극하십시오. 즉각 설득하지 않더라도 고착 점에 대한 통찰력을 얻을 수 있습니다.

( 변경 기능 에 대해 읽었 습니까?)

소스 제어없이 규모가 큰 그룹이 작동하는 것은 절대적으로 정상적이지 않습니다. 소스 제어없이 효과적으로 작동 할 수있는 가장 큰 프로그래머 그룹의 크기는 1보다 작거나 같습니다. 모든 규모 의 전문가 팀을 위해 버전을 제어하지 않고 작업하는 것은 절대적으로 용서할 수 없으며 창의력이 없지만 어쩌면 그것을 포기하고 싶은 이유를 찾을 수 없습니다.

버전 관리는 또 다른 도구, 특히 강력한 도구 이며 최소 비용에 비해 막대한 이점 을 제공 합니다. 브랜칭, 자동 병합, 태깅 등과 같은 기타 편리한 기능을 통해 모든 변경 사항을 체계적으로 관리 할 수 ​​있습니다. 빈 버전 이전의 버전을 빌드해야하는 경우 해당 시점에서 코드를 확인하고 다른 후프를 거치지 않고도 빌드 할 수 있습니다 .

더 중요한 것은 버그 수정을 작성해야하는 경우 다른 지점에 있기 때문에 작업중인 새로운 기능을 제공하지 않고도 나머지 개발에 필요한 버그 수정을 업데이트에 병합 할 수 있다는 것입니다. 걱정하지 마십시오. 아직 존재하지 않습니다.

회사의 문화에 도전하고 있기 때문에 저항을 경험하고 있습니다. 당신이 무슨 말을하든 조정하는 데 시간이 걸립니다. 당신이 할 수있는 최선의 방법은 계속해서 추진하는 것입니다. 그리고 회사가 실제로 돈을 벌지 않는다면 개발자 수준에 더 적합한 다른 직업을 찾으십시오.

이 크기의 그룹에 소스 제어가없는 것이 정상입니까?

내 경험상, 그것은 표준이 아니지만 여기의 다른 답변이 제안하는 것처럼 완전히 특이하지는 않습니다. 대부분의 소기업은 소스 제어를 사용하지만 불행히도 상당수는 그렇지 않습니다.

지금까지 소스 제어가없는 모호한 이유에 대해서만 설명했습니다. 위의 정보를 감안할 때 소스 제어를 구현하지 않은 경우 어떤 이유를 제안 할 수 있습니까?

좋은 토론을 위해 SO에 대한 이 질문을 참조하십시오 . 받아 들여진 대답은
"버전 관리를 사용하지 않는 좋은 이유는 없습니다.

무기고에 추가 할 수있는 소스 제어에 대한 더 이상의 이유가 있습니까?

내가 만난 모든 개발자와 프로젝트 관리자 사이의 합의는 물론 프로그래머와 SO에 대한 소스 제어는 필수입니다. 허용되는 모범 사례 입니다. 누군가가 그것을 무시하기로 결정했다면, 이것이 왜 자신에게 올바른 결정인지에 대한 매우 강력하고 설득력있는 주장을 가져야합니다. 지금까지 제시 한 주장은 특정 문제에 중점을두고 있습니다. 아마도 '모두가하는 일'에 따라 더 넓은 접근법을 시도해야 할 것입니다. 왜 우리도 그렇지 않습니까?

소스 제어는 단일 개발자 팀에게도 좋습니다. 모든 소스 제어 시스템은 기본적으로 변경 사항을 추적하는 버전 제어 시스템입니다. 일부 코드를 제거하고 코드가 필요하다고 생각하는 단일 개발자를 상상해보십시오. 그는 이전 코드를 다시 얻을 수 있습니까?

도움이되는 도구를 찾으십시오. 크기는 어디에나 중요하지 않습니다. 품질은 모든 곳에서 중요합니다.

이미 버전 제어 시스템을 사용하고있는 것 같지만 그다지 좋지는 않습니다. 사람들은 이미 필요한 버전 관리를 인식하는 것 같습니다. 다음 버전 인 소프트웨어 버전 제어를 소개하면됩니다.

그것이 저라면, SCM을 그들이 이미하고있는 것의 개선 된 버전으로 소개 할 것입니다. 좋은 도구를 사용하면 이미 진행중인 많은 작업을 자동화하는 방법을 강조하겠습니다.

• SCM 시스템은 스프레드 시트에서 변경 사항을 기록하는 대신 변경된 내용뿐만 아니라 누가 변경 한 이유와 이유를 추적합니다.

• 보너스로 코드 수명의 어느 시점으로 돌아가서 실제로 무엇이 있는지 확인할 수 있습니다.

• 다른 폴더에 서로 다른 코드 버전이 있고 변경 사항을 포트하기 위해 폴더간에 항목을 이동 / 병합해야하는 대신 모든 것을 동일한 위치에 보관할 수 있으며 도구가 병합을 수행하도록 할 수 있습니다.

다른 사람들이 이미 말했듯이, 나는 약간의 저항을 기대할 것이므로 시스템을 내가하고있는 것들에 사용하여 프로토 타입을 만들 것입니다.

(BTW, 실제로 이력서 및 기타 문서를 SVN 아래에 두었습니다. 다시 구성 및 통합 관리자의 역할을 여러 번 수행했습니다.)

지금까지 소스 제어가없는 모호한 이유에 대해서만 설명했습니다. 위의 정보를 감안할 때 소스 제어를 구현 하지 않은 경우 어떤 이유를 제안 할 수 있습니까?

• 개발중인 제품은 버전 관리 시스템입니다. 관리자는 기존 제품이 새 제품의 설계 및 구현에 영향을 미치는 것을 방지하는 데 관심이 있습니다.

• BASE 점프의 주말과 황소와 함께 달리는 스릴을 찾는 관리자는 모든 것이 아직 지옥에 빠졌는지 궁금해하는 운전을 즐깁니다.

• 적대적 인계를 피하십시오. 이런 방식으로 관리되는 소프트웨어 개발 복장을 누가 구매하고 싶습니까?

무기고에 추가 할 수있는 소스 제어에 대한 더 이상의 이유가 있습니까?

• 이미 버전 제어를 수행하고 있지만 현재는 가장 효율적이고 노동 집약적이며 오류가 발생하기 쉬운 방식으로 수행하고 있습니다. VCS를 사용하면 비용을 절약하고 시간을 절약하며 품질을 향상시킬 수 있습니다.

• 디스크 공간을 절약합니다. 대부분의 버전 제어 시스템은 파일 간의 델타 만 저장합니다. 현재 모든 파일의 모든 버전의 전체 사본을 저장하고 있습니다. (모든 사본을 백업하려면 많은 시간과 공간이 필요합니다!)

• 여러 개발자가 같은 파일에서 동시에 작업하고 너무 많은 문제없이 차이점을 조정할 수 있습니다. VCS없이 변경 사항을 병합하는 것은 물론 가능하지만, 누가 언제, 왜, 왜 변경했는지 추적하는 것은 거의 불가능합니다.

• 개발자는 언제든지 모든 버전을 복구 할 수 있다는 것을 알고 새로운 아이디어를 자유롭게 시도 할 수 있습니다.

• 프로세스가 향상되면 재능있는 개발자를 쉽게 고용하고 유지할 수 있습니다.

이 크기의 그룹에 소스 제어가없는 것이 정상입니까?

아닙니다. 현재 회사에서 시작했을 때 변경 한 코드를 보내야 할 사람이 한 명 있었는데이를 병합했습니다. SVN을 사용하도록 며칠 내에 모든 사람을 설득 할 수있었습니다 .

지금까지 소스 제어가없는 모호한 이유에 대해서만 설명했습니다. 위의 정보를 감안할 때 소스 제어를 구현하지 않은 경우 어떤 이유를 제안 할 수 있습니까?

모호한 이유 만 들었던 이유는 버전 관리를 사용하지 않는 유효한 이유가 없기 때문이라고 생각합니다.

무기고에 추가 할 수있는 소스 제어에 대한 더 이상의 이유가 있습니까?

예, 많은 이유가 있습니다.

1. 분기는 다른 개발을 방해하지 않고 새로운 기능을 개발할 수있는 가능성을 제공합니다.
2. 각 커밋은 정확히 변경된 사항, 변경 한 사람 및 변경시기에 대한 정보를 제공합니다.
3. 버그 수정을 쉽게 커밋하고 고객에게 배포하고 완료되지 않은 새로운 기능을 생략 할 수 있습니다.
4. 고객이 최신 버전으로 이동하는 것을 두려워하는 경우 다른 버전을 유지할 수 있습니다.
5. 동일한 프로젝트 (같은 소스 파일까지도)에서 쉽게 작업 할 수 있습니다.
6. 커밋 된 실수 후 변경 사항을 유지하여 실수를 쉽게 되돌릴 수 있습니다.

어떤 사람들은 자신에게 더 좋은 것을 볼 때까지 현 상태가 얼마나 나빠지는지 깨닫지 못하는 데 어려움을 겪습니다. 필요한 것은 좋은 데모 입니다. 개선 할 수있는 실제 작업 예를 보여줍니다. "현재 시스템을 추적하는 데 4 시간이 걸렸지 만이 단일 소스 제어 명령으로 즉시 알려줍니다."

소스 컨트롤을 사용하지 않으면 솔로 개발자에게도 문제가 발생합니다. 아무것도 잃을 위험없이 무자비하게 편집 할 수 있다는 단순한 사실은 몇 주 또는 며칠 내에 학습 노력을 보충합니다.

즉, 관리자가 소스 제어를 도입하도록 설득 할 수 없다면 자신에게 호의를 베풀고 적어도 git 또는 mercurial과 같은 것을 로컬에서 사용하십시오. 소스 제어 부족으로 인해 일이 터지면 최소한 그것을 한 사람.

우리 회사는 버전 관리를 위해 GIT를 사용합니다. 이 회사는 한 명의 개발자, 한 명의 CEO, 한 명의 경비원, 한 명의 청소부 및 한 명의 직원입니다. 그들 모두는 나입니다. 소스 버전 관리는 항상 필수입니다.

나는 많은 프로젝트를 혼자서 일하고 있으며 여전히 버전 관리를 사용합니다. 크기는 중요하지 않습니다. 항상 버전 관리가 가능합니다.

Joel 테스트에서 1 위인 이유는 다음과 같습니다. http://www.joelonsoftware.com/articles/fog0000000043.html

또한 목록의 # 2 및 # 3을 가능하게합니다.

우리는 몇 년 전 6 명으로 구성된 팀과 비슷한 위치에있었습니다. 개발자 중 한 명이 공유 폴더가있는 dev 서버에 SVN을 설치하고 사용하기 시작했습니다.

CI ( CruiseControl )를 구현 하고 자동화 및 품질 검사를 포함하도록 빌드 및 릴리스 프로세스를 혁신 하기까지는 모두가 그 뒤를 따랐습니다 .

이런 씨발?! 이것은 내가 본 것 중 가장 우스운 질문 일 수 있습니다. 새로운 직업을 찾아야합니다. 15 명의 개발자?! 작은 팀이라고 생각하십니까? 이건 미친 짓이야 관리자는 즉시 종료해야합니다. 솔직히이 질문을 읽은 후에 악몽이 생길 것입니다. 판매하지 않는 제품을 알려주십시오. 나는 무엇이 더 무서운지,이 질문, 또는 이것이 드문 일이 아니라고 대답합니다!

소스 제어없이 15 명의 개발자가 어떻게 작업 할 수 있을지 상상할 수 없습니다. 그러나

(...)는 네트워크 공유를 사용하여 소스 코드를 호스팅합니다 (...)

VSS (공유 폴더를 기반으로 함) 와 같은 자신의 가난한 사람의 버전 컨트롤을 생성했다고 가정합니다 . 위험하고 비효율적입니다.

상사에게 그것이 얼마나 나쁜지 설명하고, 2 일 간의 SVN 또는 GIT 교육에 투자하고, 코드가 합리적인 형태로 유지되는 동안 실제 버전 제어 시스템을 사용하기 시작하십시오.

하루에 여러 번 또는 적어도 집으로 떠나기 전에 약속을하지 않으면 뭔가 빠진 것, 잘못된 것 같은 느낌이 듭니다.

1998 년에 2 명의 개발자 (me + long haired admin guy)와 함께 회사에서 근무한 적이 있습니다. 심지어 svn을 사용했습니다. 너무 편리합니다.

내 경력에서 여러 번 나는 cp 대신 mv와 rm -rf 대신 mv와 같은 것을했기 때문에 며칠의 일을 잃었습니다. 절망으로 도시의 거리에서 울고 돌아 다녔다.

저는 SE에서 13 년 동안 5 개의 회사에서 근무했으며 일부 회의에 참석했으며 버전 관리를 사용하지 않는 회사를 만나지 못했습니다.

그러나 제가 가장 좋아하는 인테리어 디자인 회사 인 직원 20 명은 프로젝트 관리 및 공동 작업에 화이트 보드를 사용합니다. 그들은 명백한 잘못을 알고 있지만 업그레이드 할 시간을 찾지 못하는 것 같습니다. 어떻게 든 작동합니다. 방법을 묻지 마십시오.

리더가 되십시오. 리더가된다는 것은 올바른 일을하는 것을 의미합니다. 능동적으로 문제를 해결합니다. 합의가 충분하지 않기 때문에 리더십은 아무것도하지 않습니다. 그리고 훌륭한 지도자는 합의를해야 할 때와해야 할 때를 인식하는 법을 배웁니다. 이것은 분명히 상황입니다. 코드 제어가 부족하면 조만간 얼굴이 터질 것입니다.

리더는 종종 공식 관리직에 있지 않습니다. 사람들은 제목에 관계없이 훌륭하고 결정적인 리더를 따릅니다.

특히 경영진의 결정에 따라 결정적인 노력이 멈춰지면 지옥에서 나가는 것이 분명합니다. 그것은 당신의 직업적인 발전에 끌립니다. 유능한 개발자와 무능한 경영진은 섞이지 않으며 무능한 힘을 가진 사람은 당신을 망칠 것입니다.

좋아, 플래시백이 나에게 닿고있다. 사인 오프 행운을 빕니다.

1. 스톱워치를 받으십시오.
   • 버전 동기화를 위해 스프레드 시트에서 소비 한 시간 계산
   • 깨진 버전을 복구하는 데 소비 한 시간 계산
   • 사람들이 복도에서 소리 치는 횟수를 세어 보세요. "지금 main.c!를 편집하고 있습니다. .
   • 버그 수정에 다른 변경 사항이 포함되어있어 고객으로부터받은 불만 수를 계산합니다.
   • 버전을 동기화 할 수 없었기 때문에 릴리스 시간 지연 계산
2. 이 데이터로 파워 포인트를 만들고 vc가 어떻게 작동하는지 비교하십시오.
3. 쇼 관리

이것은 단지 사고를 기다리고 있습니다. 코드 히스토리가 없으며 한 번의 실패로 개발자 중 한 명이 수개월의 작업을 지울 수 있습니다. 소규모 회사는 이런 종류의 좌절을 감당할 수 없습니다.

또한 해당 공유 드라이브에 매우 노출되어 있습니다. 백업이 양호하더라도 작업을하지 않는 데 시간이 얼마나 걸릴 수 있습니까? 1 시간 1 일 1 주 새 서버를 설치하고 백업 등으로 복원하는 데 시간이 얼마나 걸립니까? 다시 소규모 회사 인 경우 대기중인 추가 하드웨어가없고 빠른 배송 등을 위해 돈을 쉽게 버리지 못할 수도 있습니다.

오프 사이트 스토리지에 대해서도 생각하십시오. 홍수 나 화재는 그렇게 드문 일이 아닙니다. 몇 시간 후에 건물에 화재가 발생하면 어떻게됩니까? 몇 개월의 작업이 손실 될 수 있습니다. github와 같은 관리 코드 저장소는 이것에 유용 할 것입니다. 호스팅 된 서비스에서 간단한 SVN 서버를 사용해도이 영역에서 한 단계 업그레이드됩니다.

LordScree, 나는 당신과 거의 같은 처지에 있습니다. 제 직속 팀은 약 15 명의 개발자입니다. 나는 소스 컨트롤이 사용되지 않는다는 불신 (거의 공포)에 있습니다. "소스 제어를 사용해야합니다"에 대한 나의 초기 응답은 "구현할 시간이 없습니다"였습니다. 나에게 속옷을 입는 것처럼 소스 제어는 선택 사항이 아닙니다. 몇 달 후, 나도 TFS를 구현할 수있는 승인을 받았습니다. TFS는 MS이기 때문에 90 일 평가판이 제공되기 때문입니다. 결론적으로, 조직이 소스 제어 없이도 소스 제어가 필요하다는 사실을 조직에 확신시키는 것은 매우 어렵다. 필자는 개발자가 파일 백업, 특히 백업 된 파일 이름 또는 디렉토리에 날짜가있는 파일을 발견하면 언제든지 소스 제어에 무언가를 넣는 예라고 말합니다. 나는 t 당신에게 어떤 훌륭한 답변을 가지고 있지만, 나는 이것이 드문 것이라고 생각합니다. 나는 같은 전투에서 싸우고 있으며 진행 상황을 계속 알려줄 것입니다. 그리고 다른 곳에서 바라본 진전이있을 수 있기를 바랍니다.

우리는 3 명의 개발 직원이 있으며 소스 제어를 사용합니다. 내 개인 프로젝트에는 한 명의 개발자가 있으며 소스 제어를 사용합니다. 팀 관리에만 유용 할뿐 아니라 무언가를 파괴하려는 두려움없이 실험적인 작업을 수행 할 수있는 데 유용합니다.

경영진을 설득하는 가장 쉬운 방법은 무엇입니까? 전체 제품에 대한 위험이 적으며 장기적으로 개발자 생산성이 향상됩니다. 둘 다 사실이며 둘 다 관리자에게 호소합니다.

결코 정상적인 시나리오는 아니며 회사 에서이 설정을 얻는 데 어려움을 겪어야한다고 생각합니다. 종말에 다가 갈 때 이점을 얻지 못하고 동일한 것을 실현하는 데 아무런 의미 가 없으며 부서지지 않은 경우 수정하지 마십시오.

그것을 구현하지 않은 이유는 나쁜 일에 대한 변명이나 실수가 일어나기를 기다리는 것일 수 있습니다.

올해 1 월 1 일에 앱의 내용 을 찾는 것이 얼마나 좋은지 알려주세요.

이 기능이 3 월에 추가 된 방법에 대해서는 조금 더 확장해야한다고 생각합니다.

와우이 버그 154256이 커밋에서 수정되었습니다.

나는 응용 프로그램을 분기하고 배포 할 수있는 문제가없는 사람을 보낼 수 있습니다.

이것은 계속 될 수 있습니다 ... (다른 질문으로 오는 다른 커밋에 대해서는 주석을 추가해야 함)

저는 한 사람의 프로젝트와 작업 프로젝트에 버전 제어를 사용합니다. 여기서 30 명에서 40 명 이상의 사람들이 한 번에 같은 코드로 작업하고 있습니다. 버전 관리에는 조직적인 이점이 있지만 파일을 되돌리고 변경 사항을 숨기는 기능은 실제로 코드 관리를 어렵게 만들 수 있으며 결국 프로그래머에게 가장 좋은 시나리오이므로 코딩에만 집중할 수 있습니다.

버전 관리를 사용하지 않는 이유는 상당히 제한적입니다. 내가 생각할 수있는 것은 사물의 기술적 측면입니다.

• 전체 직원의 워크 플로를 버전 관리 시스템을 통합하여 비용 효율적으로 변환하기에는 학습 곡선이 너무 많습니다.
• 프로젝트 관리자는 리포지토리 관리 및 유지 관리 워크 플로에 오버 헤드를 도입하는 것이 유리하다고 생각하지 않습니다. (이전 버전 관리 시스템의 주요 문제)

버전 관리 시스템을 사용하는 데는 여러 가지 이유가 있습니다. 적어도 물건을 옮기는 것을 멈추십시오. 패치 작업 버전 관리 시스템은 사용자가 말한대로 정확하게 수행 할 수 있습니다.

• 버그 수정을 수행하는 동시에 다음 버전에서 작업하여 별도로 릴리스 할 수 있습니다.
• 작업을 위해 한 위치에서 다른 위치로 파일을 이동하는 대신 분기를 작성하고 완료시이를 마스터에 병합 할 수 있습니다.
• 각 개발자는 자신의 소스 코드 사본을 보유하여 여러 시스템에서 동일한 프로젝트가 열려있는 문제를 방지 할 수 있습니다.
• 코드가 심각하게 손상된 경우 마지막 작업 개정 번호로 롤백해야하는 모든 상황이 발생합니다.
• 버전 관리는 버그 추적기 및 지속적인 통합 시스템과 잘 작동합니다.

나는 개인적으로 한 사람 팀이 버전 관리, 버그 추적, 지속적인 통합, 코드 검토, 코드 일관성 검사, 단위 테스트, 셀레늄 테스트, 소스 코드 분석을 사용하고 잊어 버릴 수 있습니다. 나는 약간의 학습 곡선이 있음을 인정한다. 자동화하는 추가 단계에 필요한 추가 관리 시간의 균형도 있습니다. 내 경험상 절약 된 노력은 추가 관리 시간보다 중요합니다.

1990 년에 처음으로 심각한 일을하면서 저는 부서에서 일하는 유일한 개발자였으며 ​​소스 제어를 사용하는 방법을 몰랐습니다.

그 후 얼마 지나지 않아 저는 처음부터 프로젝트를 시작하지 않은 프로젝트를 본 적이 없습니다.

폴더를 잘못된 수준에서 삭제했기 때문에 해당 작업에서 모든 작업이 거의 손실되었습니다. 운 좋게도 나는 일주일 전에 5 인치 플로피로 집을 가져 왔고 며칠 동안 몇 주 동안 일을 다시 만들 수있었습니다.

그래서 그것이 팀의 모든 사람들을위한 첫 번째 프로젝트 였고 아무도 더 잘 알지 못했다면 받아 들일 수 있다고 생각합니다. 그러나 한 사람조차도 실제로 이점을 설명 할 수 있고 팀이 여전히 듣지 못하면 "순진한"에서 "위험한 무능한"에 이르기까지 그룹에 대한 의견 ).

나는 많은 임베디드 소프트웨어 / 하드웨어를 수행하는 소규모 엔지니어링 / 전자 회사에서 이것을 많이 생각해 냈습니다.

이러한 곳에서 SCM은 전자 공학 문화의 일부가 아닙니다. 일반적으로 프로젝트 당 한 명의 엔지니어가 있으며 최신 릴리스 만 백업하면됩니다.

따라서 분기 / 병합 및 공유 코드는 관련이없는 것으로 간주됩니다. 또한 이러한 회사는 아마도 ISO9000이므로 프로세스가 문서화되어있을 수도 있습니다.

어쨌든 I / 다른 개발자는 SCM을 개인적으로 사용하기 시작했습니다.

내가 일하는 곳에서도 같은 문제가 있습니다. 현재 "레이더 아래"에서 소스 제어를 슬라이드하여 동일한 문제를 해결하려고합니다. 개인적으로 개발 한 프로젝트에 화석 을 사용 합니다.

최근에 회사 LAN에 화석 서버가 ​​설치되어 훨씬 편리해졌습니다. 나는 소규모 프로젝트에 대한 유용성을 보여줄 때 저항을 약화시키고 네트워크 폴더의 현 상태에서 멀어지기를 바라고 있습니다.

화석이나 다른 VCS를 사용하지 않은 것으로 들었던 가장 큰 이유는 다음과 같습니다.

1. 많은 "프로그래머"는 스크립트 키드이며 사용 방법을 이해하지 못합니다
2. 배울 수있는 사람들은 사용하는 것이 성가신 것이라고 생각합니다.
3. 이 사람들은 네트워크 폴더에 익숙한 오래된 가드이므로 모든 사람이
4. 아무도 그것을 올바르게 설정하거나 사용하는 방법을 배울 시간이 없습니다
5. 기능은 훌륭 할 수 있지만 그 중 어느 것도 필요하지 않습니다

보시다시피, 사용하기 쉽고 이미 설정되어 있으며 배우기 쉽고 기능이 가치가 있음을 보여줌으로써 이러한 문제를 해결하려고합니다.

마지막으로 소스 제어를 사용하지 않아도 네트워크 트리에 있습니다. 화석은 전체 트리에서 모든 것을 버전 관리 할 수 있으며 파일 변경이 발생할 때마다 또는 적어도 매시간 실행되도록 설정할 수 있습니다. "소스 제어가 필요하지 않은"프로젝트 중 일부에 대해서는 문제가 발생했을 때 좋은 버전으로 롤백 할 수있게되었습니다.

제대로하면 그들이 한 일조차 알지 못할 것입니다. 그럼 당신은 깨진 빌드를 복원, 영웅이 될 수 및 당신의 도구가 얼마나 유용 보여줍니다.

이제 Git 및 Mercurial과 같은 DVCS 도구를 사용할 수 있고 설정 및 사용이 매우 쉬워 졌으므로 소스 제어를 사용하지 않는 1 (!)의 팀조차도 변명의 여지가 없습니다. 팀 규모에 관한 것이 아니라 변경 사항에 대한 주석이 달린 기록과 새 릴리스에서 작업하는 동안 생산 문제를 해결하고 다른 버전의 소스 코드 상태를 추적하는 등의 워크 플로를 지원하는 기능에 관한 것입니다.

내가 그 규모에 도달 한 팀에서 일자리를 제공 받았는데 개발자 중 한 명이 VCS 사용을 제안하지 않았거나 "관리"로 인해 방해받지 않았다면 평평하게 거절 할 것입니다. 요즘은 일할만한 방법이 아닙니다.

즉시 GIT 버전 관리를해야합니다. Google Code Project Hosting에서도 사용할 수 있습니다. 다른 사람들이 수동으로 내용을 복사하는 동안 클릭 한 번으로 변경 내용을 커밋하면 마음이 바뀔 수 있습니다.

와우, 그냥 와우. 코드 제어를 처리하는 가장 좋은 방법이라고 생각하지는 않지만 6 명의 개발자가있는 회사에서 근무했으며 소스 제어가 사용되지 않은 것은 드문 일이 아니며 파일, 릴리스 관리자 및 모든 변화를 감독하지 않을 것. 실제로는 일종의 스위치가 기능을 둘러싼 한 새로운 기능을 프로젝트에 추가 할 수 있어야한다는 것이 필수였습니다.

예를 들어, 우리는 PHP로 작성된 ab 급 소셜 네트워크에서 작업하고 있었고 클라이언트는 사용자 프로파일을 구독 할 수있는 기능을 원했습니다. 기본적으로 기능은 (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {다음과 같이 검사에 래핑되었습니다.}

내가 근무했던 장소는 특정 파일을 작업하는 한 번에 두 명 이상의 개발자가 없었습니다. 대부분 모든 것이 모듈 식이므로 소스 제어가 필요하지 않았습니다. 그러나 소스 컨트롤의 장점은 대부분의 경우 소스 컨트롤이 없다는 단점보다 훨씬 큽니다.

회사가 파일 변경 사항을 문서화하는 스프레드 시트에 의존하고 Git 또는 Subversion과 같은 것이이를 처리 할 수있게되었을 때 변경된 내용은 정말 터무니 없습니다.

당신이 확신하는 것처럼 보이지만 조직의 누군가가 당신에게 권한을 부여하지 않습니다. 다른 의견을 읽을 수 있으므로 그렇게해야합니다.

여기에서 몇 가지 정보를 찾을 수 있습니다. http://www.internetcontact.be/scm/?page_id=358

가장 중요한 요소는 고객이 마지막 '사용할 수없는'지점으로 이동해야하며 고객과의 계약으로 인해 불안정한 버전을 배포해야하는 경우 회사에서 돈을 잃는 것입니다. 여기서 릴리스 안정성에 중점을 두어야합니다. 이것이 소스 제어의 주된 이유이며 주요 실패로 보입니다. 다른 시스템이 이미 준비되어 있으므로 소스 제어를 사용하여 다른 시스템은 그다지 향상되지 않습니다.