버전 관리 요약

프로그래머로서 버전 제어를 반드시 사용해야 한다.코드에 문제가 생겼을 때 버전 제어의 장점을 알게 된다.

공구.

자주 사용하는 버전 제어 도구는 다음과 같습니다.

SVN

Git

여기서 나는 버전 제어 도구를 어떻게 사용하는지 서술하지 않고 단지 프로젝트에서 버전 제어에 관한 자신의 경험을 총결하고 싶을 뿐이다.

프로세스

실제 프로젝트에서 코드의 버전 제어는 대략 다음과 같다.

프로젝트 만들기

개발 기능

첫 번째 내부 테스트 버전

N차 내부 테스트 버전

첫 번째 베타 버전

N차 베타 버전

첫 번째 공식 버전

수정 버전 버그

새로운 기능 개발

그중 3~7은 많을 수도 있고, 적을 수도 있으며, 회사 상황에 따라 결정된다.
다음은 SVN을 예로 들어 이 기능을 설명한다.
전제 조건
프로젝트 이름: Chat 3단: Android, IOS, Server

루트 디렉토리 생성

소스 루트 디렉토리는 다음과 같습니다.

|-Chat
    |-trunk
        |-Android
        |-IOS
        |-Server
    |-branches
    |-tag

개발하다

각 측은 첫 번째 안정적인 내측 버전까지 각자의 Trunk 지점에서 개발되었다.

내측

첫 번째 내부 테스트 버전을 발표할 때 다음과 같이 tag 분기 아래에 tag를 추가해야 합니다.

|-Chat
    |-trunk
        |-Android
        |-IOS
        |-Server
    |-branches
    |-tag
        |-Android
            |-inner_test_1.0.0
        |-IOS
            |-inner_test_1.0.0
        |-Server
            |-inner_test_1.0.0

어느 쪽에서 버전을 발표하든지 tag 지점 아래에 tag를 추가해야 합니다.

공개 측량

내측 몇 판 이후 공측을 진행할 수 있으며, 테스트는 Trunk 지점에서 계속 개발된 다음에 공측 버전을 발표할 때 tag 지점에 tag를 추가할 수 있다.다음과 같습니다.

|-Chat
    |-trunk
        |-Android
        |-IOS
        |-Server
    |-branches
    |-tag
        |-Android
            |-inner_test_1.0.0
            |-inner_test_1.0.1
            |-inner_test_1.0.2
            |-public_test_1.0.3
            |-public_test_1.0.4
        |-IOS
            |-inner_test_1.0.0
        |-Server
            |-inner_test_1.0.0

정식판

정식 버전이 발표된 후에 해야 할 일은 다음과 같다.tag 분기 아래에 tag 2.branches 지점에 개발판 지점 추가
다음과 같습니다.

|-Chat
    |-trunk
        |-Android
        |-IOS
        |-Server
    |-branches
        |-Android
            |-BaseDev
    |-tag
        |-Android
            |-inner_test_1.0.0
            |-inner_test_1.0.1
            |-inner_test_1.0.2
            |-public_test_1.0.3
            |-public_test_1.0.4
            |-release_1.0.5
        |-IOS
            |-inner_test_1.0.0
        |-Server
            |-inner_test_1.0.0

BaseDev 지점의 의미는 이 버전에서 이전 버전의 버그 복구 및 단기 교체 작업만 하는 것입니다.

번갈아

교체는 빠른 교체와 긴 주기 교체로 나뉜다.
빠른 교체는 다음과 같습니다.

이전 버전의 버그 수정

기존 기능의 세부적인 최적화

빠른 기능 추가

긴 주기의 교체는 다음과 같다.어떤 기능이 단기간 내에 완성되지 않기 때문에 여러 개의 빠른 교체 버전을 나누어야 한다
빠른 교체에 대해서는 BaseDev 지점에서 개발할 수 있으며, 교체가 끝난 후에 BaseDev를 Trunk 지점으로 업데이트할 수 있습니다.
언제 새로운 지점을 세워야 합니까?

새로운 기능이 다음 릴리즈에서 릴리즈될지 여부가 일시적으로 결정되지 않음

새로운 기능 개발 주기가 길고 여러 버전으로 분리된 후 체험이 좋지 않아 독립적으로 발표할 수 없음

예를 들어Chat 프로젝트에 기능 공간(Space)을 새로 추가하면 이 기능은 빠른 교체에서 완성할 수 없고 개발 주기가 비교적 길 수 있다.이때branches에 지점을 추가해야 합니다.예:

|-Chat
    |-trunk
        |-Android
        |-IOS
        |-Server
    |-branches
        |-Android
            |-BaseDev
            |-Space
    |-tag
        |-Android
            |-inner_test_1.0.0
            |-inner_test_1.0.1
            |-inner_test_1.0.2
            |-public_test_1.0.3
            |-public_test_1.0.4
            |-release_1.0.5
        |-IOS
            |-inner_test_1.0.0
        |-Server
            |-inner_test_1.0.0

맨 마지막에 쓰다

코드를 합병하는 대가가 너무 높기 때문에 가능한 한 지점을 적게 만들어야 한다!!!
코드를 합병하는 대가가 너무 높기 때문에 가능한 한 지점을 적게 만들어야 한다!!!
코드를 합병하는 대가가 너무 높기 때문에 가능한 한 지점을 적게 만들어야 한다!!!

가능한 한 교체 임무를 분리하여 신속하게 교체할 수 있는 임무로 한다.

코드의 컴파일링은 설치 패키지의 버전을 제어하기 위해 자동 컴파일을 사용하는 것이 가장 좋다.예: Jenkins

좋은 방법이 있으면 메모를 남기거나 연락 주세요.연락처 보기
자세한 내용은 내 블로그: DevWiki's Bolg