기업의 Git 기반 소스 제어 : 제안 된 툴 및 사례?

기업의 Git 기반 소스 제어 : 제안 된 툴 및 사례?

---

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

그러나 지금은 직장에서 의무화되었으며 솔직히 문제가 있습니다.

기본적으로 git은 다양한 능력과 수준의 git 정교함을 가진 개발자 (특히 Perforce 또는 Subversion과 같은 다른 소스 제어 시스템과 비교)와 함께 대규모 (20 + 개발자) 조직의 중앙 집중식 개발에 적합하지 않은 것으로 보입니다. 그런 환경을 목표로합니다. (예, Linus는이를 위해 의도 한 적이 없습니다.)

그러나-정치적 이유로-우리는 git이 우리가하려고하는 일을 짜증나더라도 깃에 붙어 있습니다.

우리가보고있는 것들 중 일부는 다음과 같습니다.

• GUI 도구가 성숙하지 않습니다
• 커맨드 라인 도구를 사용하면 병합을 망쳐 놓고 다른 사람의 변경 사항을 제거하는 것이 훨씬 쉽습니다.
• 글로벌 읽기 전용 또는 읽기 / 쓰기 권한 이외의 사용자 별 저장소 권한을 제공하지 않습니다.
• 리포지토리의 모든 부분에 대한 권한이있는 경우 리포지토리의 모든 부분에 대해 동일한 작업을 수행 할 수 있으므로 중앙 서버에서 다른 사람들이 할 수없는 소규모 그룹 추적 지점을 만드는 것과 같은 작업을 수행 할 수 없습니다 엉망.
• "무엇이든 간다"또는 "자비로운 독재자"이외의 워크 플로우는 권장하기는 어렵지만 장려하기가 어렵습니다.
• 하나의 큰 리포지토리 (모든 사람이 모든 것을 망칠 수있게 함) 또는 많은 구성 요소 별 리포지토리 (버전을 동기화하려고하는 두통을 만드는)를 사용하는 것이 더 나은지 여부는 확실하지 않습니다.
• 여러 리포지토리를 사용하면 중앙 리포지토리에서 다른 사람이 가져 오는 모든 소스를 복제하거나 어제 오후 4시 30 분에 모든 것을 얻는 것과 같은 방법을 명확하게 알 수 없습니다.

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

그러한 상황에 처해 있거나 일반적으로 일부 사람들이 커맨드 라인 팬이 아닌 대규모 조직에서 git을보다 쉽고 생산적으로 사용하기위한 도구, 팁 및 요령이있는 경우-귀하가 가진 것을 듣고 싶습니다. 제안합니다.

BTW, 나는 이미 링크드 인에서이 질문의 버전을 물었고, 실제 답변은 없었지만 많은 "아, 나도 알고 싶다!"

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

내가 일하는 곳에서는 git 이외의 다른 것을 사용할 수 없습니다 . 옵션이 아닙니다. 우리는 그것에 붙어 있습니다. 우리는 1987 년에 사용한 수은, svn, 비트 키퍼, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, 바자, Darcs, 모노톤, 퍼 포스, 화석, AccuRev, CVS 또는 Apple의 훌륭한 ol '프로젝터를 사용할 수 없습니다. 따라서 다른 옵션을 논의하는 것을 환영하지만 git에 대해 이야기하지 않으면 현상금을 얻지 못합니다.

또한 엔터프라이즈에서 git을 사용하는 방법에 대한 실용적인 팁을 찾고 있습니다 . 이 질문의 맨 위에 문제의 전체 세탁 목록을 넣었습니다. 다시 한 번 사람들은 이론에 대해 논의하기를 환영하지만 현상금을 얻으려면 해결책을 제시하십시오.

---

