Git의 다양한 워크플로에 대해 심층적으로 이해하세요.

이 글에서는 Git에 대해 소개하고, Git에 대한 기본 지식과 Git을 기반으로 한 다양한 워크플로우를 소개하겠습니다.

이 기사를 통해 배울 수 있는 내용:

• git의 기원
• git의 기본 지식
• gitflow 프로세스의 기본 방법
• git 기반의 다양한 작업 흐름

Git Flow에 대해 이야기하기 전에 먼저 먼저 다른 얘기부터 해보자

• 버전이란 무엇인가요?
  버전은 인쇄할 때의 버전을 말하며, 버전은 인쇄된 책의 버전을 말하며, 동일한 것의 서로 다른 다양한 형태, 상태 또는 내용을 설명하는 데 사용되는 제목입니다.
  즉, 무엇이든 차별화되는 한 버전 개념이 포함됩니다. 그러나 나중에 이야기할 내용을 포함하여 여기서 이야기하는 버전은 모두 의미 있는 버전이어야 합니다. 1월 31일 기획 문서가 매일 수정되었습니다. 2월 1일 Xiao Ming의 당사자 A는 이전 버전이 Xiao Ming에게 더 좋았다고 말했습니다. 어쩌면 샤오밍이 A측에 보낸 마지막 계획이었을 수도 있고, A측이 괜찮다고 말한 마지막 계획이었을 수도 있지만, 샤오밍은 해당 계획이 A측으로 수정된 구체적인 날짜를 기억하지 못할 수도 있습니다.

• 일반적인 버전 관리는 무엇인가요?
  복사 파일을 이름으로 구분하는 방식, 이 편집기의 실행 취소/전달 기능, svn, git 등과 같은 전문 도구의 사용은 모두 버전 관리의 범주에 속합니다. 파일 복사와 같은 수정 사항을 쉽게 취소할 수 있으며, 이를 통해 새 파일과 기존 파일이 동시에 존재하여 쉽게 비교할 수 있지만 이러한 방법은 너무 간단하고 중간 프로세스가 일시적입니다. 이를 살펴보려면 중앙 집중식 버전 관리 시스템 SVN, CVS, 분산 버전 관리 시스템 BitKeeper, Git 등과 같은 일부 전문 도구도 필요합니다.

• Git 개발 배경

  인생의 많은 위대한 일들처럼, Git은 큰 투쟁과 혁신의 시대에 태어났습니다. Linux 커널 오픈 소스 프로젝트에는 많은 참가자가 있습니다. Linux 커널 유지 관리 작업의 대부분은 패치를 제출하고 아카이브를 저장하는 지루한 작업에 소요되었습니다(1991-2002). 2002년까지 전체 프로젝트 팀은 독점 분산 버전 제어 시스템인 BitKeeper를 사용하여 코드를 관리하고 유지하기 시작했습니다.
  2005년에 BitKeeper를 개발한 상업 회사와 Linux 커널 오픈 소스 커뮤니티 간의 파트너십이 종료되었고 그들은 Linux 커널 커뮤니티에서 BitKeeper를 무료로 사용할 수 있는 권리를 되찾았습니다. 이로 인해 Linux 오픈 소스 커뮤니티(특히 Linux 제작자 Linus Torvalds)는 BitKeeper 사용에서 얻은 교훈을 기반으로 자체 버전 시스템을 개발하게 되었습니다. 그들은 새로운 시스템에 대한 몇 가지 목표를 설정했습니다.

  • 속도 ​​
  • 단순한 디자인
  • 비선형 개발 모델에 대한 강력한 지원(수천 개의 병렬 개발 분기 허용)
  • 완전 분산
  • 능력 매우 큰 프로젝트를 효율적으로 관리 Linux 커널과 유사(속도 및 데이터 볼륨) 2005년 탄생 이후 Git은 초기에 설정된 목표를 유지하면서 사용자 친화적으로 변하면서 성숙해졌습니다. 빠르고 대규모 프로젝트 관리에 적합하며 놀라운 비선형 분기 관리 시스템을 갖추고 있습니다(Git 분기 참조).

