Git flow project development process and simplification, use git to fall back to the specified version, and the role of core.autocrlf in git

1. Git Flow development process

In actual development, using git flow can easily manage each version of the project, and function development can also improve efficiency. The specific usage method is as follows:

Install the Git client:

Download and install git:

​​​​​​https://github.com/petervanderdoes/gitflow-avh/wiki/Installation

Just select the corresponding platform.

Here the git of the Windows platform is used by default: Git for Windows

PS：

1. TortoiseGit will also be installed in the daily development , which is convenient for the display of file submissions in the local warehouse, and can also be easily submitted to the remote warehouse.

TortoiseGit download link: Download – TortoiseGit – Windows Shell Interface to Git

Notice:

1. TortoiseSVN is an SVN tool. When using SVN as a version management tool in a project, you need to use TortoiseSVN for version development. Download link: Download · TortoiseSVN

The difference between Git and SVN: Git and SVN comparison - WindrunnerMax - 博客园

2. Both TortoiseGit and TortoiseSVN have corresponding LanguagePack multi-language packs in the corresponding download links, and the LanguagePacks of different tools cannot be shared.

The detailed process of using git flow in the project:

1. Clone the remote repository:

git clone 远程仓库链接

Notice:

1. After using the git clone command, it will automatically create a folder in the current directory with the name of the project in the remote warehouse link

For example, right click on the current directory "D:\Project\Unity" and select "Git Bash Here" to open the git window:

 

After using the git clone command, the corresponding folder "testBranch" will be automatically generated according to the project name linked to the remote warehouse.

So there is no need to create another folder to place remote warehouse items, avoiding nesting

2. After the clone command is completed,

*** will automatically associate the local warehouse with the remote warehouse

*** And will automatically create a branch with the same name in the local warehouse according to the default branch of the remote warehouse (the default branch in Gitlab is main).

*** If needed later, you can freely change the name of the folder with the same name that is automatically created based on the remote project above .

     Note: Changing the folder name does not change the association between the local warehouse and the remote warehouse.

3. Afterwards, all operations on the local warehouse and remote warehouse need to enter the "testBranch" folder first and then open the git window, and cannot be operated in the same level directory as "testBranch".

PS：

View the association status of the local warehouse:

git remote -v

Associate the local warehouse with the remote warehouse:

git remote add 远程仓库别名(默认为origin，也可以自定义)  远程仓库链接

Notice:

1. The function of setting the remote warehouse alias is only to use this alias directly when the remote warehouse link needs to be used later, instead of entering a long string of links.

2. It is also possible to associate the local warehouse with the branch of the same name as the remote warehouse:

git push -u origin 本地分支名

2. Synchronize the contents of the remote warehouse to the local warehouse:

PS: After using the git clone command for the first time, the latest content of the remote project will be cloned to the local warehouse by default, and no additional synchronization is required at this time.

Synchronize the specified branch of the remote warehouse to the specified branch of the local warehouse :

git pull 远程仓库别名 远程仓库指定分支：本地仓库指定分支

Synchronize the specified branch of the remote warehouse to the current branch of the local warehouse :

git pull 远程仓库别名 远程仓库指定分支

3. Initialize with git flow:

The name of each branch of the Git project will be set here, including the release branch release, the development branch develop, and the function branch feature, etc., just keep the default configuration.

Note: After executing the git flow init command, the local warehouse will be automatically switched to the develop branch.

But this only creates a new development branch in the local warehouse, and does not create a new development branch in the remote warehouse . If you need to create a develop branch in the remote warehouse, you can use "git push origin local branch name: remote branch name", or create a new branch directly on Gitlab

PS: When performing initialization, you may encounter the problem that the branch name is wrong, which will cause the failure to initialize successfully

This is because the branch name is incorrect, and some project master branches use "master". So here "Branch name for production releases" fill in the master

4. New function development feature branch:

In actual development, an independent branch is usually created for a certain function for development. After the development of this function is completed, it will be merged back into the develop branch for easy management.

Create a feature branch for feature development: The branch prefix used for feature development in the above git flow init command is feature, which can be set freely

git flow feature start 分支名

After executing the above command, the " feature/branch name " branch will be automatically created in the local warehouse :

Notice:

1. The branch name of git flow feature start is to create a new branch based on develop in the local warehouse, not based on the develop branch in the remote warehouse , so the local develop branch needs to be synchronized when starting feature branch development to the latest status.

2. The created feature branch will automatically add the feature prefix, so the actual name of the branch obtained above is: feature/branch name

