0 x00 is written on the former

For tool learning, first collect as much information as possible from various channels and sort it out. When you apply it, you should do a lot of subtraction, remember only the most useful parts, forget the weird tricks or the dark arts, and put your energy into more valuable things.

Ask 2 questions:

  1. What is the relationship between GitFlow, GitHub Flow and GitLab Flow?

  2. Have you used the Git pull –rebase directive in your own projects?

0x01 Basic Concepts

Start with the three git partitions, all of which appear before committing to the remote repository

  1. Local work directory: is the working directory, that is, on our computer, we can see the file

  2. The code in this area is red when viewed with Git status

  3. Staging area stage: After executing git add, the changes in work dir are added to staging area

  4. The code in this area is green when viewed with Git status

  5. Commit history: When the code is in the stage area, git commit is used. Each commit generates a unique hash pointer and points the HEAD to that pointer

The flow process in the figure above:

1、本地 dir => 暂存区 stage

$git add. $git addCopy the code

Stage => local dir

$git checkout. $git checkoutCopy the code

This operation has some risks: changes made in a.js in the local dir will be overwritten by stage and cannot be recovered. So you need to make sure that operations performed in local A.js can be discarded.

Usage scenario: Switch to code in the Master branch and look at a file. If the file does not conform to the specification that our local ESLint code saves automatically, our IDE will format the file automatically, but we don’t want to commit the change. You can then use the Git checkout directive to restore the file.

3. Temporary area statge => Historical submission area histroy

$git commit -m 'commit message'
Copy the code

If you want to create a new commit to the history section, you can use the following command:

$git commit --amend
Copy the code

This merges the typo changes with the previous commit and commits them to the history section as a COMMIT.

5. Histroy => local dir

In this scenario, I would like to give an extreme example: for example, I clone someone else’s project from GitLab, and then change the code arbitrarily, and then find that my code doesn’t work at all, so I regret, just don’t change, I want to restore to the original appearance, what should I do?

$git checkout HEAD $git checkout HEADCopy the code

0x02 What are common collaborative workflows?

2.1 Central collaborative workflow

I don’t think you know SVN very much anymore. When I was an intern, SVN was still very popular. Git actually works as a central workflow like SVN. Many of our current underlying frameworks also work in this way.

A central workflow would look like this:

  1. Pull code: Execute git pull origin master to synchronize the code down

  2. Commit code: run git add. && git commit to add code to the cache

  3. Push code: Execute git push Origin master to push the code to the remote repository

If the push fails at step 3 because someone else has already committed it, here’s the synergy part:

Git pull –rebase to merge the commit from the server directly into your code, but this is not done yet.

Git does this:

  1. Put your locally committed code aside for a moment.

  2. Then download the changes from the server.

  3. Then commit your changes locally, one by one, until they are all successful.

As shown in the figure below. Git will download the origin/feature/v3.2.0 remote branch (purple) and commit the local feature/v3.2.0 branch one by one (blue).

The final effect is shown below:

Git push Origin feature/v3.2.0

Git rebase –continue if there is a conflict, you need to resolve the conflict first and then do git rebase –continue, as shown in the following figure. When Git does pull –rebase, it applies the locally committed code one by one. If there is a conflict, it will stop and wait for you to resolve the conflict.

2.2 Collaborative workflow of functional branches

Central collaborative workflows are only suitable for 2 or 3 people, and everyone is developing on the trunk.

The common collaborative workflow development process of “functional branch” is as follows:

  1. Git checkout -b new-feature git checkout -b new-feature

  2. The programmers who co-developed the feature then work on the branch, doing add, COMMIT, and so on.

  3. Git push-u origin new-feature is used to push the branch code to the server.

  4. Other students can get the latest branch code by git pull –rebase. Finally, Code Review was completed through Pull Request and merged into the Master branch.

In fact, this form of development is also centralized, but server-centric, using branches to achieve code isolation.

If a project branch is opened for a long time, the more difficult it is to merge back. This method of functional branch is also for us to break a huge project into several small projects for implementation. Git best practices encourage quick commit, quick merge, and quick completion. That’s a lot less conflict.

2.3 GitFlow collaborative workflow

The above approach still does not meet our actual needs because there is only one master branch. We need to maintain the code on the line while constantly developing new code, hence the following requirements.

  1. You want to have a branch that is very clean, where the code is releasable and changes are always releasable to production. There can be no code submitted on this branch that is not above the production line during intermediate development.

  2. For code that has been released, there are often bug-fixes that do not commit the code under development to the production line.