일반적인 견해에 비추어 볼 때, DVCS를 사용하는 것은 매우 유연한 워크 플로를 가능하게하기 때문에 엔터프라이즈 환경에서 이상적인 선택이라고 생각합니다. 먼저 DVCS와 CVCS를 사용하는 방법, 모범 사례, 특히 git에 대해 이야기하겠습니다.

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

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

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

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는 뛰어난 병합 기능을 제공하지만 Continuous Integration을 대신 할 수 는 없습니다 . 이 시점에서도 트렁크 저장소의 CI, 팀 저장소의 CI, Q & A 저장소 등의 유연성이 매우 뛰어납니다.

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

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

• 여전히 Windows에서 다소 미숙 한 지원 (최근에 변경된 경우 수정하십시오) 이제 Windows에는 github windows client , tortoisegit , Atlassian의 SourceTree가 있습니다
• 성숙한 GUI 도구 부족, 일류 시민 vdiff / 병합 도구 통합 없음
• 내부 작업 위에 매우 낮은 추상화 수준의 일관성없는 인터페이스
• svn 사용자를위한 매우 가파른 학습 곡선
• 힘내는 매우 강력하고 역사를 쉽게 수정할 수 있습니다. 무엇을하고 있는지 알지 못하는 경우 매우 위험합니다.
• 상업적 지원 옵션이 없습니다.

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

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

요컨대, 엔터프라이즈에서 DVCS를 사용할 때는 마찰이 가장 적은 도구를 선택하는 것이 중요하다고 생각합니다. 전환이 성공하려면 VCS와 관련하여 개발자 간 다양한 기술을 고려하는 것이 특히 중요합니다.

---

마찰 감소 :

좋아, 당신은 상황에 정말로 붙어있는 것처럼 보이기 때문에 IMHO에는 두 가지 옵션이 있습니다. 자식을 덜 복잡하게 만드는 도구는 없습니다. 자식 은 복잡하다. 이 문제에 직면하거나 git 문제를 해결하십시오.

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

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

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

---

저는 합리적으로 대규모 개발 조직의 SCM 엔지니어이며 작년 한 해 동안 svn에서 git로 변환했습니다. 우리는 그것을 중앙 집중식으로 사용합니다.

리포지토리를 호스팅하기 위해 gitosis 를 사용 합니다. git의 분기 단위가 기본적으로 저장소이기 때문에 모 놀리 식 svn 저장소를 여러 개의 작은 자식 저장소로 나누었습니다. (그 주위에는 여러 가지 방법이 있지만 어색합니다.) 지점 별 액세스 제어를 원한다면 gitolite 가 더 나은 접근 방법 일 수 있습니다. 돈을 쓰는 데 관심이 있다면 GitHub의 방화벽 내부 버전도 있습니다 . 우리의 목적을 위해, 우리는 우리의 저장소에 대해 꽤 개방 된 권한을 가지고 있기 때문에 gitosis가 좋습니다. (우리는 저장소 그룹에 대한 쓰기 권한을 가진 사람 그룹이 있으며 모든 사람이 모든 저장소에 대한 읽기 권한을 갖습니다.) 웹 인터페이스에 gitweb을 사용합니다.

특정 관심사 중 일부는

• 병합 : 선택한 시각적 병합 도구를 사용할 수 있습니다. 다양한 장소에 설치 방법에 대한 지침이 있습니다. 로컬 리포지토리에서 병합을 수행하고 유효성을 완전히 확인할 수 있다는 사실은 내 의견으로는 git의 주요 이점입니다. 아무 것도 누르기 전에 병합을 확인할 수 있습니다.
• GUI : TortoiseGit을 사용하는 사람이 거의 없지만 실제로 권장하지는 않습니다. 명령 줄과 이상한 방식으로 상호 작용하는 것 같습니다. 이것이 개선이 필요한 영역이라는 데 동의해야합니다. (저는 일반적으로 버전 관리를위한 GUI 팬이 아닙니다.)
• 소그룹 추적 브랜치 : gitolite와 같이보다 세밀한 ACL을 제공하는 것을 사용하면이 작업을 수행하는 것이 쉽지만 다양한 개발자의 로컬 리포지토리를 연결하여 공유 브랜치를 만들 수도 있습니다.

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