5. Submit files in the branch to the local cache:

First add the specified file tracking:

git add 文件路径

 Notice:

1. The file path here is a relative path, and it is a relative path under the project root directory

When adding the file01.txt file as follows, just use "git add file01.txt" directly

PS: When you need to submit all the files in the root directory, you can use "git add ." - the dot, which means all the files in the root directory

2. Use "git status" to view the status of file submission:

Then, after adding all the files, submit these modified files to the local warehouse cache:

git commit -m "注释"

Note: If you use TortoiseGit, all files will turn green after executing git commit -m "comment", that is, the submission to the local warehouse is completed

6. Push the contents of the local warehouse cache to the remote warehouse:

Push the current branch of the local warehouse to the specified branch of the remote warehouse :

git push origin <本地分支名>:<远程分支名>

Push the current branch of the local warehouse to the branch of the same name in the remote warehouse :

git push origin <本地分支名>

Notice:

1. When the file to be submitted is large, the submission may fail. At this time, the size of the git cache area can be configured:

# 缓存大小单位：B，例如：524288000（500MB）
$ git config --global http.postBuffer <缓存大小>

2. After executing the git push origin operation, if the branch does not exist in the remote warehouse, the branch will be automatically created in the remote warehouse ; if there is, the content of the current branch of the local warehouse will be synchronized to the branch with the same name in the remote warehouse.

7. Close the function feature branch:

After the entire function is implemented and the acceptance is confirmed to be correct, you can use git flow to close the branch:

git flow feature finish 分支名

Notice:

1. The actual name of the branch is "feature/branch name", but you only need to write "branch name" in the above command, and you don't need to add the "feature" prefix

2. After the above command is executed, the branch "feature/branch name" of the local warehouse will be automatically deleted, and it will automatically switch to the develop branch of the local warehouse.

By default, the "feature/branch name" of the remote warehouse will also be deleted. If the local develop branch is not synchronized with the remote develop branch or other circumstances, the remote "feature/branch name" may not be deleted

3. The above operation is just to switch the local warehouse to the develop branch, and the develop branch of the remote warehouse will not be modified in any way . So if you want to synchronize to the develop branch of the remote warehouse, you need to use the git push origin local branch name additionally

PS：

1. When executing the above instructions to close the feature branch, you may encounter the following problems:

 $  git flow feature finish archiveDrawing
Branches 'develop' and 'origin/develop' have diverged. 
Fatal: And branch 'develop' may be fast-forwarded.

Reason: Although the latest content of the remote "develop" branch has been pulled to the local "feature/archiveDrawing" branch at this time, the local "develop" branch still does not have the latest content, so you need to switch to the local "develop" branch first " branch, and then update the local "develop". Then use "git flow finish" to close the feature branch

Solution:
Step 1: Switch the local to the "develop" branch first, and then pull the latest content of the remote develop branch

git checkout develop                      //先将本地切换到develop分支

git pull origin                           //更新本地develop分支到最新

Step 2: Switch to the archiveDrawing branch based on the latest local development branch:

git flow feature rebase archiveDrawing               //archiveDrawing为feature分支名

At this point there may be some conflicting files. Therefore, it is recommended to pull the latest remote develop branch content on the local archiveDrawing branch before executing the "git flow feature finish" command. Files that may cause conflicts are directly processed in this step. After processing, there will usually be no conflicts when using the "git flow feature rebase" instruction here

PS: I encountered "REBASE 1/1" when using the git flow feature rebase instruction :

A "REBASE 1/1" marker appears at the end of the branch

This is caused by a conflict with the local file after pulling the remote branch. At this time, it is not acceptable to directly execute the "git rebase --continue" command.

Solution:

First use "git rebase --skip" directly to skip the current commit.

Then switch to the develop branch and pull the latest development content to the local. Give up using the feature function branch, just commit and push the modified content directly on the develop branch

Step 3: Re-execute the "git flow feature finish archiveDrawing" command

After executing the "git flow feature rebase" command, you will switch to the "archiveDrawing" branch locally. At this time, re-execute the "git flow feature finish archiveDrawing" command to delete the local and remote "archiveDrawing" branches normally. Then push to the remote develop to complete the submission process

8. Synchronize the development branch of the local warehouse to the development branch of the remote warehouse:

This is an important step:

reason:

1. Using the git flow feature finish command only switches the local warehouse to the develop branch, and does not synchronize the modification to the develop branch of the remote warehouse, so it is necessary to execute the git push command again,

