Get an in-depth understanding of Git's various workflows

This article will introduce you to Git, introduce the basic knowledge of git, and various workflows based on git. I hope it will be helpful to you!

Through this article you can learn:

• The origin of git
• Basic knowledge of git
• The basic method of gitflow process
• Multiple workflows based on git

Before talking about Git Flow, let’s talk about other things first

• What is a version?
  Edition refers to the printing edition, and the edition is the printed book; edition is a title used to describe various forms, states or contents of the same thing that are different from each other.
  In other words, as long as anything is differentiated, it will involve the concept of version. However, the versions we are talking about here, including the things we will talk about later, should all be meaningful versions. For example, Xiao Ming January 1 From February 1st to January 31st, a planning document was revised every day. On February 1st, Xiao Ming’s Party A said that the previous version was better. At this time, for Xiao Ming, what was the previous version? Maybe it was the last plan that Xiao Ming sent to Party A, or maybe it was the last plan that Party A said was okay, but Xiao Ming may not remember the specific date on which the plan was revised to Party A.

• What are the common version controls?
  copy The way files are distinguished by name, the undo/forward function of this editor, and the use of professional tools such as svn, git, etc. all belong to the category of version control. Different version controls have different uses, such as text editors. Withdraw, you can easily undo this modification, such as copying files, which can allow new and old files to exist at the same time for easy comparison, but these methods are too simple, and the intermediate processes are temporary things, which are not enough to serve as a modification history reference or Treat it as a complete version. For this, some professional tools are needed, such as centralized version management systems SVN, CVS, distributed version management systems BitKeeper, Git, etc.

• Git development background

  Like many great things in life, Git was born in an era of great strife and innovation. The Linux kernel open source project has a large number of participants. The vast majority of Linux kernel maintenance work was spent on the tedious task of submitting patches and saving archives (1991-2002). By 2002, the entire project team began to use BitKeeper, a proprietary distributed version control system, to manage and maintain code.
  By 2005, the partnership between the commercial company that developed BitKeeper and the Linux kernel open source community ended, and they took back the Linux kernel community's right to use BitKeeper for free. This forced the Linux open source community (especially Linux creator Linus Torvalds) to develop their own version system based on the lessons learned from using BitKeeper. They set several goals for the new system:

  • Speed
  • Simple design
  • Strong support for non-linear development models (allowing thousands of Branches of parallel development)
  • Fully distributed
  • Ability to efficiently manage ultra-large-scale projects similar to the Linux kernel (speed and data volume) Since its birth in 2005, Git has matured and matured, becoming highly user-friendly while still retaining the goals set in its early days. It's fast, great for managing large projects, and has an incredible non-linear branch management system (see Git branches).

• In 1991, Linux developed the Linux system, an open source project. It used the method of sending source files with patches by email for writing and development, and Linux himself merged them manually;

• In 2002, BitKeeper reached an agreement with the Linux community to allow the Linux community to try BitKeeper for free. Due to the free trial, the content of the agreement is more about protecting BitKeeper itself.

• In 2005, BitKeeper was dissatisfied with the Linux community's destruction of the agreement (to put it bluntly, it was decompiling BitKeeper, trying to make a cracked version or other), and terminated cooperation;

• Same as 2005, Linux spent 2 weeks to develop the first version of Git, and used Git to manage Linux code within a month;

Git basic knowledge

Workspace, Temporary Storage 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'

Several concepts involved above:
Workspace: A simple understanding is our project Directory
Index: A simple understanding is the area where content to be submitted is stored
Repository: Version repository

Commit, Tree, Blob objects

# 通过 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 的内容

Several concepts involved in the above:
commit: commit records the submitted version
tree: tree records the directory structure and file name under different versions
blob: blob record file content

At this time our git project structure is as follows

What happens when you modify the file and submit the commit?

1. First of all, the content of a.txt is modified from 111 to 333. At this time, the git warehouse has not changed, but the contents of the workspace and the index do not match;
2. Execute the git add command
   1. The git warehouse creates a new blob node based on the new a.txt content (333) and records the a.txt content
   2. The index changes from the old The blob points to the new blob
3. Execute the git commit command
   1. Generate the tree object based on the status of the index
   2. According to the newly generated tree object and the previous A commit object, generates a new commit object
   3. Move the branch pointer from the old commit object to the new commit object

HEAD, Branch, Tag

Branch: is the pointer pointing to Commit. Every time a new commit is submitted, the current Branch will point to the latest commit;

HEAD: Pointer to Branch. When checkout reaches a non-branch, it will prompt It is in the detached head pointer state, and you can do some experimental actions. ;

Tag: Pointer to Commit, used as a label, usually used to record a fixed version, and can also be understood as an alias for a specified commit;

