기업의 Git 기반 소스 제어 : 권장 도구 및 사례?

나는 개인 프로젝트에 git을 사용하며 훌륭하다고 생각합니다. 빠르고 유연하며 강력하며 원격 개발에 적합합니다.

하지만 지금은 직장에서 의무화되어 있으며 솔직히 문제가 있습니다.

기본적으로 git은 다양한 능력과 수준의 git 정교함을 가진 개발자가있는 대규모 (20 명 이상의 개발자) 조직에서 중앙 집중식 개발에 적합하지 않은 것 같습니다. 특히 Perforce 또는 Subversion과 같은 다른 소스 제어 시스템과 비교하면 그런 환경을 겨냥하고 있습니다. (예, 알아요. Linus는 그것을 의도하지 않았습니다.)

하지만-정치적 이유로-우리가하려는 일이 싫더라도 git과 붙어 있습니다.

다음은 우리가보고있는 몇 가지 사항입니다.

• GUI 도구는 성숙하지 않았습니다.
• 명령 줄 도구를 사용하면 병합을 망칠 수 있고 다른 사람의 변경 사항을 지울 수 있습니다.
• 전역 읽기 전용 또는 읽기-쓰기 권한 이상의 사용자 별 저장소 권한을 제공하지 않습니다.
• 저장소의 모든 부분에 대한 권한이있는 경우 저장소의 모든 부분에 대해 동일한 작업을 수행 할 수 있으므로 다른 사람이 할 수없는 중앙 서버에 소규모 그룹 추적 분기를 만드는 것과 같은 작업을 수행 할 수 없습니다. 엉망입니다.
• "무엇이든 간다"또는 "자비로운 독재자"이외의 워크 플로우는 시행은 말할 것도없고 장려하기 어렵습니다.
• 하나의 큰 저장소 (모든 사람이 모든 것을 엉망으로 만들 수 있음)를 사용하는 것이 더 나은지 또는 많은 구성 요소 별 저장소 (버전 동기화를 시도하는 데 골칫거리가 됨)를 사용하는 것이 더 나은지 여부는 명확하지 않습니다.
• 여러 저장소를 사용하는 경우 다른 사람이 중앙 저장소에서 가져 와서 가지고있는 모든 소스를 복제하거나 어제 오후 4시 30 분에 모든 것을 가져 오는 것과 같은 작업을 수행하는 방법도 명확하지 않습니다.

그러나 사람들이 대규모 개발 조직에서 git을 성공적으로 사용하고 있다고 들었습니다.

그러한 상황에 처해 있거나 일반적으로 명령 줄 팬이 아닌 대규모 조직에서 git을 더 쉽고 생산적으로 사용할 수있는 도구, 팁 및 트릭이있는 경우-당신이 가진 것을 듣고 싶습니다. 제안합니다.

BTW, 나는 이미 LinkedIn에서이 질문의 버전을 요청했지만 실제 답변은 없지만 "이런, 저도 알고 싶습니다!"

업데이트 : 명확히하겠습니다 ...

내가 일하는 곳에서는 git 이외의 것을 사용할 수 없습니다 . 옵션이 아닙니다. 우리는 그것에 붙어 있습니다. 우리는 mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS 또는 1987 년에 사용했던 Apple의 좋은 프로젝터를 사용할 수 없습니다. 따라서 다른 옵션에 대해 논의하는 것은 환영하지만 git에 대해 논의하지 않으면 현상금을받을 수 없습니다.

또한 기업에서 git을 사용하는 방법에 대한 실용적인 팁을 찾고 있습니다 . 이 질문의 맨 위에 우리가 겪고있는 문제의 전체 세탁 목록을 넣었습니다. 다시 말하지만 사람들은 이론에 대해 토론 할 수 있습니다. 하지만 현상금을 받고 싶다면 해결책을주세요.

일반적인 의견과 달리 DVCS를 사용하는 것은 매우 유연한 워크 플로를 가능하게하므로 기업 환경에서 이상적인 선택이라고 생각합니다. 먼저 DVCS 대 CVCS 사용, 모범 사례, 특히 git에 대해 이야기하겠습니다.

엔터프라이즈 컨텍스트에서 DVCS 대 CVCS :

