GIT 저장소의 모듈 식 Java 응용 프로그램

Question

"모듈 식 Java 응용 프로그램"을 개발 중이며, 약 60 개의 독립 모듈이 있습니다. 모두 자체적으로 "빌드 가능"합니다.

GIT에서이 유형의 응용 프로그램을 구조화하는 최선의 방법이 무엇인지 이해하려고합니다.

더 나은 자신을 설명 할 것이다 : SVN과

내가 일한지 몇 년과 나 같은 SVN과 같은 중앙 집중식 버전 관리 도구에서 다음과 같이 프로젝트를 구성하는 것이 정말 쉬운 것입니다 I 동안 GIT 모범 사례와 찬반 양론에 대해 잘 모르겠습니다. SVN으로

:

mod_A 
    |___trunk 
    |___branches 
    | |___branch_A 
    | 
    |___tags 
mod_B 
    |___trunk 
    |___branches 
    | |___branch_A 
    | |___branch_B 
    | 
    |___tags  

또는

을 :이

내가 예를 들어, 내가 유사한 결과로, 두 개의 서로 다른 접근 방식을 고려할 것

같은 저장소에서 모든 프로젝트를 가져올 것

trunk 
    |___mod_a 
    |___mod_b 
    |___mod_c 
branches 
    |___branch_A 
    | |___mod_a 
    |___branch_B 
     |___mod_a 
     |___mod_b 

두 가지 방법을 사용하면 특정 기능을 위해 분기 된 모듈과 같은 정보를 얻는 것이 정말 쉬울 것이고 장래의 모듈뿐만 아니라 미래의 지점에서도 응용 프로그램을 볼 수 있습니다.

또한 두 구조를 사용하면 언제든지 모듈을 여러 개 분기 할 수 있으므로 모듈을 쉽게 분기 할 수 있습니다. GIT와

: 몇 가지 장점을 제공하는 경우에도 그 순간 나는 내 생각이 구조에서, 모든 모듈에 대해 하나의 독립적 인 환매 특약으로 구성되어 함께 일하고 있어요 모듈 응용 프로그램에서

는, 또한이있는 진짜 큰 문제.

실제로 응용 프로그램에 대한 전반적인 개요가 명확하지 않아 모든 단일 저장소에 연결하고 분기를 확인하여 특정 분기에 어떤 모듈이 관련되어 있는지 파악할 수 있으므로, 내 응용 프로그램의 분기 된 버전을 관리 할 수 ​​있습니다. 예를 들어 전체 응용 프로그램이 아닌 특정 BUG_FIXING 또는 FEATURE 분기에서 분기되는 모듈이 7 개만 있으면 GIT를 통해이 정보를 얻을 수있는 방법이 없습니다. 정보를 사용자 정의 방식으로 표시합니다.

그럼 응용 프로그램이 동일한 저장소에 설정되었다고해도 "Git은 개별 저장소가 아닌 전체 저장소에서 작동합니다"라는 모듈의 하위 집합 만 분기 할 것을 결정할 수 없었을 것입니다.

GIT 하위 모듈을 솔루션으로 사용할 수있는 모듈 식 응용 프로그램을 사용하는 최선의 방법은 무엇인지 명확히 설명해주십시오. 내가 고려하지 않은 다른 접근법이 있습니까, 아니면 잘못된 가정에서 이동하고 있습니까?

고맙습니다.

Answer 1

먼저 모든 모듈이 동일한 프로젝트에서 작동하기 때문에 하나의 SVN 저장소에서 관리하는대로 git repo의 모듈 Java 응용 프로그램을 관리해야합니다.당신이 응용 프로그램에 대한 분기 모듈 구조

, 나는 별도의 지점 (modX)의 각 모듈을 관리 제안 및 master 지점에서 전체 프로젝트를 관리하게됩니다.

작업 흐름은 다음과 같습니다

