일반 회사의 대규모 프로젝트에 어떤 소스 제어가 필요합니까? [닫은]

Git이 오픈 소스 프로젝트에 적합하다는 것을 알고 있습니다. 그러나 궁금한 점이 있습니다. 프로그래머가 20 명인 1 년 프로젝트를 진행하는 회사의 경우 어떤 소스 제어 시스템이 바람직한가요? 내가 들었던 것에서 Git은 당기기를 사용한다. 메인 트렁크에서 변경 사항을 얻기 위해 다른 누군가를 거쳐야하는 것이 바람직하지 않습니까? 특히 모두가 동시에 일할 때?

그것은 내가 궁금했던 예일뿐입니다. SVN을 사용하는 방법을 알고 있지만 마지막 작업에서도 PHP에서 모든 것이 사용되었으며 일반적으로 독립형 1 주 프로젝트이기 때문에 프로젝트에서 사용하지 않았습니다. 방금 로컬 코드에 SVN이 있었고 다른 사람들과 함께 사용할 필요가 없었습니다.

좋은 소스 컨트롤은 무엇이며, 특히 왜 좋은가요?

팀이 편한 것을 사용하십시오. 모든 버전 관리 시스템은 비슷한 방식으로 거의 동일한 기능을 수행합니다. 휠이 더 잘 작동하기 때문에 휠을 다시 발명 할 이유가 없습니다. 팀에 익숙하지 않은 경우 팀의 표준 IDE와 가장 쉽게 통합 할 수있는 옵션을 선택하십시오.

머큐리얼은 훌륭하고 분산되어 있으며 무료입니다.

필요한 지원 수준에 달려 있다고 생각합니다.

문제가 생길 때 집에서 git을 재미있는 프로젝트에 사용하는데 시간이 걸리지 만 문제를 해결하는 데 배우는 데 시간을 할애 할 수 있습니다.

24/7 기술 지원이 필수적이기 때문에 직장에서는 Perforce를 사용합니다. 우리는 뉴욕, 독일, 아일랜드 및 일본에서 항상 코드 작업을하는 사람들이 있습니다. 문제가 있으면 최대한 빨리 답변을 받아야합니다. 내 경험상 Perforce 직원들은 자신이하는 일을 실제로 알고 있으며 제안을 받아들입니다.

이 질문이 광범위하고 IT 프레임 워크 및 네트워크 / 개발 구조에 따라 회사별로 해결되어야한다고 생각하지만 소스 / 버전 제어를 선택하는 가장 중요한 측면은 사용하는 응용 프로그램이 아니라고 생각합니다. 그러나 사용 여부는 실질적으로 구성되고 시행됩니다.

사용의 구조와 시행은 버전 관리에서 가장 중요한 측면입니다.

미리 계획하고 모든 사람을 탑승시킵니다. 사용을 강화하십시오. 프로그래머뿐만 아니라 프로젝트 (문서, 이미지 등)와 관련된 모든 것.

SVN은 훌륭한 응용 프로그램이며 많은 추가 기능 (버그 / 작업 추적 포함)과 통합 될 수 있으며 별도의 서버가 필요 없으며 무료입니다!

@EricBoersma가 말했듯이 다른 좋은 소스 제어 응용 프로그램도 있습니다.

팀이 편한 것을 사용하십시오.

프로세스와 모범 사례를 마련하고이를 시행 할 수있는 방법으로 구매하십시오.

git의 작동 방식에 대한 큰 오해가 있습니다. 게이트 키퍼로 풀 요청을 보내는 것은 한 가지 방법 일뿐입니다. svn과 거의 같은 것을 포함하여 설정하는 다른 많은 방법이 있습니다. git과 같은 DVCS를 사용하면 소스 컨트롤을 워크 플로우를 중심으로 구성 할 수있는 충분한 옵션이 있습니다.

소스 제어는 도구 일 뿐이며 각 제품은 거의 동일한 작업을 수행한다는 견해를 가지고있었습니다. 그리고이 분산 버전 제어 시스템의 요점은 저와 함께 클릭되었습니다.

분산 버전 제어를 통해 둘 이상의 중앙 저장소를 가질 수 있습니다. 로컬 개발자 저장소에서 기능 저장소로, 제품 저장소로, QA 저장소로, 마지막으로 릴리스 된 저장소로 마이그레이션하는 코드 변경을 상상해보십시오.

개인적으로 Hg를 기반으로하는 Kiln이라는 상용 제품을 사용하지만 주요 기능은 분산 버전 제어 입니다. 개발자에서 출시 된 제품으로 새로운 코드 흐름을 혁신합니다.

SVN을 사용하는 방법을 알고 SVN을 사용하십시오. 필요한 것이 있으면 DVCS로 마이그레이션하십시오.

정말로 중요한 것은 사용하고 싶은 것을 사용하기 쉽다는 것입니다. 마틴 파울러 (Martin Fowler)는 VCS에 대해 간단한 간단한 설문 조사를 실시 했는데 그 결과 는 매우 흥미 롭습니다.

비슷한 크기의 프로젝트 (15 명의 개발자, 18 개월 프로젝트)에서 작업하고있는 마지막 직장에서 자식을 설정했으며 제대로 작동했습니다.

우리가 설정 한 방식은 다음과 같습니다.

중앙 집중식 권한있는 git 서버 인 git 서버가 있습니다. 모든 변경 사항이 중앙 서버로 전달되도록 팀 구성원은 서로 직접 연결하지 않는 것이 좋습니다.

우리는 마스터 브랜치를 주 생산 브랜치로 사용했고 각 릴리스에 대한 태그를 사용했습니다. 프로젝트의 각 모듈은 자식 하위 모듈이었습니다. 각 하위 모듈에는 각 팀원별로 지점이 있습니다. 관리자 (보통 원래 작성자)는 각 하위 모듈에 할당되었으며 다른 팀 구성원의 풀 요청을 처리하고 팀 브랜치에 하위 모듈을 업데이트 할 수있는 팀 리더에게 풀 요청을 발행 할 책임이있었습니다. 생산 지점에 통합됩니다. 특정 기능을 완료했거나 릴리스에 해당하는 커밋을 식별하기 위해 태그를 사용했습니다.

저는 적어도 Microsoft의 TFS (Team Foundation System)에 좋은 모습을 보여줄 것입니다. 귀하가 Microsoft 상점이 아니라는 귀하의 의견에 동의합니다. 그러나 내 이해는 개발에 IDE를 사용하면 상당히 강력한 Eclipse 플러그인이 있다는 것입니다.

병합 및 분기 메커니즘은 다른 소스 제어 시스템 (SVN보다 뛰어나고 경험 상으로는 perforce만큼 우수함)만큼 훌륭하게 작동하지만 제품의 프로젝트 추적 및 프로젝트 관리 측면은 실제로 빛나고 있습니다. 빌드 및 배포를위한 내장 된 자동화

웹 기반 애플리케이션을 작성하는 경우 자동화 된 UI 테스트 프레임 워크 및로드 테스트 프레임 워크를 살펴보고 매우 짧은 순서로 구성 및 구성 할 수 있습니다. 하나의 세련된 기능 :로드 테스트에 내장 된 모바일 브라우저 시뮬레이션.