Gitflow auxiliary branches - Gitflow와 보조 브랜치

hyperskill - Gitflow auxiliary branches 영어 원문

gitflow를 설치하고, 당신의 gitflow repo를 생성 한 후, 브랜치에서 프로젝트의 개발을 시작 할 수 있습니다.

하지만, 이러한 프로세스는 보이는 것처럼 쉽지 않습니다. :

프로젝트는 다중 버전을 가질 것이며, 심지어 더 많은 버그를 가지고 있을 겁니다.

이를 다루기 위해서, 우리는 gitflow 구조 내부에 보조적인 브랜치들을 포함 할 필요가 있습니다.

이는 새로운 프로젝트의 변형을 위해, 에러를 작업하기 위해, 새로운 버전을 릴리징 (출시) 하기 위함입니다.

Auxiliary branches - 보조 브랜치

---

작업하는 동안, 당신은 develop 브랜치에 기반한 feature (기능) 이라 불리는 브랜치를 생성 할 수 있습니다.

이에 대해 제한 없이 생성할 수 있습니다.

이러한 브랜치들은 현재, 혹은 미래 릴리즈에 나타나야 할 새로운 기능들을 개발 하는 데에 사용됩니다.

이러한 브랜치들은 보조적이기 때문에, 제한된 수명을 가지고 있습니다.

feature (기능) 제작이 완료되었을 때, 해당 브랜치는 develop 브랜치에 merge (병합) 되어야 하며,

그리고 나서 자동적으로 제거됩니다.

간단한 경우로, 만약 당신이 어떠한 추가적인 기능들을 개발 할 필요가 없다면,

이러한 부가적인 브랜치들이 더 이상 필요하지 않습니다.

하지만 만약 당신이 프로젝트에 새로운 기능을 추가하기로 결심했다면,

이미 생성되어 있는 develop 브랜치에서 코드를 망치지 않고, 별도로 작성하고 테스트하는 것이 편리 할 겁니다.

Release 브랜치는 프로젝트에 있어 새로운 버전의 릴리즈를 준비하는 데 사용됩니다.

이 브랜치는 최종적인 수정을 만들 수 있게 해 줍니다.

Release 브랜치는 브랜치의 개발 프로젝트가 거의, 혹은 완벽하게 준비 된 상태일 때 생성됩니다.

전체 프로젝트의 여러 버전을 가지고 있으며 하나씩 릴리즈(출시) 하고 싶을 때, 당신은 이 브랜치를 사용 할 겁니다.

Hotfix 브랜치는 release 브랜치와 비슷한데,

이는 새로운 버전에서 작업하게 될 때, 생성되며 사용된다는 점에서 비슷합니다.

하지만, Hotfix 브랜치에서 차이점이 나타나는데,

원치 않는 상황을 즉시 올바르게 만들어야 할 때만 필요하다는 것 입니다.

즉, 프로덕션 버전에 버그가 있을 때 입니다.

Hotfix 브랜치의 이점은 팀 중 한 명이 버전 버그를 고치고 있을 동안,

당신의 팀이 develop 브랜치에서 계속 작업할 수 있다는 것 입니다.

당신은 개발하는 동안 몇 가지 에러를 발견한다면, 이러한 Hotfix 브랜치가 필요 할 겁니다.

gitGraph TB:
        commit
    branch hotfixes
    branch release
    checkout release
        commit
    branch develop
        commit
    branch feature

    checkout release
        commit
        commit

    checkout release
        commit

    checkout hotfixes
    commit

    checkout main
    merge hotfixes

    checkout feature
        commit
        commit

    checkout hotfixes
        commit

    checkout main
    merge hotfixes

    checkout develop
    merge feature
        commit

    checkout release
    merge develop

    checkout main
    merge release

    checkout release
        commit type: HIGHLIGHT

    checkout develop
        commit type: HIGHLIGHT

    checkout main
        commit type: HIGHLIGHT

Working process - 작업 프로세스

---

Gitflow의 작업 프로세스는 대략 밑의 알고리즘을 따릅니다 :

1. repository를 초기화시킵니다.
2. 프로젝트 작업의 시작은 develop 브랜치에서 시작합니다.
3. 만약 당신이 새로운 것을 시도한다면, feature 브랜치를 생성합니다.
4. 새로운 기능이 준비되었을 때, feature 브랜치는 develop 브랜치에 merge되고, 삭제합니다.
5. 만약 모두가 현재 버전에 만족한다면, 버그가 수정 될 release 브랜치를 생성합니다.
6. 모든 에러들을 수정하고 난 후, release 버전을 main 브랜치에 merge 합니다.