• 1991년 Linux는 오픈 소스 프로젝트인 Linux 시스템을 개발했습니다. 소스 파일은 작성 및 개발용 패치가 첨부된 이메일을 통해 전송되었으며 Linux는 이를 수동으로 병합했습니다.

• 2002년에 BitKeeper는 Linux 커뮤니티와 합의에 도달했습니다. Linux 커뮤니티는 무료 평가판으로 인해 BitKeeper 자체를 보호하는 것에 관한 것입니다.

• 2005년에 BitKeeper는 계약 내용을 파기한 Linux 커뮤니티에 불만을 품고(솔직히 말하자면 BitKeeper를 디컴파일하고 크랙 버전 등을 만들려고 했습니다) 협력을 종료했습니다. 2005년과 같은 해, Linux는 Git 개발에 2주를 소비했습니다. 첫 번째 에디션, Git을 사용하여 한 달 만에 Linux 코드 관리

• Git에 대한 기본 지식

Workspace(Workspace), Staging Area(Index), Repository(Repository) )

# 创建并进入 testGitFlow 目录
# 此时 testGitFlow 就是我们的工作区(Workspace)，也就是工作目录

$ mkdir testGitFlow && cd testGitFlow

# 初始化 git 仓库
# 此时目录中增加了 .git 目录，.git 目录就是 git 仓库，不属于工作区

$ git init

# 新增两个文件
$ echo 111 > a.txt
$ echo 222 > b.txt

# 添加两个文件到暂存区/索引(Index)
$ git add .

# 把索引中的两个文件添加到版本库(Repository)
$ git commit -m 'init'

위와 관련된 여러 개념 :

Workspace

: 간단한 이해는 프로젝트 디렉토리

Index: 간단한 이해는 제출할 콘텐츠를 저장하는 영역
Repository: 버전 저장소
Commit, Tree, Blob 개체

# 通过 git log 查看版本
$ git log

>
commit 2b304a56998989dbcfd77f370f4b43fcad9e5872 (HEAD -> master)
Author: huihuipan <huihuipan163@163.com>
Date:   Mon Feb 27 17:56:53 2023 +0800

    init


# 通过 git cat-file 查看 commit 信息

# 查看 commit 类型
$ git cat-file -t 2b304a
> commit

# 查看 commit 内容
$ git cat-file -p 10d717

>
tree 4caaa1a9ae0b274fba9e3675f9ef071616e5b209
author huihuipan <huihuipan163@163.com> 1677491813 +0800
committer huihuipan <huihuipan163@163.com> 1677491813 +0800

init

# 可以发现有 tree, author, committer 等信息
# 继续查看 tree 内容
$ git cat-file -t 4caaa1
> tree

$ git cat-file -p 4caaa1
>
100644 blob 58c9bdf9d017fcd178dc8c073cbfcbb7ff240d6c	a.txt
100644 blob c200906efd24ec5e783bee7f23b5d7c941b0c12c	b.txt

# 可以发现有 blob 信息
# 继续查看 blob 内容
$ git cat-file -t 58c9bd 
> blob

$ git cat-file -p 58c9bd 
> 111

# 可以看到里面存储的是 a.txt 的内容

위 항목 중 몇 가지 관련 개념:

commit

: 커밋은 제출된 버전을 기록합니다.

tree: 트리는 다른 버전의 디렉터리 구조와 파일 이름을 기록합니다.
blob: blob은 파일을 기록합니다. content
현재 저희 git 프로젝트 구조는 다음과 같습니다

파일을 수정하고 커밋을 제출하면 어떻게 되나요?

1. 먼저 a.txt의 내용을 111에서 333으로 수정합니다. 이때 git Warehouse는 변경되지 않았으나 작업공간과 인덱스의 내용이 일치하지 않습니다.
2. 를 실행합니다. git add 명령
   1. git Warehouse는 새로운 a.txt의 내용(333)을 기반으로 새 blob 노드를 생성하고 a.txt의 내용을 기록합니다
   2. 인덱스는 이전 blob에서 새 blob을 가리킵니다
3. git commit 명령어 실행
   1. 인덱스 상태에 따라 트리 객체가 생성됨
   2. 새로 생성된 트리 객체와 이전 커밋 객체를 기반으로 새로운 커밋 객체 생성
   3. 이전에서 분기 포인터 이동 커밋 개체를 새 커밋 개체