git push origin develop

Only the remote warehouse has these modifications, otherwise the develop branch of the remote warehouse will not have any modifications

2. The develop branch in the same project generally saves the functions of the current project that have been accepted and are relatively stable, so develop may be modified by multiple people at the same time. Everyone will merge into the develop branch after completing the functions at that time. So the develop branch in our local warehouse may lag behind the develop branch in the remote warehouse

So in order to avoid restoring some files, we need to synchronize the latest content in the development branch of the remote warehouse to the local before synchronizing

When pulling the development branch of the remote warehouse to the local development branch, there may be some file conflicts, so you need to deal with the conflict first, and then "git commit -m" the processed content to the local warehouse develop Cache area, and then use git push origin develop to synchronize to the development branch of the remote warehouse

The above is the normal git flow development process, and the following is a simplified version:

The git flow branch development process is simplified:

In actual use, although git flow can manage the development process in a unified manner, when the feature branch is completed and merged into develop, the "git flow feature finish branch name" command often encounters some problems and fails to close the branch, so the process is simplified here:

1. At the beginning of development, the command "git flow feature start branch name" is still used to create a new feature branch on the basis of develop, and all subsequent submissions are operated on this branch.

2. After the development of the feature branch is completed, the modification of the feature branch needs to be submitted to the local and remote feature branches with the same name. The process is as follows:

First, you need to pull the latest content from the develop branch to the feature branch . Since the project is developed by multiple people, file conflicts are often encountered.

Conflict handling:

1. When pulling the remote develop branch to the local feature branch, in order to avoid the local modification being overwritten and resulting in loss, git will automatically stop the pull operation, prompting that the local modification needs to be "stash", that is, first commit the local modification content to the local feature branch , to avoid loss.

2. After the commit is modified to the local feature branch, then pull the remote develop branch. At this time, git will automatically merge the modified content in different places in the same file . But if you modify the same line of code in the same file, then git will prompt you to select the corresponding version at this time, and you can choose the modification corresponding to develop or its own feature according to the specific situation.

So the conflict is resolved

Secondly, after pulling the latest development content to the feature branch, since the local has the latest development branch content, it needs to commit again to the local feature branch warehouse.

Finally, push the local feature branch to the remote feature warehouse. This completes the feature branch.

Branch merge: how to merge feature branch into develop branch?

First switch the local branch to develop: git checkout develop

Then update the local develop branch . If the local develop is not up to date, the merge operation cannot be performed:

git pull origin develop. —— It is recommended to use the git tool for this step, the tool is relatively simple and clear

Finally, merge the feature into the develop branch:

Notice:

1. If branch a is to be merged into branch b, then the local needs to checkout to branch b, and branch a is merged on the basis of branch b.

2. In the process of merging, conflicts are often encountered. Since the content of the feature branch has been merged once before, part of the conflicts can be avoided, but there is still the possibility of conflicts

The operation of merging features into the develop branch can be done directly using the git tool:

 The "Branch" in "From" in the above figure refers to the merged branch C. There is no need to fill in the merge in the "Merge message", and it will be automatically generated. After the selection is completed, it means that branch C will be merged into develop

After clicking "OK", the merge will start. Conflict handling may occur during the merging process, just choose the version to use according to the specific situation.

Reference link for merging branches: git merging branches (understand at a glance) - Programmer Sought

After the merge is completed, the contents of the two branches are locally available, but since the previously modified content has been submitted using branch C, there is no need to re-commit the modified content using the develop branch after merging branch C to develop Once - after the merge is complete, the develop branch already contains the content that branch C has committed , so you only need to push the develop branch to the develop branch of the remote warehouse

2. Use git to roll back to the specified version:

Sometimes during development, after committing and pushing to the remote warehouse, it is found that some content is not suitable for submission. At this time, you need to return to the original version. You can use "git reset --soft" and "git reset --hard":

git reset --soft：

Only roll back to the specified version A. After using this command, the local warehouse will roll back to version A. After version A, all submissions in the local warehouse will be invalid, which is equivalent to the situation when the local warehouse directly rolls back to version A. ——Note that it is a local warehouse, and the local branch still retains the previous modification content to facilitate resubmission

However, the remote warehouse still retains the latest version, but because the local and remote warehouses are first updated to be consistent, and then "git reset --soft" is used, there will be no conflicts when pushing to the remote warehouse again - if there is Someone submitted something, just pull it at this time