여기서는 일반적인 장단점에 대해 이야기하지 않고 컨텍스트에 초점을 맞 춥니 다. DVCS를 사용하려면 중앙 집중식 시스템을 사용하는 것보다 더 잘 훈련 된 팀이 필요하다는 것이 일반적인 개념입니다. 이는 중앙 집중식 시스템이 워크 플로우 를 쉽게 시행 할 수있는 방법을 제공하기 때문입니다. 분산 형 시스템을 사용하려면 설정된 규칙을 고수 하려면 더 많은 의사 소통 과 규율이 필요합니다 . 이것이 오버 헤드를 유발하는 것처럼 보일 수 있지만, 좋은 프로세스를 만드는 데 필요한 증가 된 커뮤니케이션에서 이점을 봅니다. 팀은 일반적으로 코드, 변경 사항 및 프로젝트 상태에 대해 통신해야합니다.

규율의 맥락에서 또 다른 차원은 분기와 실험을 장려하는 것입니다. 다음 은 버전 제어 도구에 대한 Martin Fowler의 최근 bliki 항목 에서 인용 한 것입니다 . 그는이 현상에 대한 매우 간결한 설명을 발견했습니다.

DVCS는 실험을위한 빠른 분기를 권장합니다. Subversion에서 분기를 수행 할 수 있지만 모든 사람이 볼 수 있다는 사실은 사람들이 실험 작업을 위해 분기를 열지 못하게합니다. 마찬가지로 DVCS는 작업의 체크 포인트를 권장합니다. 컴파일하거나 테스트를 통과하지 못할 수도있는 불완전한 변경 사항을 로컬 저장소에 커밋하는 것입니다. 다시 Subversion의 개발자 분기에서이 작업을 수행 할 수 있지만 이러한 분기가 공유 공간에 있다는 사실은 사람들이 그렇게 할 가능성을 줄입니다.

DVCS는 단순한 텍스트 차이 대신 DAG (Directed Acyclic Graph)에서 전역 적으로 고유 한 식별자를 통해 변경 집합 추적을 제공하므로 유연한 워크 플로를 지원합니다. 이를 통해 매우 중요 할 수있는 변경 집합의 출처와 기록을 투명하게 추적 할 수 있습니다.

워크 플로우 :

Larry Osterman (Windows 팀에서 일하는 Microsoft 개발자)은 Windows 팀에서 사용하는 워크 플로에 대한 훌륭한 블로그 게시물을 가지고 있습니다. 특히 다음과 같은 이점이 있습니다.

• 깨끗한 고품질 코드 전용 트렁크 (마스터 리포지토리)
• 모든 개발은 기능 분기에서 발생합니다.
• 기능 팀에는 팀 저장소가 있습니다.
• 그들은 정기적으로 최신 트렁크 변경 사항을 기능 브랜치에 병합합니다 ( Forward Integrate ).
• 완전한 기능은 검토, 테스트 범위, Q & A (자체 리포지토리)와 같은 여러 품질 게이트를 통과해야합니다.
• 기능이 완성되고 허용되는 품질이있는 경우 트렁크에 병합됩니다 ( Reverse Integrate )

보시다시피 이러한 각 저장소를 자체적으로 유지하면 서로 다른 속도로 진행하는 서로 다른 팀을 분리 할 수 ​​있습니다. 또한 유연한 품질 게이트 시스템을 구현할 수있는 가능성은 DVCS와 CVCS를 구별합니다. 이 수준에서도 권한 문제를 해결할 수 있습니다. 소수의 사람 만 마스터 리포지토리에 액세스 할 수 있어야합니다. 계층의 각 수준에 대해 해당 액세스 정책이 포함 된 별도의 저장소가 있습니다. 실제로이 접근 방식은 팀 수준에서 매우 유연 할 수 있습니다. 팀 리포지토리를 서로 공유할지 또는 팀 리더 만 팀 리포지토리에 맡길 수있는보다 계층적인 접근 방식을 원하는지 결정하려면 각 팀에 맡겨야합니다.

(사진은 Joel Spolsky의 hginit.com 에서 도난 당했습니다 .)

하지만이 시점에서 한 가지 말해야 할 사항은 다음과 같습니다. DVCS가 뛰어난 병합 기능을 제공하더라도 이것이 지속적인 통합 사용을 대체 할 수 는 없습니다 . 그 시점에서도 트렁크 리포지토리를위한 CI, 팀 리포지토리를위한 CI, Q & A 리포지토리 등 상당한 유연성이 있습니다.