The above two points lead to a concept: environment

To solve these problems, GitFlow collaborative workflow comes out. GitFlow synergy workflow was highlighted by Vincent Driessen in the 2010 article A Successful Git Shoot Model.

There are five branches in the code path:

  1. The Master branch. The trunk branch, which is used as a publishing environment, is publishable for every commit.

  2. Feature branch. The functional branch, which is used to develop functionality, corresponds to the development environment.

  3. Developer branch. Is the development branch, once the feature development is complete, merge to the Developer branch, once the merge is complete, delete the feature branch.

  4. The Release branch. When the Developer branch is ready for Release, issue a Release branch and do the pre-release work. This branch corresponds to the pre-release environment. The Release branch was needed so we could move forward. Once the code on the Release branch is ready to go live, the Release branch needs to be merged with both the Master and Developer branches to ensure code consistency. Then delete the Release branch.

  5. Hotfix branch. Hotfix is used to process bug-fixes for code on the production line. Each bug-fix of code on the production line needs to open a Hotfix branch. After completion, it is merged to the Developer branch and Master branch. After the merge is complete, delete the Hotfix branch.

The core process is shown in the figure below :(I found a picture on the Internet, but I couldn’t draw it.)

Based on this workflow, what you need to do is:

  1. The Master and Developer branches need to be maintained for a long time.

  2. There is some complexity to this approach, especially since the Release and Hotfix branches need to merge into both branches. So, without a good tool to back it up, we might forget to do something and cause code inconsistencies

  3. GitFlow synergy although workflow is heavy. But it can handle almost any company’s development process.

2.4 GitHub/GitLab collaborative workflow

Is there a problem with the GitFlow workflow? After all, it’s been 11 years. But there’s a lot of teasing going on in the industry:

  1. GitFlow considered harmful | End of Line Blog

  2. A real-life git workflow. Why git flow does not work for us – Lucian Sabo

The above two pictures is in my article GitFlow considered harmful | End of the Line harvesting in the Blog, the main problem is that too many branches. The result is the situation shown in Figure 1 above.

  1. So many layers

  2. Too many branches crossing

Git flow uses git merge –no-ff to merge branches. If you have multiple branches in a git-flow environment, your branch management log will become ugly. As shown below, on the left is the problem with the -no-ff parameter under multiple branches.

The –no-ff parameter means no fast forward. That is, the merge method does not commit the branch as a pre-merge, but instead leaves a merge commit. It’s a double-edged sword, and we want our — no-FF to be like the right-hand side, not the left-hand side.

The recommendation is to use the –no-ff parameter only when the feature is merged into the Developer branch, and not use the –no-ff parameter for all other merges.

At the beginning, GitLab was a firm supporter of GitFlow. Later, due to people’s dissatisfaction with GitFlow, GitLab created a new workflow: GitLab Flow, which is based on GitHub Flow.

Against 2.4.1 making Flow

GitHub Flow is also called Forking Flow, which is the development method on GitHub. Those of you who regularly contribute code to Github will be familiar with the words fork and PR.

GitHub workflow:

  1. Each developer forks the code from the “official library” into their own repository.

  2. Developers then do whatever they want in their own code repository.

  3. Therefore, developers need to have two remote repositories in their code base, one for their own library and one for the official library (the user library for submitting code changes, and the official library for synchronizing code).

  4. You then build a “functional branch” locally and do code development on that branch.

  5. This branch of functionality is pushed into the developer’s own code repository.

  6. Then, make a pull request to the “official library” and do a Code Review. Once approved, it merges into the official repository.

If you have access to the “official library”, you can build branch development directly in the “official library” and submit the pull request. After Code Review, merge into the Master branch, and the Master can release the merged Code as soon as it has been merged

An aside:

If you are involved in open source Code merging often, you should be familiar with some Code Review jargon:

1, LGTM: Looks Good To Me, I agree To merge the code into the remote repository. Out of Acknowledgement is i.e. agreed/accepted change. 5, RFC: I.e. disagree with change and/or concept “Request For Comments” i.e. I think this is a good idea, lets discuss 6, WIP: 1. You can submit part of the document, title or Tag with WIP, to indicate that it has not been completed. As Far As I Know/As Far As I Know/As Far As I Know/As Far As I Know IANAL: I am not a lawyer, but I smell licensing issues If I Recall Correctly. 11, In My Opinion, I have to work hard. DR: Too Long; README documents are common. 14, PTAL: Please Take A Look. 9, Have you Reviewed them? 9, Have you Reviewed them? To Be Done (or Defined/Discussed/Decided/Determined). “do not completed, will Be” different meanings differ according To the context, but basically it haven’t Done. TBH: To Be Honest with you, I’m at the ATM at the moment. I’m impressed by the amazing programming skills on display in this PR. Ifr means to continue developing on a piece of unmaintainable shitty code without refactoring 💩 R

2.4.2 GitLab Flow

GitHub Flow is still a bit of a problem, because it’s very simple, but it doesn’t tie our code to our environment. Therefore, GitLab proposed several optimization points.

1. Introduce the environment branch, as shown in the figure below, which includes the pre-production and Production branches.

2. Sometimes we will have different releases, so there will be branches of releases. As shown in the figure below. The Master branch is a roadmap branch, then, once stable, build stable versions like 2.3.stable and 2.4.stable, which can cherry pick changes on the Master branch.

This solves two problems:

  1. Environment and code branch issues;

  2. Issues related to versions and code branches;

After reading a lot of articles about workflow, I concluded that for Internet companies, environment and code branch correspond to this matter. As long as there is a good CI/CD production line, such environment branch should not be necessary. As for versioning and branching, I think this should make sense, but it is best not to maintain too many versions, versions should be short-lived, and old versions should be removed when new ones are released.

2.5 The nature of collaborative workflow

The essence of collaborative workflow is not how to play the branch strategy of the code warehouse, but how to play our software architecture and software development process.

There are four issues to consider when working together:

  1. Different teams can develop in parallel as much as possible.

  2. Consistency across versions and code.

  3. Consistency across environments and code.

  4. Code always alternates between stable and unstable. We want code on the production line to always correspond to stable code

There is no silver bullet for collaborative workflow, and when the above conditions can be met, we just need to choose what works for us.

0x03 Productivity Tips

3.1 instruction

3.1.1 Hors d ‘oeuvres: Enable global error correction

Everyone makes typos from time to time, but if you enable Git autocorrect, you can have Git autocorrect some of the mistyped subcommands.

$git config --global help.autocorrect 1
Copy the code

Efficiency improvement:

  1. Before autocorrect: only suggestions are given for you to re-enter the command (case 1 above)

  2. After automatic error correction is enabled: The system not only provides a suggestion, but also outputs the print result corresponding to the first suggestion (case 3 in the figure above is the print result of the normal input of status) to avoid re-entering the command

3.1.2 View a file on another branch

Sometimes, you’ll want to browse through the contents of a file in another branch. This can be done with a simple Git command, without even having to switch branches.

$git show main:README.md
Copy the code

Efficiency improvement:

  1. There are two fewer branch switches (cut past, cut back) and no need to temporarily store the current code (git stash) and then restore the current code (git stash pop). You can directly see what happens to a file in a branch.

3.1.3 Login with Multiple Accounts

The concept of git config scope is introduced here

Git config $git config --list [email protected] user.name=hello help.autocorrect=1 # $git config --global user.email $git config --global user.email "[email protected] $cd myProjectDir $git config user.name "lisi" $git config user.email "[email protected]"Copy the code

3.1.4 Temporary git stash code

Staging area, rational use of staging area will greatly improve the efficiency of our parallel development, can let everyone in each project freely shuttle 💃🏻

Usage Scenarios:

Sometimes when you’re working on a new feature in the Dev branch and someone comes along with a bug and asks you to fix it right away, but when you’re working on a new feature and you don’t want to commit it, you can use the Git Stash command to save the progress and then switch to another branch to fix the bug. After making the commit changes, we cut back to the dev branch and use git Stash pop to resume development.

Common instructions:

$git stash pop $git Stash clear $git stash clearCopy the code

Efficiency improvement:

Upgrade the usage of the above three common instructions:

# git stash can be added with the save command, $git stash pop --index 3 $git stash pop --index 3 The drop command removes a specified version of the $git stash dropCopy the code

It can be seen that when stash instruction is directly executed, a large number of WIP is on master, and the following information is the commit submitted last time. The function differentiation is not clear, and there is no way to distinguish the specific function changed.

Git branch — set-uppage-to

$git branch --set-upstream =origin/masterCopy the code

Here’s an example:

I’m going to associate a local branch master with the remote repository origin branch master, either way. But method 1 is more general, because your remote library may not have the master branch, in which case method 2 is not feasible, even the target branch does not exist, how to associate?

To sum up:

Git branch –set-upstream =origin/master

Improve efficiency:

In future development, you can use Git push -u Origin new_branch for the first time you name a longer branch and then execute git push directly on that branch to improve efficiency.

The config file can be viewed in the.git folder:

[branch "master"]
        remote = origin
        merge = refs/heads/master
[branch "new_branch"]
        remote = origin
        merge = refs/heads/new_branch 
Copy the code

3.1.6 Git revert and Reset

Revert (to do)

Usage Scenarios:

Git revert is used to “reverse” a version in order to undo changes made to that version. For example, we commit three releases (version 1, version 2, and version 3) and suddenly discover that version 2 doesn’t work (e.g. If you want to undo version 2 without affecting a commit to undo version 3, you can use git revert to reverse version 2 and create a new version 4 that retains version 3 but undoes version 2

There are two types of Commit: regular commit and Merge COMMIT, and the two types of COMMIT are different

  1. Regular Revert COMMIT: With Git Revert, git generates a new COMMIT that removes the specified commit from the current branch.

  2. Revert Merge Commit: This is not recommended

Common scenarios:

How do I Revert after Revert?

$git reset --hard commit-hashCopy the code

Reset your mind

** This method can be used if you want to revert to a previously committed version and we don’t want to commit any later versions.

Common scenarios:

1. Roll back the code that has been pushed to the remote repository

$git push -f origin master $git push -f origin masterCopy the code

2. Merge multiple unpushed commits

# there are multiple commits in this history. $git add. $git commit -m 'balabala' # Commit is merged into oneCopy the code

The difference:

The biggest difference between the two is that reset causes the HEAD to revert and revert causes the HEAD to continue forward

3.1.7 Git rebase and Git Merge

Instead of merge, try to understand the rebase instructions that make more sense.

1. Do not use rebase on public branches

Why not use Rebase in a public branch?

Because all of these new commits are new, everyone else that pulls out of this public branch needs to be rebase, so if you rebase things in, they’re all new commits

2. When the local and remote branches correspond to the same branch, rebase is preferred over merge

When using merge, pay attention to the application of the –no-ff parameter described above

Summary: 1. If the local and remote branches are in the same branch, use rebase, merge but do not add –no-ff parameter when handling conflicts. 2. When merging branches, use merge, but be sure to add the –no-ff parameter.

3.2 tools

3.2.1 Git alias

If you are using a command-line tool, you are advised to install iTerm, use ZSH instead of bash, and upgrade oh-my-zsh for style updates and functionality extensions

You can use aliases to reduce the speed of git operations.

$gp='git push'

$gl='git pull'

$ga='git add'

$gaa='git add --all'

$gcmsg='git commit -m'

...
Copy the code

2. Some combined instructions are placed in NPM Script to improve efficiency

# in all submitted records search contains' xgplayer commit $git rev - list - all | xargs git grep -f 'xgplayer' # $git add is not recommended. The && git commit -m 'fast commit' && git pushCopy the code

3.2.2 utility plug-ins in Vscode

Git Graph

View branches

GitLens

  1. Look at the commit record for a line of code

  2. Handling Merge Conflicts

3.2.3 cli tool

commitizen

Help users to output compliant specifications

Husky

Help Commitizen by adding Git hooks to force this action

"husky":{
  "hooks": {
    "commit-msg": "commitlint -e $GIT_PARAMS"
  }
}
Copy the code

0 x04 comprehension

1. Use the command line tool:

As mentioned above, you can spend more time doing more meaningful things, but I recommend using the command line or visual tools to manipulate Git.

  1. I feel like I’m talking to Git: I’m going to pull remote code down, merge it with my local code, and push it to a remote repository.

  2. Similar to Vim, Vim is not only used to improve efficiency, but also hopes that every operation is considered.

  3. You don’t have to switch software, or even Windows, just use the keyboard.

2, the use of tools is also the cost, be sure to simplify:

  1. Familiarize yourself with workflow: For Git, you just need to know which scenarios each Git collaborative workflow is suitable for.

  2. Proficient in basic instructions: don’t waste extra energy memorizing various bizarre techniques, only master the most basic instructions, and know how to use them more efficiently. (for example, add the -u parameter to the first push)

3. Complex workflows must be caused by unreasonable architecture