HEAD, Branch, Tag

Branch : 새 커밋이 제출될 때마다 현재 Branch는 커밋을 가리키는 포인터입니다. 최신 커밋;

HEAD: Checkout이 비브랜치에 도달하면 분리된 헤드 포인터 상태에서 몇 가지 실험적인 작업을 수행할 수 있습니다.

Tag: 커밋에 대한 포인터, 일반적으로 고정 버전을 기록하는 데 사용되는 레이블로 사용되며 지정된 커밋의 별칭으로도 이해될 수도 있습니다.

위에서 git의 버전 관리 세분성을 배울 수 있습니다. 파일 수준에 도달하면 Blob 간의 비교가 다를 수 있습니다. 이는 또한 프로그램 설계의 기초가 비교인 경우 개발 생각으로 이어집니다. 세분화가 작을 때 실제로 후속 개발 및 확장이 더 유연해집니다. git의 커밋 작업도 매우 유연하므로 주의하지 않으면 사고가 발생할 수 있습니다.

Checkout, Merge, Rebase, Fetch, Pull

checkout: 지정된 브랜치 또는 커밋으로 HEAD를 체크아웃하거나, 지정된 버전에서 지정된 파일의 내용을 체크아웃합니다. 왜냐하면 Git의 체크아웃은 너무 많은 다중 항목을 전달하기 때문입니다. 기능, 모든 전환 분기에는 독점 명령 이 있습니다. switch

merge merge

:

rebase rebase

:rebase는 버전 기록을 수정합니다. 리베이스 전후의 콘텐츠가 일관되더라도 버전은 더 이상 동일한 버전이 아닙니다.

fetch

: 원격 라이브러리와 같은 다른 저장소에서 개체 및 참조 다운로드

pull

: git pull = fetch + merge Git 기반의 여러 워크플로

Git Flow

소개

는

2010

main Branch

에

Vincent Driessen

이 작성한 기사

"성공적인 Git 분기 모델"에서 가져온 것입니다. 라이프 사이클, 즉 장기 분기:

master 분기: 릴리스용
• develop 분기: 개발용 마스터 브랜치와 개발 브랜치의 관계는 위와 같습니다. 점선은 두 브랜치가 직접적으로 관련되어 있지 않고 릴리스/핫픽스 브랜치

지원 브랜치

기능 브랜치를 통해 관련되어 있음을 나타냅니다. 수요 개발에 사용됩니다

요구 사항을 개발할 때 기능 브랜치가 개발된 후(개발 자체 테스트에 문제가 없으면) 다시 병합됩니다. 병합 후에는 해당 브랜치가 삭제되며 나중에 버그가 발생하면 개발 브랜치에서 수정됩니다.

릴리스 브랜치: 릴리스에 사용

개발 브랜치가 비교적 안정적인 상태에 있을 때 릴리스 브랜치를 개발 브랜치에서 끌어와 릴리스 준비를 할 수 있습니다. 릴리스 브랜치는 기능 개발을 수행하지 않습니다. , 버그 수정만 가능하며, 문제가 없으면 마스터 브랜치에 병합하여 릴리스하는 동시에 다시 개발 브랜치에 병합하고 릴리스 브랜치를 삭제합니다.

• hotfix 브랜치: 프로덕션 문제를 해결하는 데 사용됩니다

hotfix 브랜치는 프로덕션 환경에서 긴급하게 수정해야 하는 버그를 수정하는 데 사용됩니다. 프로덕션 환경에서 버그가 발생하면 마스터에서 hotfix 브랜치를 끌어옵니다. 브랜치를 수정한 후 다시 마스터 브랜치에 병합하고 개발 브랜치에 병합한 후 삭제하세요.

마지막으로 전체 gitflow를 검토합니다

Supplement

In 2020 Vincent Driessen이 반성 메모를 추가했습니다. 대충 말하자면Git Flow이 모델은 지속적인 전달 소프트웨어에 속합니다. 복잡해 보여 넌 프로젝트에 Git Flow를 강제하는 대신 Github Flow 사용을 고려해 보세요.