---

네, 알고 있습니다. Linus는 그것을 위해 그것을 의도하지 않았습니다.

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

그리고 독재자와 중개자 워크 플로에 어떤 문제가 있습니까?

git은 분산 시스템입니다. 중앙 집중식으로 사용하지 마십시오.

(업데이트 됨)

git을 마치 스테로이드에서 "svn"인 것처럼 사용하지 않으면 대부분의 문제는 사라질 것입니다.

베어 리포지토리를 모두가 푸시 (및 잠재적으로 망칠 수있는) 중앙 서버로 사용하는 대신 병합을 처리하는 몇 개의 통합 관리자를 설정하여 베어 리포지토리로 푸시 할 수 있습니다.

일반적으로이 사람들은 팀장이되어야합니다. 각 리더는 자신의 팀 작업을 통합하여이를 축복 된 저장소로 보냅니다.

더 좋은 점은 다른 사람 (예 : 독재자)이 팀 리더를 끌어 내고 변경 사항을 축복받은 저장소에 통합합니다.

이 워크 플로우에는 아무런 문제가 없지만, 우리는 지나치게 일을 시작했으며 인간의 시간과 관심을 대신 할 도구가 필요합니다. 자비로운 독재자는 물론 코드 검토조차 할 수있는 대역폭이 없습니다.

통합자가 코드를 검토 할 시간이 없다면 문제는 없지만 모든 사람의 병합을 통합하는 사람들이 여전히 필요합니다.

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

git pull A
git pull B
git pull C

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

• GUI 도구가 성숙하지 않습니다

GUI 도구는 기본 사항을 잘 처리 할 수 ​​있습니다.

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

• 커맨드 라인 도구를 사용하면 병합을 망쳐 놓고 다른 사람의 변경 사항을 제거하는 것이 훨씬 쉽습니다.

"중앙 리포지토리"에 대한 전체 쓰기 액세스 권한을 가진 많은 무능한 개발자가없는 한 문제가되지 않습니다.

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

힘내는 병합을 망쳐 놓기가 쉽지 않습니다.

병합 충돌이 발생하면 git은 충돌하는 행을 명확하게 표시하여 변경 사항과 변경 사항을 알 수 있습니다.

svn 또는 다른 (비 분배) 도구를 사용하여 다른 사람의 코드를 제거하는 것도 쉽습니다. 사실, 다른 툴을 사용하면 훨씬 쉬워집니다. 오랫동안 "변경 사항에 앉아"경향이 있고 어떤 시점에서는 병합이 끔찍하게 어려울 수 있습니다.

And because these tools don't know how to merge, you end up always having to merge things manually. For example, as soon as someone makes a commit to a file you're editing locally, it will be marked as a conflict that needs to be manually resolved; now that is a maintenance nightmare.

With git, most of the time there won't be any merge conflicts because git can actually merge. In the case where a conflict does occur, git will clearly mark the lines for you so you know exactly which changes are yours and which changes are from other people.

If someone obliterates other people's changes while resolving a merge conflict, it won't be by mistake: it will either be because it was necessary for the conflict resolution, or because they don't know what they're doing.

• It doesn't offer per-user repository permissions beyond global read-only or read-write privileges

• If you have a permission to ANY part of a repository, you can do that same thing to EVERY part of the repository, so you can't do something like make a small-group tracking branch on the central server that other people can't mess with.

• Workflows other than "anything goes" or "benevolent dictator" are hard to encourage, let alone enforce

These problems will go away when you stop trying to use git as if it was a centralized system.

• It's not clear whether it's better to use a single big repository (which lets everybody mess with everything) or lots of per-component repositories (which make for headaches trying to synchronize versions).

Judgment call.

What kind of projects do you have?