엔터프라이즈 컨텍스트에서 Git :

Git은 이미 지적했듯이 엔터프라이즈 컨텍스트에 이상적인 솔루션이 아닐 수 있습니다. 귀하의 우려 사항 중 일부를 반복하면서 가장 주목할만한 것은 다음과 같습니다.

• Windows에서 여전히 다소 미숙 한 지원 (최근에 변경된 경우 수정 해주세요) 이제 Windows에는 atlassian의 github windows client , tortoisegit , SourceTree가 있습니다.
• 성숙한 GUI 도구 부족, 일류 시민 vdiff / 병합 도구 통합 없음
• 내부 작업 위에 매우 낮은 수준의 추상화가있는 일관성없는 인터페이스
• SVN 사용자를위한 매우 가파른 학습 곡선
• Git은 매우 강력하고 히스토리를 쉽게 수정할 수 있습니다. 자신이 무엇을하는지 모르는 경우 매우 위험합니다 (알고 있다고 생각하더라도 때때로 발생합니다).
• 사용 가능한 상업적 지원 옵션 없음

여기서 git vs. hg flamewar를 시작하고 싶지 않습니다. 이미 DVCS로 전환하여 올바른 단계를 수행했습니다. Mercurial은 위의 몇 가지 사항을 다루기 때문에 엔터프라이즈 컨텍스트에 더 적합하다고 생각합니다.

• 파이썬을 실행하는 모든 플랫폼이 지원됩니다
• 모든 주요 플랫폼 (win / linux / OS X)에 대한 뛰어난 GUI 도구, 일류 병합 / vdiff 도구 통합
• 매우 일관된 인터페이스, svn 사용자를위한 쉬운 전환
• git도 할 수있는 대부분의 작업을 수행 할 수 있지만 더 깨끗한 추상화를 제공합니다. 위험한 작업은 항상 명시 적입니다. 고급 기능은 명시 적으로 활성화해야하는 확장을 통해 제공됩니다.
• 셀렌에서 상업적 지원을받을 수 있습니다.

요컨대 기업에서 DVCS를 사용할 때 마찰을 최소화하는 도구를 선택하는 것이 중요하다고 생각합니다. 성공적인 전환을 위해서는 VCS와 관련하여 개발자 간의 다양한 기술을 고려하는 것이 특히 중요합니다.

마찰 감소 :

좋아, 당신은 상황에 정말로 갇혀있는 것처럼 보이기 때문에 두 가지 옵션이 남아 있습니다. git을 덜 복잡하게 만드는 도구는 없습니다. 자식 은 복잡합니다. 이 문제에 직면하거나 git :-

1. 전체 팀을위한 git 입문 과정을 받으십시오. 여기에는 기본 사항과 몇 가지 연습 문제가 포함되어야합니다 (중요!).
2. 마스터 리포지토리를 svn으로 변환하고 "young-stars" git-svn 합니다. 이것은 대부분의 개발자에게 사용하기 쉬운 인터페이스를 제공하고 팀의 부족한 규율을 보완 할 수있는 반면, 젊은 스타는 자신의 저장소에 git을 계속 사용할 수 있습니다.

솔직히 말해서 도구 문제보다는 사람 문제가 정말 있다고 생각합니다. 이 상황을 개선하기 위해 무엇을 할 수 있습니까?

• 현재 프로세스가 유지 관리 가능한 코드베이스로 끝날 것이라고 생각한다는 것을 분명히해야합니다.
• 지속적인 통합에 시간을 투자하십시오. 위에서 설명한 것처럼 어떤 종류의 VCS를 사용하든 CI를 대체 할 수 없습니다. 마스터 리포지토리에 쓰레기를 밀어 넣는 사람들이 있다고 말했습니다. 적색 경보가 울리는 동안 쓰레기를 고치도록하고 빌드를 깨뜨린 이유 (또는 품질 메트릭 등을 충족하지 못함)를 비난합니다.

저는 상당히 규모가 큰 개발 조직의 SCM 엔지니어이며 작년에 svn에서 git로 전환했습니다. 중앙 집중식으로 사용합니다.

