Today’s sharing started, please give us more advice ~
How to configure your local Git environment and pull code?
1. Download Git and select your own version to download it.
2. Generate the SSH key on your PC, open the terminal, and run the ssh-keygen -t rsa -c “your internal email address” command. If the command is executed successfully, switch to the ~/. Copy the contents of id_rsa.pub.
Go to Settings -> SSH and GPG keys and run cat to check the contents of the id_rsa.pub file. Then copy the file and click Add SSH key. This step is equivalent to hosting your public key on Github.
4. Configure git user name and email globally
git config –global user.name “xxx”
git config –global user.email “[email protected]”
Git will use your local private key and the public key of your remote repository to verify whether it is a pair of secret keys. Thus simplifying the operation process.
Introduction of git
Before introducing git related operations, I feel it is necessary to understand the origin of Git and what problems git is designed to solve.
Git (pronounced /gɪt/) is an open source distributed version control system that can handle version management of projects from the very small to the very large efficiently and quickly. Linus Torvalds, who I’m sure you all know, is the inventor of the open source Linux system. Most servers you see today actually run Linux, and it’s amazing that this god-like programmer didn’t just create Linux. So how does Linux code manage that?
Before 2002, volunteers from around the world sent source code files to Linus via Diff, and Linus merged the code by hand! You know, the amount of Linux code at that time has been very large, through the way of manual management, one is prone to error, the second is low efficiency. Linus chose a commercial version control system, BitKeeper, which BitMover, the owner of BitKeeper, licensed to the Linux community for free out of humanitarian concern.
Eventually, for some reason, BitMover took back free access to the Linux community, so Linus spent two weeks writing his own distributed version control system in C, and that’s where Git came in.
Git’s workspace and workflow
To understand how Git manages our code, the first step is to understand how git’s workspace is structured. Until you understand the composition of git’s workspace, you can use the right commands in the right areas. The figure below shows git’s four workspaces and some common operations.
Workspace: a place where changes are usually made, where the latest content is currently seen and the operation of the workspace is performed during the development process.
Git add marks the contents of your workspace that are managed by Git. If you need to commit code after completing a requirement or function, the first step is to commit it to the staging area using git add.
Repository: a local Repository that is located on your own computer and will be accessed by committing the contents of the staging area via git commit.
Remote: a server used to host code in a Remote repository. The contents of the Remote repository can be modified by collaborative local repositories distributed in multiple locations. After the code is modified in the local repository, the code is synchronized to the Remote repository through git push command.
In general, git’s workflow is divided into the following steps:
-
Develop, add, and modify files in the workspace.
-
Place the modified file in the staging area.
-
Submits files for the staging area to the local repository.
-
Push changes from the local repository to the remote repository.
Git Basic Operations
git add
Adds a file to the staging area, which can be followed by multiple files, separated by Spaces
git add xxx
Adds all currently changed files to the staging area.
git add .
git commit
# Submit temporary changes, a new editor will be opened for editing
git commit
Commit the temporary changes and record the remarks
git commit -m “you message”
Git add. && git commit -m
git commit -am
This operation modifies the hash value of the last commit
git commit –amend
git pull
Git pull = git fetch && git merge
Git pull < remote host name > < remote branch name >
# use rebase to merge
Git pull –rebase < remote host name > < remote branch name >:
git fetch
Unlike Git pull, git fetch only pulls remote changes and does not automatically merge. Has no effect on your current code.
Get updates for a specific branch of the remote repository
Git fetch < remote host name >
Get updates for all branches of the remote repository
git fetch –all
git branch
Create a local branch without switching
git branch
# View local branches
git branch
# View remote branches
git branch -r
# View local and remote branches
git branch -a
# delete local branch
git branch -D
Rename the branch
git branch -m
A problem solving scenario using Git at work
Git rebase makes your commit records more legible
Git rebase
Rebase is similar to merge. It is used to merge changes made in one branch into the current branch.
The following figure shows how the commit history has changed before and after rebase.
Now let’s use an example to illustrate the above process.
Suppose we now have two branches, one for master and one for feature/1, and they both check out branches based on the initial commit add readme. After that, the master branch adds 3.js and 4.js files, and commits twice respectively. Js and 2.js files are also added to feature/1, corresponding to the following two submission records respectively.
In this case, the submission record of the corresponding branch is as follows.
The master branch is shown below:
The feature/1 branch is shown below
It looks like this in combination
At this point, switch to the feature/1 branch and execute git rebase master. After success, view the record through log.
As shown in the figure below, you can see that the changes of the Mater branch are applied one by one, and then each change of feature/1 is applied one by one, using the last commit of the Master branch as a base point.
Git rebase –continue — git rebase — git rebase — git rebase — git rebase — git rebase — git rebase Git rebase –skip complete the rebase. If you don’t want the result of a rebase, use Git rebase –skip to skip the rebase.
Git merge git rebase
Unlike Git rebase, git merge produces an additional merge record that is not fast-forward, similar to a commit message for merge branch ‘XXX’ into ‘XXX’.
In addition, when resolving conflicts, merge can resolve only one conflict, which is simple and crude, while rebase can resolve conflicts over and over again.
Git Rebase interaction mode
In development, it is common to encounter many invalid commits on a branch. In this case, the interactive mode of Rebase can compress multiple commits into a single commit and get a clean commit history. For example, the commit history of a branch is as follows:
The way to enter interactive mode is to execute:
git rebase -i
The base-commit parameter specifies the base commit object for the operation, based on which the rebase operation is performed. For the commit history example above, we want to compress the commit before the last commit object (AC18084) into one commit. We need to execute the following command:
git rebase -i ac18084
You will enter a Vim interactive page with the editor listing information like the following.
To merge these changes, we use a squash strategy, which combines the current COMMIT with its previous commit, roughly as follows.
After modifying the file, press: and then wq to save and exit. A new editing page will pop up. Git branch is used to rebase the commit. Git branch is used to rebase the commit. Git branch is used to rebase the commit. The rebase operation makes our commit history clearer.
Note that rebase operations can only be performed on the feature branch you use, not on the integration branch, because such operations will modify the history of the integration branch.
Use git cherry-pick to get the specified commit
Git cherry-pick is a “pick” commit. Unlike merge, which merges all commits in a branch, git cherry-pick takes a single commit from a branch and introduces it to your current branch as a new commit. Git cherry-pick is used when we need to merge a commit from another branch locally, if we don’t want to merge the whole branch but want to merge a single commit to the current local branch.
In the following scenario, there are three branches: Feature /cherry-pick1 and feature/cherry-pick2 are two functional branches drawn based on the master, and the corresponding branch log is as follows:
The master branch commits as follows:
Select feature/cherry-pick1 and feature/cherry-pick2 from ‘fix’; select feature/cherry-pick1 from ‘fix’; At this point the cherry-pick command can be used.
Git cherry-pick [commit-hash]
Commit-hash indicates the hash value of a commit. Git cherry-pick e0bb7f3 git cherry-pick c9a3101 git cherry-pick e0bb7f3 git cherry-pick c9a3101 Git cherry-pick –continue
At this point, the required commit is applied to the master branch and we have the desired effect. Git cherry-pick: git cherry-pick: git cherry-pick: git cherry-pick: git cherry-pick Git cherry-pick | git cherry-pick | git cherry-pick | git cherry-pick | git cherry-pick , which indicates that commits including first-commit-id through last-commit-id will be merged.
Use Git Revert to roll back a commit
Imagine a scenario where you have two recent releases coming out, and these two releases are accompanied by bug fixes. At the beginning, you fix the bug in the release branch of the first release, and suddenly, the day before the release, the test team says, You need to change the bug fixes from the first version to the second version.
At this time, the integration branch of the first version should include the functionality content of the first version, the legacy bug fix commit and the content submitted by other colleagues. It is definitely not possible to remove the commit of the previous bug fix by means of reset. At the same time, this method is dangerous. What if we don’t want to break the commit record, but we want to undo the commit record for our remaining bugs? Git Revert comes in handy.
Git Revert Reverses an operation that does not modify the original commit record, but adds a new commit record to cancel the operation.
Git revert applies to common COMMIT
Git revert -m Commit for merge
To understand this command, use an example, as shown in the figure below. Suppose that the red box is a bug causing commit, and that his commit is followed by two more commits, including those of other colleagues.
If you want to remove the bug, run Git REVERT 1121932, and then open the log again, as shown in the following figure, you can see that a new COMMIT record has been added. The previous commit record does not disappear, and the code rollback effect is also implemented.
Git Revert can also roll back multiple commits.
Git revert [commit-id1] [commit-id2]… Note that this is an open before closed interval, meaning that commit1 is not included, but COMMIT2 is included.
There are two ways to rollback a commit. You can also use git reset to undo your commit.
Git Revert will create a commit message to undo the changes.
Git reset returns the commit directly to the specified COMMIT.
For individual feature branches, you can use git reset to roll back the history, and then use git push –force to push the history to the remote branch. However, it is not recommended to use git reset directly on multiple collaborative integrated branches. Instead, use the more secure Git Revert command to undo the commit. In this way, the submitted history is not erased and can be safely withdrawn.
Use git Stash to temporarily store files
There is a scenario where you are now developing new features on your feature branch. At this time, there is a bug in the production environment that needs to be fixed urgently, but you have not finished developing this part of the code and do not want to submit it. What should you do? Then switch to the Hotfix branch to fix the bug. When the fix is complete, switch back to the feature branch to restore the content just saved from the stack.
The basic commands are as follows:
Here’s a closer look at stash’s command through a few diagrams.
At this point, I’m working on a new feature that changes the contents of the 1.js file.
I have to stop development and switch to the Hotfix branch, but I still have some content in my workspace. If I switch branches, Git will report the following error.
A file has been modified in your workspace and cannot be committed. You need to commit it or stash it.
Saved working directory and index state WIP on stash: 22e561c feat: add 1.js
At this point, our workspace is clean and we can switch to the Hotfix branch to fix the bug. Assuming that we have finished fixing the bug, we can continue to switch back to the feature branch to develop the original function. At this point, we only need to execute git Stash pop. The changes we temporarily saved will be restored to the workspace, as shown below:
When we want to temporarily store files and switch branches to do something, we can use git Stash to help.
It is recommended that when using stash commands, do not directly use git stash command for staging, but use git stash save “message…” This is a way to keep track of the commit so that when you want to apply changes, you have a look at all the staging lists through the Git Stash list. After that, it is recommended to use git stash apply stash@${num} to apply the corresponding Stash. In this way, the list of existing Stash items will not be emptied and can be applied to the current workspace. If this temporary stash is not needed, you can manually clear it.
Undo changes for different workspaces
In development, we often need to roll back the code operation, in different work areas, the way to roll back the code is also different. Suppose you want to develop on the Feature/REVOKE branch, as shown below.
Git status check git status.
Currently, our workspace is clean and has not been modified. In this case, modify the code and check the status again. We can see that the 1.js file has been modified.
If you want to undo the 1.js file, use the git checkout — command. If you want to undo multiple files, separate them with Spaces, as shown in the image below.
Git reset will revoke all files in the staging area, as shown in the picture below. The file was finally successfully withdrawn to the workspace.
Configuring git aliases improves work efficiency
Git branch, Git checkout, git pull, and other commands are needed to create a branch for development. After the operation, the development is completed and the code is submitted. Git add, git commit, git push etc. Git add, git commit, git push etc. Git add, git commit, git push etc.
Git config –global alias.< simplified character > primitive command
Here’s an example:
Co means checkout, CI means commit, and BR means branch
–global is a global parameter, that is, once configured, these commands can be applied to all warehouses under this computer. Vim ~/.gitconfig, which is used to save the git configuration globally, is used to update your.gitconfig file. The following figure shows the aliases you just added with git config –global Alias.
You can also set the alias by modifying the alias TAB of the file.
To share a common alias setting of my own, replace the following Settings with [alias] in the.gitConfig file and have fun with ~
This way, every time you want to view git history, you don’t have to type a bunch of commands to use git lg
The relationship between branches is clear at a glance, and the merge operation on which COMMIT is performed is clear, helping us trace historical commits and resolve problems.
conclusion
This article explains git environment construction from shallow to deep, basic usage, as well as the use of relatively high frequency git command in the work, whether you are front-end and back-end or other end of the development, daily work is not necessary to use Git, we should not only be able to use, but also use beautiful, flexible, robust.
Today’s share has ended, please forgive and give advice!