버전 관리를 위해 github, 브랜치 및 자동 릴리스를 사용하는 방법은 무엇입니까? [닫은]

나는 지금까지 대부분의 기본 Git / Github 개념을 이해하지만 더 큰 그림을 이해하는 데 여전히 어려움이 있습니다.

이것들은 내가 지금까지 일하게 된 것들입니다.

• 푸시 커밋
• 가지 작업
• 지속적인 통합 시스템 인 Travis CI와 Github 통합
• Travis CI를 통해 마스터 할 모든 커밋마다 자동으로 빌드하고 릴리스에서 Github에 릴리스를 ZIP으로 넣습니다.

그러나 지금까지는 알파 / 베타 버전의 프로젝트에서만 작업 했으므로 아직 버전이 지정된 릴리스는 본 적이 없습니다.

따라서 버전 관리, 별도 버전 유지 관리, 버전 핫픽스 등에 대해 자세히 알고 싶습니다.

다음과 같은 일이 발생하는지 어떻게 확인합니까?

• 다른 버전의 프로젝트 (예 : 버전 1.1.0 및 2.0.0)
• 버전에 핫픽스를 푸시하거나 버전을 1.1.1 또는 2.0.1로 올릴 수있는 기능 등이 있습니다.
• 커밋시 해당 버전을 자동으로 지속적으로 통합 시스템으로 구축하고 성공하면 해당 버전의 릴리스를 게시하십시오.

다음 옵션 중 하나를 의심합니다.

• 모든 버전에 태그를 사용해야합니까? 그렇다면 어떻게 지속적 통합 시스템이 자동으로 릴리스를 구축 할 수 있습니까?
• 모든 버전에 대해 브랜치를 만들어야합니까? 그렇다면 전체 분기를 만들지 않을 것입니다 (1.1 및 2.0 분기와 같이 핫픽스는 해당 분기로 진행됩니다)
• 버전 번호는 어떻게 지정합니까? 버전 번호를 지정하는 구성 파일이 있거나 더 스마트 한 방법이 있습니까? 이 경우 Java 프로젝트가 중요합니다.

git-flow를 봐야 합니다. 훌륭한 (그리고 인기있는) 브랜칭 모델입니다.

힘내 흐름 요약

분기

주위에 영원히 머물 주요 줄기는 develop와 master. master최신 릴리스와 develop최신 "안정된"개발 사본을 보유합니다.

기고자는 다음에서 feature분기를 작성 합니다 ( feature/일반적으로 접두어 사용 ) develop .

$ git checkout -b feature/my-feature develop

및 hotfix분기 ( hotfix/일반적으로 접두사로 ) master:

# hotfix the latest version of master
$ git checkout -b hotfix/hotfix-version-number master

# or hotfix from a specific version
$ git checkout -b hotfix/hotfix-version-number <starting-tag-name>

이 지점은 "일회용"으로, 메인 트렁크로 다시 병합되기 전에 수명이 짧습니다. 그것들은 작은 기능을 캡슐화하기위한 것입니다.

마무리 지점

feature지사 와 함께 기고자가 완료되면 다시 분기로 병합됩니다 develop.

$ git checkout develop
$ git merge --no-ff feature/my-feature
$ git branch -d feature/my-feature

그들은이 완료하면 hotfix지점, 그들은 모두에 백업 병합 master및 develop핫픽스 앞으로 수행 있도록 :

$ git checkout master
$ git merge --no-ff hotfix/hotfix-version-number
$ git checkout develop
$ git merge --no-ff hotfix/hotfix-version-number
$ git branch -d hotfix/hotfix-version-number

이것이 지속적인 통합 측면입니다.

자료

릴리스 패키징을 시작할 준비가되면 release"안정된" develop브랜치에서 브랜치를 작성하십시오 ( feature브랜치 작성과 동일 ). 그런 다음 태그에 버전 번호를 표시합니다 (아래 설명 참조).

별도의 release분기를 사용하면 develop버그를 수정하고 release분기에 마무리 작업을 추가하는 동안 새로운 기능을 계속 개발할 수 있습니다 .

릴리스를 완료 할 준비가되면 모든 변경 사항이 적용되도록 release분기를 둘 다 ( master와 develop마찬가지로 hotfix) 로 병합하십시오 .

태깅