우리 는 저장소를 호스팅하기 위해 gitosis 를 사용 합니다. git의 분기 단위가 기본적으로 저장소이므로 모 놀리 식 svn 저장소를 여러 개의 작은 git 저장소로 분리했습니다. (그 주위에는 방법이 있지만 어색합니다.) 분기 별 액세스 제어를 원하는 경우 gitolite 가 더 나은 접근 방법 일 수 있습니다. 돈을 쓰고 싶다면 GitHub의 방화벽 내부 버전도 있습니다 . 우리의 목적을 위해 gitosis는 우리 저장소에 대해 꽤 열린 권한이 있기 때문에 괜찮습니다. (우리는 저장소 그룹에 대한 쓰기 권한이있는 사람들 그룹이 있고 모든 사람이 모든 저장소에 대한 읽기 권한을 가지고 있습니다.) 우리는 웹 인터페이스에 gitweb을 사용합니다.

몇 가지 구체적인 우려 사항은 다음과 같습니다.

• 병합 : 선택한 시각적 병합 도구를 사용할 수 있습니다. 설정 방법에 대한 지침이 여러 곳에 있습니다. 병합을 수행하고 로컬 리포지토리에서 유효성을 완전히 확인할 수 있다는 사실은 제 생각에는 git에 대한 주요 장점입니다. 푸시하기 전에 병합을 확인할 수 있습니다.
• GUIs : TortoiseGit을 사용하는 사람이 몇 명 있지만 실제로 권장하지는 않습니다. 명령 줄과 이상한 방식으로 상호 작용하는 것 같습니다. 나는 이것이 개선이 필요한 영역이라는 것에 동의해야합니다. (즉, 나는 일반적으로 버전 제어를위한 GUI의 팬이 아닙니다.)
• 소그룹 추적 브랜치 : gitolite와 같이 더 세분화 된 ACL을 제공하는 것을 사용하는 경우이를 수행하는 것은 간단하지만 다양한 개발자의 로컬 리포지토리를 연결하여 공유 브랜치를 생성 할 수도 있습니다. git 리포지토리는 여러 원격을 가질 수 있습니다.

원격 개발자가 많고 Subversion에 문제가 많았 기 때문에 git로 전환했습니다. 우리는 여전히 워크 플로를 실험하고 있지만 현재는 기본적으로 Subversion을 사용하는 것과 동일한 방식으로 사용합니다. 우리가 좋아하는 또 다른 점은 코드 검토를위한 스테이징 리포지토리 사용 및 소규모 그룹 간의 코드 공유와 같은 다른 가능한 워크 플로를 열었다는 것입니다. 또한 리포지토리 생성이 매우 쉽기 때문에 많은 사람들이 개인 스크립트 등을 추적하기 시작하도록 권장합니다.

네, 알아요, Linus는 그것을 의도하지 않았습니다.

실제로 Linus는 중앙 집중식 시스템이 작동하지 않는다고 주장합니다.

그리고 독재자-중위 주의자 워크 플로우에 어떤 문제가 있습니까?

git은 분산 시스템입니다. 중앙처럼 사용하려고하지 마십시오.

(업데이트 됨)

git을 "svn on steroids"인 것처럼 사용하지 않으면 대부분의 문제는 사라질 것입니다 (그렇지 않기 때문입니다).

베어 저장소를 모든 사람이 푸시 할 수있는 중앙 서버로 사용하는 대신 병합을 처리하는 몇 가지 통합 관리자를 설정하여 자신 만 베어 저장소로 푸시 할 수 있도록합니다.

일반적으로 이러한 사람들은 팀 리더 여야합니다. 각 리더는 자신의 팀 작업을 통합하여 축복받은 저장소로 푸시합니다.

더 좋은 점은 다른 누군가 (예 : 독재자)가 팀 리더로부터 가져와 변경 사항을 축복받은 저장소에 통합한다는 것입니다.

워크 플로우에 문제는 없지만, 우리는 과로 한 스타트 업이며 인간의 시간과 관심을 대신 할 도구가 필요합니다. 자비로운 독재자는 말할 것도없고 코드 검토조차 할 수있는 대역폭이있는 사람은 없습니다.

통합자가 코드를 검토 할 시간이 없더라도 괜찮지 만 모든 사람의 병합을 통합하는 사람이 있어야합니다.