다음으로 Git Flow, Adam Ruka가 Git Flow의 기술적 세부 사항을 최적화하고 One Flow

Github Flow

를 제안했습니다.

대 Git Flow , Github Flow에는 트렁크 브랜치가 하나만 있으며 PR 프로세스는 github 플랫폼을 통해 추가됩니다. 특정 기능을 개발할 때 마스터 브랜치에서 기능 브랜치를 꺼내서 기능 완료 후 PR을 제출하고 관련 담당자가 검토하도록 하세요. 검토 중에도 해당 기능을 제출할 수 있으며 기능 브랜치를 마스터에 병합할 수 있습니다. 문제가 없는 것이 확인될 때까지 PR을 통해

GitLab Flow

GitLab Flow를 출시하기 위해 master 브랜치를 기반으로 master 브랜치를 개발 브랜치로 사용합니다. 프로덕션 브랜치 출시 production
GitLab Flow 추가됨 다음 브랜치 정의:
환경 브랜치 : 다양한 환경에서 다양한 버전을 출시해야 할 때 사용됨
릴리스 브랜치 : 사용됨 프로젝트가 다른 버전을 출시해야 하는 경우 릴리스 분기를 선언한 후 이 분기는 심각한 버그 수정 업데이트와만 병합됩니다.

지속적 릴리스

gitlab-flow에서는 개발 시 마스터 브랜치를 사용하고, 릴리스 시에는 마스터 브랜치를 기반으로 프로덕션 브랜치를 구축하는 것을 권장하며, 이에 따라 레이어별로 병합되는 환경 브랜치 개념도 제안합니다. 브랜칭 후 릴리스

버전 릴리스

프로젝트가 다른 버전을 릴리스해야 하는 경우 연속 릴리스 모드에서는 gitlab-flow 버전 릴리스 모드가 더 적합할 수 있습니다. 버전마다 릴리스에 대한 릴리스 분기가 다릅니다.

Aone Flow

Aone-flow는 master 브랜치를 기반으로 하며, master 브랜치 이외는 임시 브랜치입니다. 환경 브랜치는 마스터 브랜치를 기반으로 뽑아내며, 환경 브랜치 간의 연결이 없으며 독립적으로 개발되며, 환경 브랜치는 직접 수정이 불가능하며, 서로 다른 기능 브랜치를 병합하여 결합됩니다. 기능 분기는 릴리스 분기에 병합될 때까지 삭제되지 않습니다. 한 가지 장점은 작업 세분화가 더 높고 제어가 더 쉽다는 것입니다. 단점은 환경 브랜치의 내용이 동일하더라도 버전 기록이 일관되지 않을 수 있다는 것입니다.

버전 관리 선택 방법

위에서 여러 흐름을 소개했는데, gitflow에서는 자유도가 높은 git이 안내식 사용 방법을 얻을 수 있도록 했습니다.
그리고 github-flow에서는 버전 관리에 대한 새로운 방법을 제안했습니다. gitflow의 복잡성. gitlab-flow는 지나치게 복잡하거나 너무 단순한 gitflow 및 github-flow 방법에 대한 자체 절충 솔루션을 제안하고 두 가지 전달 방법(지속적 전달, 버전 전달)에 대한 솔루션도 제공합니다.
마지막으로 더욱 자유로운 운영 세분화를 갖춘 솔루션인 AoneFlow도 도입되었습니다.

사실 모든 상황에 딱 맞는 솔루션은 없습니다. 팀/프로젝트마다 상황에 따라 흐름도 달라지며 가장 적합한 솔루션이 있습니다.

마지막으로

패닉은 존재하지 않는다는 점을 항상 기억하세요. 자신의 상황을 고려하여 스스로 결정하세요.

Vincent Driessen의 인용문: "마지막으로 마법의 총알은 없다는 것을 항상 기억하십시오. 자신의 배경을 고려하여 스스로 결정하십시오."

프로그래밍 관련 지식을 더 보려면 다음을 방문하세요. 프로그래밍 비디오 ! !

위 내용은 Git의 다양한 워크플로에 대해 심층적으로 이해하세요.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!