For example: does version x.y of project A depend on exactly version w.z of project B such that every time you check x.y of project A you also have to checkout w.z of project B, otherwise it won't build? If so I'd put both project A and project B in the same repository, since they're obviously two parts of a single project.

The best practice here is to use your brain

• With multiple repositories, it's also not clear how to replicate all the sources someone else has by pulling from the central repository, or to do something like get everything as of 4:30 yesterday afternoon.

I'm not sure what you mean.

---

I highly recommend http://code.google.com/p/gerrit/ for enterprise work. It gives you access control plus a built-in review based workflow. It authenticates against any LDAP system. You can hook it up to Hudson with http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin, letting you build and test changes while they're still under review; it's a really impressive setup.

If you decide to use gerrit, I recommend trying to keep a pretty linear history, not a branchy history like some of the open source guys like. Gerrit phrases this as "allow fast-forward changes only." Then you can use branching and merging in more the the way you're used to, for releases and whatnot.

---

I am answering this question based on my experience as developer manager in a large telco, where we adopted Git in 2010

You have quite different set of problems here:

• workflows
• client tools
• server access control and integration

Workflows

We successfully adopted a central repository mode: what we have in our enterprise project (a large portal for a 5 million user base) is a de-facto central repository that produces the official builds then are taken trough the delivery process (which, in our case, is composed of three level of testing and two deployments). Every developer manages his own repo, and we work on a branch-per-feature basis.

Client tools

There are now several options available, this is now a very crowded area. Many developers are successfully using IntelliJ Idea and Eclipse with the Git plugin, without any other stuff. Also most of the Linux developers are using CLI git client, without any problem. Some Mac developers are successfully using Tower Git. Please note that none of these clients can prevent the user to "mess up" with the central repository: a server side control mechamism is needed

Server access control and integration

If you want to avoid developers "messing up" you Git repository, you reall need to choose a solution that:

• exposes a decent web admin interface to do every operation
• allows you to enforce user identities (using a "bare" Git repository is extremely easy to commit in behalf of someone else)
• provides you fine grained security (so that for example you can prevent FORCE-PUSH and set some branches to read only for some developers / groups)
• integrate with your corporate authentication system (i.e. LDAP, Windows ActiveDirectory)
• provides you full audit (SOX compliance is sometimes very important for large corporates)

There are not so many ready-to-use server side solutions that can help this, I suggest you check out one of these:

• Gitorious: it can provide basic access level security, but it lacks fine grained permissions control out of the box, so you will probably have to do some coding to handle scenarios such as branch level permissions. It also lacks integration with existing corporate authentication mechanisms
• GitHub Enterprise: recently published by GitHub, it features GitHub in your corporate. It lacks SOX complianance and fine grained security
• Gerrit: it can provide fine graind access level security and integration with corporate authentication systems but it lacks SOX compliance and SSO. Also some operations can only be done via SSH via CLI
• GitEnterprise: it provides branch level permissions, SSO, SOX compliance, full web based administration. It was recently also integrated with Gerrit, so that it also provides you a full Gerrit instance

Hope this helps!

---

It sounds like your problem is that you haven't decided on or instituted a workflow. Git is flexible enough to use it like svn or any other VCS, but it's so powerful that if you don't establish rules that everybody must follow then you're just gonna end up with a mess. I would recommend the dictator-lieutenant workflow that somebody mentioned above, but combined with the branching model described by Vincent Driessen. For more info see these screencasts by David Bock, and this one by Mark Derricutt.

---