git pulls를 수행하는 데 많은 시간이 걸리지 않습니다.

git pull A
git pull B
git pull C

git 은 인간의 시간과 관심을 대신합니다. 그것이 처음에 쓰여진 이유입니다.

• GUI 도구는 성숙하지 않았습니다.

GUI 도구는 기본적인 것들을 잘 처리 할 수 ​​있습니다.

고급 작업에는 코더 / 너디 마인드가 필요합니다 (예 : 명령 줄에서 작업하는 것이 편안합니다). 개념을 이해하는 데 약간의 시간이 걸리지 만 그렇게 어렵지는 않습니다.

• 명령 줄 도구를 사용하면 병합을 망칠 수 있고 다른 사람의 변경 사항을 지울 수 있습니다.

"중앙 저장소"에 대한 전체 쓰기 권한을 가진 무능한 개발자가 많지 않으면 문제가되지 않습니다.

그러나 소수의 사람 (통합 자) 만 "축복 된"저장소에 작성하도록 워크 플로를 설정하면 문제가되지 않습니다.

Git은 병합을 쉽게 망칠 수 없습니다.

병합 충돌이 발생하면 git은 충돌하는 줄을 명확하게 표시하여 어떤 변경 사항이 자신의 것인지 아닌지 알 수 있습니다.

svn 또는 다른 (비 분산) 도구를 사용하여 다른 사람의 코드를 제거하는 것도 쉽습니다. 사실, 이러한 다른 도구를 사용하는 것이 훨씬 쉽습니다. 오랜 시간 동안 "변경 사항을 반영"하는 경향이 있고 어느 시점에서 병합이 끔찍하게 어려울 수 있기 때문입니다.

그리고 이러한 도구는 병합하는 방법을 모르기 때문에 항상 수동으로 병합해야합니다. 예를 들어, 누군가 로컬에서 편집중인 파일을 커밋하면 수동으로 해결해야하는 충돌로 표시됩니다. 이제 그것은 유지 관리의 악몽입니다.

git을 사용하면 git이 실제로 병합 할 수 있기 때문에 대부분의 경우 병합 충돌이 발생하지 않습니다. 충돌이 발생하는 경우 git은 라인을 명확하게 표시하여 자신의 변경 사항과 다른 사람의 변경 사항을 정확히 알 수 있습니다.

누군가가 병합 충돌을 해결하는 동안 다른 사람의 변경 사항을 지우면 실수가 아닙니다. 충돌 해결에 필요했기 때문이거나 그들이 무엇을하는지 모르기 때문입니다.

• 전역 읽기 전용 또는 읽기-쓰기 권한 이상의 사용자 별 저장소 권한을 제공하지 않습니다.

• 저장소의 모든 부분에 대한 권한이있는 경우 저장소의 모든 부분에 대해 동일한 작업을 수행 할 수 있으므로 다른 사람이 할 수없는 중앙 서버에 소규모 그룹 추적 분기를 만드는 것과 같은 작업을 수행 할 수 없습니다. 엉망입니다.

• "무엇이든 간다"또는 "자비로운 독재자"이외의 워크 플로우는 시행은 말할 것도없고 장려하기 어렵습니다.

이러한 문제는 중앙 집중식 시스템 인 것처럼 git 사용을 중단하면 사라집니다.

• 하나의 큰 저장소 (모든 사람이 모든 것을 엉망으로 만들 수 있음)를 사용하는 것이 더 나은지 또는 많은 구성 요소 별 저장소 (버전 동기화를 시도하는 데 골칫거리가 됨)를 사용하는 것이 더 나은지 여부는 명확하지 않습니다.

심판 호출.

어떤 종류의 프로젝트가 있습니까?

예를 들어, 프로젝트 A의 버전 xy는 프로젝트 B의 정확히 버전 wz에 의존하므로 프로젝트 A의 xy를 확인할 때마다 프로젝트 B의 wz도 체크 아웃해야합니다. 그렇지 않으면 빌드되지 않습니까? 그렇다면 프로젝트 A와 프로젝트 B는 모두 단일 프로젝트의 두 부분이기 때문에 동일한 저장소에 둘 것입니다.

여기서 가장 좋은 방법은 뇌 를 사용하는 것입니다.