Commands - 명령어

---

우리에게 필요한 명령어들은 밑의 사진에서 보여집니다 :

flowchart LR
    git-flow("git flow") --> blank1(" ")
    blank1 --> feature("feature")
    blank1 --> release("release")
    blank1 --> hotfix("hotfix")
    feature --> blank2(" ")
    release --> blank2
    hotfix --> blank2

    blank2 --> start("start")
    blank2 --> finish("finish")
    blank2 --> publish("publish")
    blank2 --> pull("pull")

    start --> blank3(" ")
    finish --> blank3
    publish --> blank3
    pull --> blank3

    blank3 --> name("NAME")

위에서 만든 플로우차트를 기초로, 주요 명령어들이 생성됩니다 : git flow <branch> <action> <branch_name>

예를 들어 feature 브랜치를 새로이 생성하고 싶다면, start action을 골라야 합니다 :

$ git flow feature start new_feature

이제 당신은 develop 브랜치에 기반한 새로운 feature 브랜치를 가지며,

자동적으로 새로운 브랜치로 스위칭합니다.

그리고 해당 feature 개발이 완료됐을 때, finish action을 사용하세요 :

git flow feature finish new_feature

따라서, 위의 명령으로 인해 즉시 세 가지 action을 수행합니다 :

• feature 와 develop 브랜치를 병합
• 원본 feature 브랜치를 삭제
• 계속 작업하기 위해 develop 브랜치로 이동

위의 명령어를 수행하기 전에 당신의 변경 사항을 commit하는 것을 까먹지 마세요!

hotfix 와 release 브랜치들도 같은 방식으로 생성되고 완료됩니다.

당신의 작업 결과를 remote server (GitHub) 에 업로드하기 위해서,

publish action을 선택해야 합니다.

예를 들어 publishing을 위한 명령어, release 브랜치에서 일어나는 일은 밑과 같습니다 :

$ git flow release publish my_release

현재 release/my_release 브랜치가 없기에, 해당 명령어는 실행되지 못합니다.

그리고 예를 들어 코드를 고치고자 다운로드 하기 위해서, pull action을 선택해야 합니다.

$ git flow hotfix pull new_version

Unknown subcommand: 'pull' 이라는 결과가 나오는데, hyperskill 에서 틀렸을 수도 있습니다.

에러 결과 :
Unknown subcommand: 'pull'
사용법: git flow hotfix [list]
  또는: git flow hotfix start
  또는: git flow hotfix finish
  또는: git flow hotfix publish
  또는: git flow hotfix delete

    Manage your hotfix branches.

    For more specific help type the command followed by --help

Tags and tracks - 태그 그리고 추적

---

당신의 update, fix의 수 많큼 git flow hotfix start version 1.0 과 같은 이름으로 직접적으로 쓰일 수 있습니다.

혹은, git tag -a 1.0 과 같이 직접 버전을 쓰는 명령어를 사용 할 수 있습니다.

당신이 tag에 있어 어떠한 변화라도 만들었다면,

git push --tags 를 사용해서 나중에 서버에 전달하는 것을 잊지 마세요.

태그를 붙이는 것 외에도, remote release 혹은 feature을 추적하는 데 있어서 편리합니다.

$ git flow feature track new_feature

Conclusion - 결론

---

gitflow 모델은 다양한 프로젝트의 개발에 있어서 매우 도움이 될 수 있습니다.

이는 당신에게 전체적이며, 구조적인 문제의 청사진을 볼 수 있게 해 주며, 해결 방법을 보게 해 줍니다.

Gitflow를 따르는 것은 프로젝트의 작업에 있어 branching과 merging 프로세스의 이해를 공통으로 가지게 해 줍니다.

우리는 gitflow의 기초적 명령어와 작업 구조를 분석했습니다.

바라건대, 거대한 IT 프로젝트 개발을 시작할 때 이러한 모델을 따르길 바랍니다.

words to remember

---

variants : 변형, 변체

lifespan : 수명, 생애

approximately : 약, 대략 == approximate : 근접한, 대략의, 접근하다, ~에 접근하다