On the tools, MacOS-X users find GitX (http://gitx.frim.nl/) very simple and effective. Drawback is that doesn't support Git Client hooks (the ones under $GIT_ROOT/.git/hooks).

Overall I do strongly to chose a tool that supports fine-grained access control on: - branches (in order to segregate the stable release branches with strict security from the topic-branches that needs more agility and flexibility) - identity enforcement (author / committer). This is KEY for SOX - git commands restrictions - audit-trail. This is KEY for SOX

The ones I've successfully used with those features are:

1. Gerrit Code Review (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. CollabNet TeamForge (http://www.collab.net/gotgit), uses Gerrit 2.1.8 behind the scenes

P.S. Do not underestimate SOX and CMMI compliance: many times there is limited set of choice you have that is dictated by your Company Enterprise Policies on Security.

Hope this helps.

Luca.

---

We recently switched from svn to git. Because git-daemon doesn't work with msysgit we opted for a central repository approach on a Linux server with gitosis.

To eliminate the possibility to screw up master we simply delted it. Instead we prepare all releases by merging the branches that are selected for testing and tag the merge. If it passes tests the commit is tagged with a version and put in production.

To handle this we have a rotating role of release manager. The release manager is responsible for reviewing each branch before it is ready for test. Then when the product ownder decides it is time to bundle the approved branches together for a new test release the release manager perform the merge.

We also have a rotating role of 2'nd level help desk and at least for us the workload is such that it is possible to have both roles at the same time.

As a benefit of not having a master it is not possible to add any code to the project without going through the release manager so we discovered directly how much code that was silently added to the project before.

The review process starts with the branch owner submiting the diff to reviewboard and putting up a green post-it on the whiteboard with the branch name (we have a Kanban based workflow) under "for review", or if it's part of a completed user story, move the entire story card to "for review" and put the postit on that. The relase manager is the one who moves cards and post-its to "ready for test" and then the product owner can select which ones to incled in the next test release.

When doing the merge the release manager also makes sure that the merge commit has a sensible commit message which can be used in the changelog for the product owner.

When a release has been put in production the tag is used as the new base for branches and all existing branches are merged with it. This way all branches has a common parent which makes it easier to handle merges.

---

I'll add in a "have you considered" post too.

One of the great things about Bazaar is its flexibility. This is where it beats all the other distributed systems. You can operate Bazaar in centralized mode, distributed mode, or get this: both (meaning developers can choose which model they're comfortable with or which works best for their workgroup). You can also disconnect a centralized repository while you're on the road and reconnect it when you get back.

On top of that, excellent documentation and something which will make your enterprise happy: commercial support available.

---

• Install a decent web interface, like Github FI
• Stick to a relatively centralized model (initially) to keep people comfortable.
• Run a Continuous Integration build for every shared branch.
• Share a good set of global git config options.
• Integrate git into your shell, with bash completion, and a prompt with the current branch.
• Try IntelliJ's Git Integration as a merge tool.
• Make sure you .gitignore as appropriate.

---

Regarding points 3 & 4 (per-user, per-section, per-branch permissions), have a look at gitolite (covered in the Pro Git book: http://progit.org/book/ch4-8.html).

Politics or not, Git is as good a choice of a DCVS as any. Like any powerful tool, it is worth spending a little bit of time up front in understanding how the tool is designed to work, and, to this end, I highly recommend the Pro Git book. A couple of hours spent with it will save lots of frustration in the long run.

---

GUI: At the moment, TortoiseGit v1.7.6 should be fine for most daily operations. Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodule, etc... Supports x64 natively too

---

In order to use git efficiently in a development team with lots of developers, a CI system that builds and tests continuously is required. Jenkins provides such a vehicle and I highly recommend that. The integration piece has to be done no matter what and it's a lot cheaper doing that earlier and more often.

---

More suited for collabrative development than gitosis or gitolite but open-source is Gitorious. It's a Ruby on Rails application which handles management of repositories and merging. It should solve many of your problems.

---

Git allows to create private branches. This encourage developers to commit often so as to break down modifications into small commits. When the developer is ready to publish his changes, he pushes to central server. He can make use of pre-commit scripts to verify his code if needed.

---

NXP is managing Git and Subversion with one common platform (at enterprise-scale), integrating Android mobile development with traditional software projects: http://www.youtube.com/watch?v=QX5wn0igv7Q

참고 URL : https://stackoverflow.com/questions/2383826/git-based-source-control-in-the-enterprise-suggested-tools-and-practices