• 는 master 지점에서 프로젝트 수준의 파일을 관리 할 수 ​​있습니다. 마스터로서 분기위한 구조 :

  Root (master branch) 
      |___... (project level files) 
  

• 지갑 모듈 분기 마스터의 (예컨대 modA 분기 modBmodC 분기 및 분기 등). 프로젝트 레벨 파일을 삭제하고 모듈에 대한 파일을 mod_X 폴더에 추가하십시오. 이러한 지점 MODA 경우와

  는 구조는 다음과 같습니다

  Root (modA branch) 
      |___mod_A (folder) 
        |___... (module A level files) 
  

• 당신이 다음 master 지점에 modX 가지를 병합 모듈 X에 대한 작업을 완료합니다.

  모든 모듈이 작업을 완료 (및 master에 병합) 후

• , master 지점의 파일 구조가 있어야한다 : 당신이 modX 지점에서 모듈 X를 업데이트하는 경우

  Root (master branch) 
      |___... (project level files) 
      |___mod_A (folder) 
        |___... (module A level files) 
      |___mod_B (folder) 
        |___... (module B level files) 
      |___mod_C (folder) 
        |___... (module C level files) 
  

• 가, 다시 modX 분기를 병합 master 분기로 이동하여 응용 프로그램이 업데이트되었는지 확인하십시오. 자바 응용 프로그램의 생산 버전으로

  1. master 지점 :

  2. 는 또한 develop, feature 및 hotfix 나뭇 가지에/테스트/fixbug을 개발할 수, 프로젝트 수준 (응용 프로그램 애그리 게이터 (aggregator)) 파일을 유지합니다.
  3. develop 브랜치 (master 브랜치에서 체크 아웃해야하는 긴 브랜치 브랜치)가 모든 개발자가 작업하기 위해 사용됩니다. 변경된 응용 프로그램이 성공적으로 빌드 (확인)되면 develop 분기를 master으로 병합 할 수 있습니다.
  4. feature 가지가 짧은 살아있는 가지입니다. 애플리케이션의 새로운 기능을 개발해야하는 경우 develop 브랜치 지점에서 체크 아웃 할 수 있습니다. 그리고 기능이 완료되었습니다. develop 분기로 기능 분기를 병합하여 코드를 확인하십시오.
  5. hotfix 브랜치 또한 짧은 브랜치 브랜치입니다. 브랜치에서 버그를 수정할 수 있습니다. 버그가 수정되면 핫픽스 브랜치를 develop 브랜치로 병합하십시오.

  그리고 a successful branching model이 있으며 프로젝트 수준 (응용 프로그램 수집기) 파일 관리를 참조 할 수 있습니다.

Answer 2

기타 : 다른 모듈을 관리하기 위해 분기를 사용하지 마십시오. 지사는 수명이 짧아야하며, 출시 준비가되면 궁극적으로는 마스터와 합병해야합니다.

---

모듈이 "변경/해제"되면 함께 repo 할 수 있습니다. 각각의 모듈이 SVN에서 자신의 트렁크/브랜치 폴더를 가지고 있다는 사실은 그것들이 따로 따로 변한다는 것을 나타내는 것처럼 보입니다.

Java 응용 프로그램에서 maven을 사용하는 경우 하나의 저장소에 다중 모듈 프로젝트로 설정 될 수 있습니다.

별도의 repos를 사용하는 경우 지사 이름을 비슷하게 지정하면 (티켓 번호 또는 feature/ticket-123-more-cow-bells과 같은 번호를 추가 할 수 있음) 특정 기능이 여러 모듈/저장소에 영향을 미친다는 것을 알 수 있습니다.

모듈마다 별도의 repos를 사용한다면 git 하위 모듈을 사용하여 다시 접착 할 수 있지만 그보다 더 많은 해결 방법이 있습니다.

아마도 reading about a few different git branching strategies도 지점에 대한 '생각'을 이해하는 데 도움이됩니다.