예를 들어, 저는 사용자의 이름, 정보 등을 제공하는 feature/user
사용자 관리 모듈을 개발 중이고, 제 동료는 로그인 가능 여부를 감지하기 위해 제 사용자 모듈이 필요한 feature/login
로그인 시스템을 개발 중입니다. 사용자 정보 등을 얻습니다.
질문 1:
사용자 시스템이 완성됐다고 가정하고, 동료들에게 어떻게 사용하게 해줄 수 있을까요?
먼저 finish
라고 말하고, 그 다음 동료 finish
, 그 다음 동료 start
라고 해야 할까요? 별로 현실적이지 않습니다.
질문 2:
내가 사용자 시스템을 완성하지 않았지만 동료가 필요로 하는 것을 완성했다면 어떻게 동료가 사용하게 할 수 있을까요?
내가 finish
먼저, 동료들이 finish
다음으로, 나와 동료들이 start
따로 개발을 이어가는 것은 아닐까?
이런 문제에 대한 좋은 해결책이 있나요?
보충: 우선 시간이 너무 빡빡하다는 게 주된 이유다. 한 사람이 절대 못 쓸 것이기 때문에 여러 사람이 함께 작업해야 하는데, 의존성 문제가 생기기 마련이다. 그렇다면 이 문제를 어떻게 해결해야 할지 궁금합니다.
동일한 엔지니어링 프로젝트에서 개발 중인지 언급하지 않았으므로 여기서는 동일한 프로젝트에서 작업 중이라고 가정하겠습니다. 설명하기 전에 다음 사항을 살펴보시기 바랍니다. 명확하게 알아두세요 :
Git 노드는 P2P 방식입니다.
Git은 ssh, http, 파일 및 기타 프로토콜을 지원합니다
내 제안:
John과 Jane이 같은 프로젝트에서 협력한다고 가정해 보겠습니다.
으아아아John이 자신의 개인 디렉터리에 있는 프로젝트 데모를 만듭니다.
으아아아Jane이 John과 동일한 개발 시스템을 사용하는 경우 John의 코드를 집에서 직접 복제할 수 있습니다.
으아아아 은 원본 소스의 모든 업데이트를 자신의 코드로 직접 가져올 수 있습니다.이제 John도 계속 개발할 수 있고 Jane도 계속 개발할 수 있으며 둘 다 계속 제출할 수 있습니다.
으아아아
이제 John과 Jane은 서로의 코드를 자신의 폴더에 넣어서 행복하게 개발할 수 있습니다.으아아아
이 요구사항은 노동 분업 측면에서 충돌한다고 생각합니다.
모듈은 다른 모듈에 크게 의존하며 기다려야 합니다.
필요 사항을 구체화하세요
사용자 모듈이 완성된 후 제출하면 됩니다
이때 모듈을 분기하고 계속하세요.
동료가 모듈을 분기하고 계속하세요
이것은 표준 절차입니다
지속적 통합이라는 개념이 있습니다. 통합 작업을 일찍 수행할수록 코드에 더 좋습니다.
에이러한 환경에 대처하기 위해 하향으로 확장되는 개념을 참조할 수 있습니다.
이러한 상황에서는 다음 방법을 권장합니다.
으로 병합합니다.feature/user
브랜치에서 새 브랜치를 엽니다.feature/user_login
feature/user
개발이 사용 가능한 단계에 들어가면feature/user_login
가를 직접 테스트할 수 있도록 코드를
feature/user_login
에 병합합니다. >
feature/user_login
이 개발되면feature/user
로 병합하고 마지막으로
finish
feature/user
feature/user_login
를feature/user
의 하위 기능으로 개발하기 위한 것입니다.이렇게 기능이 설계되어 있지 않다면
feature/user
finish
다음에feature/login
를 개발하는 것이 가장 좋습니다.