After using this command, the local warehouse rolls back to version A, but still retains the local modifications made at the latest commit. These modifications have not been submitted to the local warehouse, so it is also called "soft" rollback. At this point, you can commit and push again according to the normal process

git reset --hard：

Roll back the local repository to version A, and delete all locally modified content. Also known as a "hard" fallback, since locally modified content is cleaned up, at which point the code can only be rewritten

Rollback process:

1. Use git log to view the commit version record:

Carefully select the specified version that needs to be rolled back to. Since the locally modified content will be retained in soft, it is usually just a rollback to the previous version of the most recent submission record - you can also specify freely according to the specific situation

2. Use "git reset --soft" to roll back to the specified version, but keep local modifications:

git reset --soft acf6abf01d622a89dd14db10a7d03ae842ec9b4f

 Use "git reset --hard" to roll back to the specified version, but do not keep local modifications:

git reset --hard acf6abf01d622a89dd14db10a7d03ae842ec9b4f

After executing the above "git reset" command, you can enter "git log" to check the current version and find that it has rolled back to the target version

3. Use commit again to submit the local modification to the local warehouse, and then push to the remote warehouse.

Since the local warehouse is first pulled to the latest version B , and then "git reset" is used to roll back the local warehouse to version A , and then the local warehouse becomes version C after re-committing, so when re-push to the remote warehouse at this time, you need to pull it first , and the pull at this time is to update the other modified content (if any) of the remote warehouse to the local warehouse on the basis of the local warehouse version C.

PS: Since the local warehouse already has version B of the remote warehouse before "git reset", so re-pulling at this time will not overwrite version C with version B. But if the remote warehouse has other new submissions after version B, then only these submissions will be updated to the local warehouse - and this is the normal version update content, just follow the usual process

3. The role of "core.autocrlf" in git

When developing projects across platforms, due to the difference in line breaks between windows, mac, and unix systems, files will be significantly different when pushed to the remote:

 When installing "git for windows" on the windows platform, "core.autocrlf = true" will be turned on by default:

Points to note:

1. In order to ensure the consistency of cross-system development , and the default core.autocrlf setting of git for windows itself, the remote warehouse always uses "LF" as the newline character instead of "CRLF"

2. Do not change "core.autocrlf" at will. When closing core.autocrlf and then reopening "core.autocrlf = true", you need to delete the original file and re-clone or generate it to make "core.autocrlf = true" take effect - delete the original file and re-clone, this One step is very troublesome, so don't modify the "core.autocrlf" parameter easily

3. After installing git for windows on the windows platform, "core.autocrlf = true" will be enabled by default, so you can ensure that the push to the remote warehouse is "LF" line break, and it is "CRLF" during local checkout development . —— It is completely insensitive and does not affect any development process, which is one of the reasons why it is not easy to modify the "core.autocrlf" parameter.

Summarize:

With the help of the default settings of git for windows on the windows platform, "core.autocrlf" does not require any additional settings and has no impact on the development process. Therefore, there is usually no need to modify this parameter

However, if the current "core.autocrlf = false" in the windows platform, then it needs to be reopened, and it will not take effect until the local file is deleted and cloned again

PS: Other common commands of Git

git branch:

列出本地所有分支，当前所在分支以“*”标出： git branch

在本地创建新分支： git branch 分支名

删除指定的本地分支：git branch -d 分支名



git checkout:

切换到本地的指定分支：git checkout 分支名
(1.如果本地没有该分支，但是远程仓库有该同名分支，那么在使用“git checkout 远程仓库同名分支”后，会
直接在本地仓库创建一个同名的分支，并且自动将远程仓库同名分支和本地仓库同名分支关联起来
2.如果在使用“git checkout 分支名”前，本地仓库已经有该分支，那么此时使用“git checkout 分支名”后只会切换到本地仓库该分支，并不会自动与远程仓库同名分支关联起来。所以后面要push或者pull时都需要在TortoiseGit工具面板中手动重新选择远程仓库指定分支才可
)

创建并切换到本地指定分支：git checkout -b 分支名



git push: 

删除远程仓库的指定分支：git push 远程仓库别名 :远程分支名
                      git push 远程仓库别名 --delete 远程分支名


git config:

查看git配置信息：git config --list

查看用户名：git config user.name

查看邮箱：git config user.email

设置全局用户名：git config --global user.name "xxx"(输入你的用户名)

设置全局邮箱：git config --global user.email "xxx"(输入你的邮箱)

The Complete Works of Git Commands: Git Commands Complete Collection - Brief Book