release분기 또는 분기 를 만들면 hotfix태그에서 버전 번호가 적절하게 충돌합니다. 바닐라 git를 사용하면 다음과 같습니다.

$ git tag -a <tag-name> -m <tag-description>

그런 다음 태그를 원격 저장소에 별도로 푸시해야합니다.

$ git push --tags

일반적으로 버전이 형식을 취하는 시맨틱 버전 관리 를 사용하는 것이 가장 좋습니다 major.minor.hotfix. 주요 범프는 이전 버전과 호환되지 않는 반면, 부 범프 및 핫픽스 범프는 이전 버전과 호환되지 않습니다 (베타가 아닌 한 0.x.x).

합병

위에서 본 것처럼 git-flow는 다음 명령으로 브랜치를 병합하도록 권장합니다.

$ git merge --no-ff <branch-name>

이 --no-ff옵션을 사용하면 리포지토리의 현재 커밋에 여러 가지 브랜치를 남기지 않고 모든 브랜치 히스토리를 유지할 수 있습니다 (걱정하지 않아도 모든 버전에 브랜치가 생길 염려가 없습니다).

당신은 또한 함께하는 것이 좋습니다

$ git pull --rebase

따라서 쓸모없는 병합 커밋을 많이 추가하지 않습니다.

git에서 기본적으로이 두 가지 작업을 모두 수행하도록 구성 할 수 있습니다 .gitconfig. 나는 당신이 하나를 찾아 보자.)

브라우징 버전

누군가 특정 버전의 코드베이스를 찾으려면 이름으로 태그를 체크 아웃 할 수 있습니다.

# checkout in detached HEAD to browse
$ git checkout <tag-name>

# OR checkout and create a new local branch (as you might for a hotfix)
$ git checkout -b <new-branch-name> <tag-name>

또는 누군가가 github에서 탐색하는 경우 "분기"드롭 다운에 "태그"탭도 있습니다.

git-flow 확장 사용 (권장)

이 모델을 사용하는 가장 좋아하는 방법은 git 의 git flow extension 을 사용하는 것 입니다.

( 편집 : Louis는 AVH 포크 를 권장하며 git describe현재 더 잘 작동 하고 더 활동적입니다. 감사합니다. Louis

확장 기능은 merge --no-ff병합 후 분기 사용 및 삭제와 같은 모든 지저분한 부분을 자동화 하여 인생을 살아갈 수 있습니다.

예를 들어, 확장을 사용하여 다음과 같이 기능 분기를 작성할 수 있습니다.

$ git flow feature start my-feature-name

그렇게 마무리

$ git flow feature finish my-feature-name

핫픽스 및 릴리스에 대한 명령은 다음과 같이 분기 이름 대신 버전 번호를 사용하지만 비슷합니다.

# Create hotfix number 14 for this minor version.
$ git flow hotfix start 2.4.14

# Create the next release
$ git flow release start 2.5.0

Git flow는 버전 태그를 생성하고 구성 또는 매니페스트 파일 (grunt와 같은 작업 관리자로 수행 할 수 있음)에서 버전을 충돌 시킨다는 점을 친절하게 상기시켜줍니다.

희망이 도움이 되길 바랍니다 :) 어떻게 Travis CI 설정과 어떻게 통합 할 지 잘 모르겠지만 githooks가 당신을 거기에 데려다 줄 것입니다.

모든 버전에 태그를 사용해야합니까?

아니요, 태그를 전혀 사용할 필요 가 없습니다 . 모든 릴리스에 태그를 지정하고 싶거나 CI 시스템이 구축 될 때마다 태그를 지정하려는 경우에도 그렇게 할 수 있습니다. 태그는 본질적으로 커밋에 사용자에게 친숙한 이름을 지정하므로 쉽게 가져 와서 나중에 볼 수 있습니다.

모든 버전에 대해 브랜치를 만들어야합니까?

확실한! Git에서는 브랜칭이 저렴하고 무료이므로 기회가있을 때마다 활용합니다. 분기를 합병하고 상당히 빠르게 삭제할 수도 있습니다. 많은 브랜치가 필요하다고 생각되면 나중에 선택적으로 병합하여 분기 할 수 있습니다. 시도되고 진정한 구성표를 사용하려는 경우 Git 분기 구성표가 많이 있습니다.

버전 번호는 어떻게 지정합니까?