• 여러 저장소를 사용하는 경우 다른 사람이 중앙 저장소에서 가져 와서 가지고있는 모든 소스를 복제하거나 어제 오후 4시 30 분에 모든 것을 가져 오는 것과 같은 작업을 수행하는 방법도 명확하지 않습니다.

무슨 말인지 잘 모르겠습니다.

기업 작업에는 http://code.google.com/p/gerrit/ 를 적극 권장 합니다. 액세스 제어와 기본 제공 검토 기반 워크 플로를 제공합니다. 모든 LDAP 시스템에 대해 인증합니다. http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin 을 사용하여 Hudson에 연결할 수 있으므로 아직 검토중인 변경 사항을 빌드하고 테스트 할 수 있습니다. 정말 인상적인 설정입니다.

gerrit을 사용하기로 결정한 경우 일부 오픈 소스 사용자와 같은 분기 형 역사가 아닌 매우 선형적인 역사를 유지하는 것이 좋습니다. Gerrit는 이것을 "빨리 감기 변경 만 허용"이라고 표현합니다. 그런 다음 릴리스 등을 위해 익숙한 방식으로 분기 및 병합을 사용할 수 있습니다.

저는 2010 년에 Git을 채택한 대규모 통신사에서 개발자 관리자로서의 경험을 바탕으로이 질문에 답하고 있습니다.

여기에는 매우 다른 문제가 있습니다.

• 워크 플로우
• 클라이언트 도구
• 서버 액세스 제어 및 통합

워크 플로우

우리는 중앙 저장소 모드를 성공적으로 채택했습니다. 엔터프라이즈 프로젝트 (500 만 사용자 기반의 대규모 포털)에있는 것은 공식 빌드를 생성 한 다음 전달 프로세스를 통해 가져 오는 사실상의 중앙 저장소입니다. 세 가지 수준의 테스트와 두 가지 배포로 구성됩니다. 모든 개발자는 자신의 저장소를 관리하며, 우리는 기능별로 분기하여 작업합니다.

클라이언트 도구

이제 몇 가지 옵션을 사용할 수 있습니다. 이것은 이제 매우 혼잡 한 지역입니다. 많은 개발자가 IntelliJ Idea 및 Eclipse를 다른 요소없이 Git 플러그인과 함께 성공적으로 사용 하고 있습니다. 또한 대부분의 Linux 개발자는 문제없이 CLI git 클라이언트를 사용하고 있습니다. 일부 Mac 개발자는 Tower Git을 성공적으로 사용하고 있습니다 . 점에 유의하여 주시기 바랍니다 이러한 클라이언트의 아무도를 중앙 저장소와 "엉망"로 사용자를 방지 할 수 있습니다 : 서버 측 제어 mechamism이 필요하다

서버 액세스 제어 및 통합

개발자가 Git 저장소를 "혼란"하는 것을 방지하려면 다음과 같은 솔루션을 선택해야합니다.

• 모든 작업을 수행 할 수있는 적절한 웹 관리 인터페이스를 제공합니다.
• 사용자 ID를 적용 할 수 있습니다 ( "베어"Git 저장소를 사용하는 것은 다른 사람을 대신하여 커밋하는 것이 매우 쉽습니다).
• 세분화 된 보안을 제공합니다 (예를 들어 FORCE-PUSH를 방지하고 일부 개발자 / 그룹에 대해 읽기 전용으로 일부 분기를 설정할 수 있음).
• 기업 인증 시스템 (예 : LDAP, Windows ActiveDirectory)과 통합
• 전체 감사를 제공합니다 (SOX 준수는 때때로 대기업의 경우 매우 중요 함).

이를 도울 수있는 바로 사용할 수있는 서버 측 솔루션은 많지 않습니다. 다음 중 하나를 확인하는 것이 좋습니다.

