Git tips you didn’t know about

preface

Why write this article? In fact, I find that many students are not familiar with some very simple and effective git methods. Here are a few git commands with high cost performance combined with their use scenarios.

Post the official documentation so you can learn more about Git

Regret medicine

  • In our daily development, we occasionally accidentally submitted the wrong code, respectively in the workspace, staging area, version library and other scenarios above. Let’s see, what’s a good solution

Application background

1. Imagine a scenario where we have just pulled down the code for debugging and come up with two components that might fit the functional scheme for the product. Let’s try plan A first. At this point, plan A is not feasible, we use plan B, but at this point, plan A already has some code stored in the workspace, how do we deal with it?

The $git checkout filePath // directive clears the workspace. Can perfectly realize the requirements of the scene.Copy the code

2. In the same scenario, what if the code has moved from the workspace to the staging area

$git restore --staged filePath // Instructions can retract code from staging areas into workspaces. The $git restore filePath directive reverses the staging area to untrack the code.Copy the code

3. If we have completed the above scene and made the code submission at last, because our code commit management is relatively rigorous, you accidentally marked several strange symbols in the comments of your submission code, which will not affect the submission record, how should we deal with it

$git commit -- $amend // You can open it directly. After a few additions, deletions and changes to Linux. Exit the folder to complete the second commit, and the Git log is still the HASH value of the last one. No new commit record is created.Copy the code

4. The above are undone in the workspace, staging area, and commit object respectively. So how do we make up for errors in local/remote repositories

  • This is my special introduction to the rollback method, interested students can look at url: # git – Briefly describe the three ‘code rollback’ methods

git cherry-pick

  • Commit records are selected for merging.

Application background

  • Imagine a scenario where you want to add functionality from a newly developed version to a stable version. You can use the cherry-pick command to extract the commit associated with this feature and merge it into the branch of the stable version.

    $git cherry-pick commitHASH filePath $git cherry-pick commitHASH filePath $git cherry-pick commitHASH filePathCopy the code

Compare file version differences

  • In our daily work, we sometimes accidentally put the wrong code in a function code block, and find that the project doesn’t work, and we don’t know what changes we made. In this case, we want to take a look at the current file code and history. How can we do this without the help of plug-ins?

Application background

  • The current file workspace code is compared to the current file history commit record

    Git diff commitHASH filePath $git diff commitHASH filePath Compare the current workspace code with the current file of the historical commit record.Copy the code

  • Compares the current file staging area code with the current file history commit record

    $git diff --cached commitHASH filePath // Compare the current workspace code with the current file of the historical commit record.Copy the code

  • The current file version library code is compared with historical commit records

    $git diff commitHASH commitHASH2 filePath $git diff commitHASH commitHASH2 filePathCopy the code

  • Note: Remove filePath from the above comparison to compare the difference of the whole file under the current project

Code the staging

  • In our daily work, sometimes when we are developing feature A, the product tells you that feature B is urgent, but the code at this time does not constitute a commit. What should we do
  • Use git Stash to store your changed files in your working directory –.git/refs/stash

application

  • Add: stores files that are currently tracked in the staging area but do not constitute a commit

    $git stash // Stores the unfinished changes on a stack where you can reapply them at any timeCopy the code

  • Search: View the temporary indexes that have been stored

    $git stash list $git stash listCopy the code

  • Use: Get the contents of the storage according to stash index

    $git stash apply stash@{index} //Copy the code

  • Delete: Removes stored content

    $git stash drop Stash @{index} : // Drop the stash@{index} store and remove the stash from the listCopy the code

Alias (giant utility

  • On a daily basisgitDoes not automatically infer the command you want when you type part of it. If you don’t want to type it every time

Complete git commands. You can easily set an alias for each command using git config files.

application

  • When querying current log information, typing git status will cause errors

    $git config --global alias.ci commit $git config --global alias $git ci -m "XXX XXX XXX..." / / canCopy the code

  • Configure multiple aliases at a time and modify configuration files directly

    Under Win, you can directly search the global. Gitconfig file location with the everything tool, and modify it in it.Copy the code

Git Workflow

  • In daily work, it is inevitable to design a team for multi-person collaborative development. The collaboration must have a standard workflow, so that everyone can cooperate efficiently and the project can develop in an orderly way. Let’s take a look at three of the more common specificationsGit flow Github flow Gitlab flow

git flow

  • There are two long term branches of the project: the first one is used to store releases, and at any time you get a stable distribution in this branch; The latter is used for daily development and houses the latest development releases.

    - Primary branch 'master' - Development branch 'developCopy the code

  • There are three short-term branches of the project that, once development is complete, are merged into Develop or Master and then removed.

    - Feature branch - Hotfix Branch - Release branchCopy the code

github flow

  • It has only one long branch, the master, so it’s very simple to use. Generally used for open source projects

    - Primary branch 'master'Copy the code

  • The working process

    - Clone to the local branch, do some feature development, bug fix(fix - initiate a pull request operation to the original repository, let him see the bug you modified - the original repository review the bug, if it is correct, It will merge into its own project into 'master'Copy the code

gitlab flow

  • Gitlab flow is the synthesis of Git flow and Github flow. It draws on the best of both worlds, with the flexibility to adapt to different development environments and the simplicity and convenience of a single main branch. It’s recommended by Gitlab.com.

  • Focus on

    The biggest principle of Gitlab Flow is called "upsteam first", i.e. there is only one master branch, which is "upstream" of all the other branches. Only code changes adopted by upstream branches can be applied to other branches.Copy the code

  • Continuous release projects

    For "continuous release" projects, it recommends setting up different environment branches in addition to the master branch. For example, the branch of "development environment" is master, the branch of "pre-production environment" is pre-production, the branch of "production environment" is the development branch is "upstream" of the pre-production branch, and the pre-production branch is "upstream" of the production branch. Code changes must evolve from "upstream" to "downstream". For example, if there is a bug in the production environment, it is necessary to create a new function branch, first merge it into the master to confirm that there is no problem, and then cherry pick to the pre-production step to enter the production. Only in case of emergency, it is allowed to skip upstream and merge directly into the downstream branch. Production.Copy the code

  • Version release project

    For "release" projects, the recommended practice is to pull one branch from the master branch for each stable release, such as 2-3-stable, 2-4-stable, etc., and then only allow code to be merged into these branches if bugs are fixed and minor version numbers are updatedCopy the code

reference

  • Ruan Yifeng Git workflow