태그는 일반적으로 git과 관련된 버전 번호를 지정하는 방법입니다. 프로젝트 버전을 지정하는 방법이나 가장 좋은 방법에 대해 이야기하고 있다면 상당히 의견 기반의 질문이므로 파고 들어야합니다. 일부 프로젝트는 영원히 베타 버전으로 유지되고, 다른 프로젝트는 스타일에서 벗어나는 것처럼 정수 버전을 증가시킵니다 (크롬을 보면서).

모든 버전에 태그를 사용해야합니까?

"버전"이란 릴리스 또는 릴리스 후보를 구성하는 파일 세트를 의미하는 경우 모든 버전에 태그를 지정하는 것이 좋습니다. 길을 따라 버전 1.2.7을 참조 해야하는 경우 커밋의 해시를 찾거나 버전 번호를 사용 하시겠습니까?

또한 git describe빌드 정보를 어딘가에 기록하는 데 사용하면 태그를 사용하면 더 좋은 결과를 얻을 수 있습니다.

그렇다면 어떻게 지속적 통합 시스템이 자동으로 릴리스를 구축 할 수 있습니까?

지속적인 통합 시스템은 태그 사용 방법에 관계없이 릴리스를 빌드 할 수 있습니다. 커밋의 해시를 기반으로 릴리스를 빌드하도록 지시 할 수 있습니다. 태그는 인생을 더 쉽게 만듭니다.

모든 버전에 대해 브랜치를 만들어야합니까? 그렇다면 전체 분기를 만들지 않을 것입니다 (1.1 및 2.0 분기와 같이 핫픽스는 해당 분기로 진행됩니다)

분기가 "버전 별"인 것으로 보지 않습니다. 내 버전이 모두 master지점에서 커밋되는 몇 가지 프로젝트가 있습니다. 어느 프로젝트도 안정적인 단계에 있지 않고 이전 버전을 장기간 지원할 필요가 없기 때문에 지금 보다 더 복잡한 것은 필요하지 않습니다 . 그러나 1.0, 1.1, 1.2를 릴리스 한 다음 2.0을 릴리스한다고 가정하고 보안 수정 등으로 1.0 시리즈를 지원해야한다고 가정 해 보겠습니다. 그런 다음 1.x 시리즈의 유지 보수 릴리스를 배치 할 지점이 있어야합니다. .

버전 번호는 어떻게 지정합니까? 버전 번호를 지정하는 구성 파일이 있거나 더 스마트 한 방법이 있습니까? 이 경우 Java 프로젝트가 중요합니다.

구성 파일과 같이 버전 번호에 대한 단일 소스를 갖는 것이 여러 위치에서 숫자를 업데이트해야 할 경우 발생할 수있는 팻 핑거 오류를 방지하는 가장 좋은 방법입니다. 나는 ... 음 ... 창피한 경험에서 말하고 있습니다. 소프트웨어가 여전히 버전 1.2임을보고하기 위해 1.3 만 릴리스합니다. 죄송합니다!

다른 대답으로, mxdubois는 gitflow를 추천했습니다. gitflow를 사용하기로 결정한 경우 AVH 버전을 사용하는 것이 좋습니다 . 원본 버전은 더 이상 적극적으로 유지 관리되지 않습니다. 한 가지 주목할만한 차이점은 AVH 버전이 git describe지능적으로 작동 할 수 있도록 릴리스 병합을 수행한다는 것입니다. 원래 버전은 트립git describe 되는 방식으로 병합을 수행합니다 .

목록을 스캔하면 버전 이 귀하의 초점으로 간주되므로

버전을 유지하는 한 가지 방법은 브랜치 및 병합 (또는 리베이스)입니다.

그래서 당신은 :

master

그런 다음 지점을 만듭니다

v1

그런 다음 더 많은 변경 사항을 추가

master(diff1)

그런 다음 지점을 만듭니다

v3

그런 다음 더 많은 변경 사항을 추가

master(diff2)

지금:

버전 2를 업데이트하려면 이제

git checkout v2
git merge master  # for the changes you want to bring into version 2
# rebasing is also an option
# resolve any merge conflicts
# Done.

버전 3을 업데이트하려면

git checkout v3
git merge master

위의 도매 업데이트입니다.

아마도 특정 변경 사항을 선택하고 싶을 것입니다.

git cherry-pick

체리 따기에 대한 자세한 내용은 http://git-scm.com/docs/git-cherry-pick에서 확인하십시오.