• Gitorious : 기본적인 액세스 수준 보안을 제공 할 수 있지만 기본적으로 세분화 된 권한 제어가 부족하므로 분기 수준 권한과 같은 시나리오를 처리하기 위해 약간의 코딩을해야 할 것입니다. 또한 기존 기업 인증 메커니즘과의 통합이 부족합니다.
• GitHub Enterprise : 최근 GitHub에서 게시했으며 회사에서 GitHub를 제공합니다. SOX 준수와 세분화 된 보안이 부족합니다.
• Gerrit : 세분화 된 액세스 수준 보안 및 기업 인증 시스템과의 통합을 제공 할 수 있지만 SOX 준수 및 SSO가 부족합니다. 또한 일부 작업은 CLI를 통해 SSH를 통해서만 수행 할 수 있습니다.
• GitEnterprise : 분기 수준 권한, SSO, SOX 준수, 전체 웹 기반 관리를 제공합니다. 최근 Gerrit와 통합되어 전체 Gerrit 인스턴스도 제공합니다.

도움이 되었기를 바랍니다!

문제는 워크 플로를 결정하지 않았거나 도입하지 않은 것 같습니다. Git은 svn 또는 다른 VCS처럼 사용할 수있을만큼 유연하지만 너무 강력해서 모두가 따라야하는 규칙을 설정하지 않으면 엉망으로 끝날 것입니다. 나는 누군가가 위에서 언급했지만 Vincent Driessen이 설명한 분기 모델과 결합 된 독재자-중위 자 워크 플로우를 권장합니다 . 자세한 내용 은 David Bock의 스크린 캐스트 와 Mark Derricutt의 스크린 캐스트 를 참조하십시오 .