We can learn from the above that the version management granularity of git reaches the file level, and diff can be obtained by comparing blobs. This also leads to a development thought. When our program design When the basis is a relatively small granularity, subsequent development and expansion will be more flexible. In fact, git's operation of commit is also very flexible, so flexible that accidents may occur if you are not careful.

Checkout, Merge, Rebase, Fetch, Pull

checkout checkout: Check out HEAD to the specified branch or commit, Or check out the contents of a specified file of a specified version. Since checkout carries too many functions in git, all switching branches have exclusive commands switch.

merge merge:

##rebase rebase:

Rebase will modify the version history. Even if the content before rebase is consistent with the content after rebase, the version is no longer the same version

fetch: Download objects and references from another repository, such as a remote library

pull: git pull = fetch merge

based on Several workflows of Git

Git Flow

Introduction

From

Vincent Driessen in 2010 An article written in
"A successful Git branching model"

There are two main branches

A branch will run through the entire version life cycle, that is, a long-term branch:

master branch: used for release
• develop branch: used for development The relationship between the master branch and the develop branch is as above. The dotted line points to the two branches that are not directly related, but related through the release/hotfix branch

support branch

feature branches: used for requirement development

When developing requirements, pull the feature branch from the develop branch. After the feature branch is developed (the development self-test has no problems), Merge back to the develop branch, delete the branch after merging, and modify it in the develop branch if bugs occur later.

release branches: used for release

When the develop branch is in a relatively stable state, it can be pulled from the develop branch The release branch is ready for release. The release branch does not carry out functional development, but only bug fixes. When there are no problems, it is merged into the master branch for release. At the same time, it is merged back into the develop branch and then the release branch is deleted.

• hotfix branches: used to fix production problems

hotfix branches are used to fix bugs that urgently need to be fixed in the production environment. When a bug occurs in the production environment At that time, pull out the hotfix branch from the master branch, merge it back into the master branch for release after repair, and merge it into the develop branch before deleting it.

Finally review the complete gitflow

Added

In 2020 Vincent DriessenAdded a Reflection Note, roughly speakingGit FlowThis model seems complicated under continuous delivery software, you can consider using Github Flow instead of shoehorning Git Flow into the project.

FollowingGit FlowAdam Ruka forGit Flow## The technical details of # have been optimized and One Flow

Github Flow

## is proposed compared to

Git Flow, Github Flow There is only one trunk branch, and the PR process is added through the github platform: When developing a certain function, pull out the feature branch from the master branch, submit a PR after completing the function, and let relevant personnel review it. During the review period, you can still submit the feature until it is confirmed that there are no problems and pass the PR to merge the feature branch into master. Branch for releaseGitLab Flow

GitLab Flow Use the master branch as the development branch, Based on the master branch, release the branch production
GitLab Flow Add The following branch definition:
Environment branch: Use
release branch## when you need to release different versions in different environments #: Used when the project needs to release different versions. After declaring a release branch, this branch will only merge serious bug fix updates. Continuous Release

gitlab-flow recommends using the master branch for development, and building a production branch based on the master branch for release. It also proposes the concept of environment branches. , merge layer by layer according to different environments, and finally summarize it into the production release branch for release

Version release

If your project needs to release different versions , the gitlab-flow version release mode may be more suitable. In the continuous release mode, different versions will be released in different release branches.

Aone Flow

Aone-flow is based on the master branch, and other than the master branch are temporary branches. The environment branches are pulled out based on the master branch. There is no connection between the environment branches and they are developed independently. The environment branches are not allowed to be modified directly, but are combined by merging different feature branches. The feature branch will not be deleted until it is merged into the release branch. One advantage is that the operation granularity is higher and more controllable. The disadvantage is that even if the content of the environment branch is the same, the version history may be inconsistent.

How to choose version control

Several flows are introduced above, starting from gitflow, gitflow allows git with a high degree of freedom to be used in a guided manner;

And github- flow proposes a minimalist version of flow in response to the complexity of gitflow;

gitlab-flow also proposes its own compromise solution for the overly complex or simple methods of gitflow and github-flow, and also provides Two delivery methods (continuous delivery, version delivery) solution;

Finally, AoneFlow is also introduced, a solution with freer operating granularity.

In fact, there is no one-size-fits-all solution. Different teams/projects have their own special situations. For different situations, the flow is also changing, and the appropriate one is the best.

Finally

To conclude, always remember that panaceas don't exist. Consider your own context. Don't be hating. Decide for yourself.

QuoteVincent Driessen: "Finally, always remember that there is no magic bullet. Consider your own background. Don't hate. Decide for yourself"

More For programming related knowledge, please visit: programming video! !

The above is the detailed content of Get an in-depth understanding of Git's various workflows. For more information, please follow other related articles on the PHP Chinese website!