온 도구 , 맥 OS-X 사용자는 GitX (http://gitx.frim.nl/) 매우 간단하고 효과적인를 찾을 수 있습니다. 단점은 Git 클라이언트 후크 ($ GIT_ROOT / .git / hooks 아래의 후크)를 지원하지 않는다는 것입니다.

전반적으로 저는 다음 과 같은 세분화 된 액세스 제어 를 지원하는 도구를 강력하게 선택했습니다 .-브랜치 (더 민첩성과 유연성이 필요한 토픽 브랜치에서 엄격한 보안을 사용하는 안정적인 릴리스 브랜치를 분리하기 위해)-ID 적용 (작성자 / 커미터 ). 이것은 SOX의 KEY -git 명령 제한-audit-trail입니다. SOX의 KEY입니다

이러한 기능으로 성공적으로 사용한 기능은 다음과 같습니다.

1. Gerrit 코드 검토 (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. CollabNet TeamForge (http://www.collab.net/gotgit)는 백그라운드에서 Gerrit 2.1.8을 사용합니다.

추신 : SOX 및 CMMI 준수를 과소 평가하지 마십시오 . 보안에 대한 회사 엔터프라이즈 정책에 따라 제한적으로 선택해야하는 경우가 많습니다.

도움이 되었기를 바랍니다.

루카.

최근에 svn에서 git로 전환했습니다. git-daemon은 msysgit에서 작동하지 않기 때문에 gitosis가있는 Linux 서버에서 중앙 저장소 접근 방식을 선택했습니다.

마스터를 망칠 가능성을 없애기 위해 우리는 그것을 간단히 설명했습니다. 대신 테스트를 위해 선택된 분기를 병합하고 병합에 태그를 지정하여 모든 릴리스를 준비합니다. 테스트를 통과하면 커밋에 버전 태그가 지정되고 프로덕션에 배치됩니다.

이를 처리하기 위해 릴리스 관리자의 순환 역할이 있습니다. 릴리스 관리자는 테스트 준비가되기 전에 각 분기를 검토 할 책임이 있습니다. 그런 다음 제품 소유자가 새 테스트 릴리스를 위해 승인 된 분기를 함께 번들링 할 때라고 결정하면 릴리스 관리자가 병합을 수행합니다.

우리는 또한 2 단계 헬프 데스크의 순환 적 역할을 가지고 있으며 적어도 우리에게 워크로드는 동시에 두 역할을 가질 수 있습니다.

마스터가 없다는 이점으로 릴리스 관리자를 통하지 않고는 프로젝트에 코드를 추가 할 수 없으므로 이전에 프로젝트에 자동으로 추가 된 코드의 양을 직접 발견했습니다.

검토 프로세스는 브랜치 소유자가 검토 보드에 diff를 제출하고 "검토 용"아래에 브랜치 이름 (Kanban 기반 워크 플로가 있음) 또는 완료된 사용자의 일부인 경우 화이트 보드에 녹색 포스트잇을 올리는 것으로 시작됩니다. 이야기, 전체 이야기 카드를 "검토 용"으로 옮기고 그 위에 포스트잇을 붙입니다. 릴리스 관리자는 카드와 포스트잇을 "테스트 준비"상태로 옮기고 제품 소유자는 다음 테스트 릴리스에 포함 할 카드를 선택할 수 있습니다.

병합을 수행 할 때 릴리스 관리자는 또한 병합 커밋에 제품 소유자의 변경 로그에서 사용할 수있는 적절한 커밋 메시지가 있는지 확인합니다.

릴리스가 프로덕션에 배치되면 태그가 브랜치의 새 기반으로 사용되며 기존 브랜치가 모두 병합됩니다. 이렇게하면 모든 분기에 공통 부모가있어 병합을 더 쉽게 처리 할 수 ​​있습니다.

나는 또한 "당신이 고려한"포스트를 추가 할 것입니다.

Bazaar의 가장 큰 장점 중 하나는 유연성입니다. 이것은 다른 모든 분산 시스템을 능가하는 곳입니다. Bazaar를 중앙 집중식 모드, 분산 모드로 작동하거나 둘 다 얻을 수 있습니다 (즉, 개발자는 자신에게 익숙한 모델이나 작업 그룹에 가장 적합한 모델을 선택할 수 있음). 이동 중에 중앙 저장소의 연결을 끊고 돌아올 때 다시 연결할 수도 있습니다.

그 외에도 훌륭한 문서와 기업을 행복하게 만드는 것 : 상업적 지원이 가능합니다.

• Github FI 와 같은 괜찮은 웹 인터페이스 설치
• 사람들을 편안하게 유지하려면 상대적으로 중앙 집중화 된 모델 (처음에는)을 고수하십시오.
• 모든 공유 브랜치에 대해 지속적 통합 빌드를 실행하십시오 .
• 좋은 글로벌 git 구성 옵션 세트를 공유하십시오.
• bash 완료 및 현재 브랜치의 프롬프트를 사용하여 git을 쉘에 통합하십시오.
• 병합 도구로 IntelliJ의 Git 통합을 사용해보십시오.
• .gitignore가 적절한 지 확인하십시오.

3 번과 4 번 지점 (사용자 별, 섹션 별, 분기 별 권한)과 관련하여 gitolite (Pro Git 책 : http://progit.org/book/ch4-8.html )를 살펴보십시오 .

정치 여부에 관계없이 Git은 DCVS를 선택하는 데 적합합니다. 다른 강력한 도구와 마찬가지로 도구가 작동하도록 설계되는 방식을 이해하는 데 약간의 시간을 할애 할 가치가 있으며이를 위해 Pro Git 책을 적극 권장합니다. 그것으로 몇 시간을 보내면 장기적으로 많은 좌절감을 줄일 수 있습니다.

GUI : 현재 TortoiseGit v1.7.6은 대부분의 일상적인 작업에 적합합니다. Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodule 등 ... 기본적으로 x64 지원

개발자가 많은 개발팀에서 git을 효율적으로 사용하기 위해서는 지속적으로 구축하고 테스트하는 CI 시스템이 필요합니다. Jenkins는 이러한 차량을 제공하며이를 적극 권장합니다. 통합 부분은 무엇이든 상관없이 수행되어야하며 더 빠르고 자주 수행하는 것이 훨씬 저렴합니다.

gitosis 또는 gitolite보다 협업 개발에 더 적합하지만 오픈 소스는 Gitorious 입니다. 저장소 관리 및 병합을 처리하는 Ruby on Rails 애플리케이션입니다. 많은 문제를 해결해야합니다.

Git을 사용하면 비공개 브랜치를 만들 수 있습니다. 이것은 개발자가 수정을 작은 커밋으로 나누기 위해 자주 커밋하도록 권장합니다. 개발자가 변경 사항을 게시 할 준비가되면 중앙 서버로 푸시합니다. 필요한 경우 사전 커밋 스크립트를 사용하여 코드를 확인할 수 있습니다.

NXP는 하나의 공통 플랫폼 (엔터프라이즈 규모)으로 Git 및 Subversion을 관리하고 Android 모바일 개발을 기존 소프트웨어 프로젝트와 통합합니다. http://www.youtube.com/watch?v=QX5wn0igv7Q