1. Git reset head Clears staging. The workspace is not moving
  2. Git checkout filename clears unpending changes in the workspace
  3. Git fetch origin branchname: Branchname Can be used to fetch a remote branch to the local Branchname. If no branchname exists, a new branchname will be created locally
  4. git checkout -b localName origin/remoteName
  5. Git push: Get remoteName to localName and jump to localName
  6. Git branch -d branchName -d branchName -d branchName -d branchName -d branchName [Remote repository name] Empty :[remote branch name] Pushing an empty branch to a remote branch is equivalent to deleting the remote branch
  7. Cannot switch branches if there is data in the workspace or staging area.
  8. Many times, it is useful to know which branch or label each commit is associated with. The –decorate tag makes git log show all references to this commit (branches, tags, etc.). git log –oneline –decorate –graph
  9. The –merged and –no-merged options are available. Git branch –merged(–no-merged)
  10. Git Checkout fails to branch if the current workspace or staging area conflicts with the branch of Git Checkout. For example, if the current branch is master, the transaction record is 1-2-3-4-5. If there is any uncommitted content in the current workspace or staging area, the switch fails. Because the content in the current workspace is modified based on version 5, but the switch to dev branch does not have version 5, so the switch fails.
  11. stash list
  12. stash drop
  13. Git push origin < branch name > –force Rollback required on the local git reset –hard < version number to be rolled back to (just enter the first few digits) > // Note that using –hard will discard the changes in the current workspace. // Using –soft will roll back to the previous version but keep the changes in the current workspace

Git push origin < branch name > –force

Example: Suppose you have 3 commits as follows:

Commit 3 commit 2 commit 1

Git reset –hard HEAD~1 you will find that the HEAD is now at commit 2.

Then use git push –force to push the change to the server. The last false commit on the server disappears completely.

It is worth noting that this type of operation can be dangerous. For example, if someone submits a new COMMIT 4 after your commit 3, that person’s commit 4 will disappear after you force it. Reset deletes the original commit, whereas Revert treats a rollback change like a new commit commit5. Push requires pull and merge code first, so no commit4 is lost

One day you will encounter the following problems.

(1) What should I do if I submit the code in a hurry and find a problem when I go online? Roll back.

(2) There is no problem after the code test, but when I go online, I find that your modification affects the previously normal code and reports an error, which must be rolled back.

These are common problems in development, so git’s uncommit, rollback, or even going back to the previous version is especially important.

It can be roughly divided into the following two situations:

1. No push

This happens in your local repository. If you add and commit, you find something wrong with your code and are ready to cancel the commit, use the following command

reset git reset [–soft | –mixed | –hard

There are three common types

–mixed

The source code is retained, but git commit and index information are reverted to a version.

Git reset defaults to –mixed mode git reset –mixed is equivalent to git reset

–soft

Keep the source code and only back up to commit information to a certain version. Index rollback is not involved. If you still need to commit the index, you can commit it directly.

–hard

The source code is also reverted to a version,commit and index are reverted to a version (note that this is done by changing the local repository source code).

Reset –hard <commit… < span style = “max-width: 100%; clear: both; min-height: 1em; box-sizing: border-box! Important

So, in this case, you should use the following method

2. Have a push

If you’ve pushed your code to an online repository, you want to roll back your local code and you want to roll back your online code to a specific version, so that your online and offline code are consistent. You will need to use the following command

revert

Git Revert is used to reverse a commit, and the evert command requires that the working tree be clean.

Git Revert uses a new commit to undo any changes made to a historical commit.

After you revert, your local code will roll back to the specified historical version, and you can git push to update the existing code.

To revert, you need to find the unique commit identifier for the version you want to rollback using git log or the AdGit web commit history.

Git revert c011eb3c20ba6fb38cc94fe5a8dda366a3990c61 usually, top can

git revert c011eb3

Git revert allows you to use a new COMMIT to rollback the previous commit. Git reset deletes the specified commit

The effect seems to be the same, but it’s completely different.

The first:

If you have pushed to an online repository, reset deletes the commit specified, and you git push can cause a bunch of conflicts. But revert does not.

The second:

If the existing branch and the history branch need to merge later, the reset part of the code will still appear in the history branch. However, a COMMIT submitted by revert does not appear in the history branch.

The third:

Reset removes the specified commit from the normal commit history, and the HEAD is moved backwards. Revert commits again from the normal commit history, and its HEAD is always forward.

The reset parameter handles the commit version number, which can also be a remote branch name such as Origin or master

The current branch tracks the remote branch. Git branch -u origin/ Feature_yousong_417 -u is short for –set-upstream

Check the relationship between the remote branch and local branch git branch-vv

git pull origin master:master

FETCH_HEAD is a short-lived ref, to keep track of what has just been fetched from the remote repository. git pull first invokes git fetch, in normal cases fetching a branch from the remote; FETCH_HEAD points to the tip of this branch (it stores the SHA1 of the commit, just as branches do). git pull then invokes git merge, merging FETCH_HEAD into the current branch.

The result is exactly what you’d expect: the commit at the tip of the appropriate remote branch is merged into the commit at the tip of your current branch.

This is a bit like doing git fetch without arguments (or git remote update), updating all your remote branches, then running git merge origin/, but using FETCH_HEAD internally instead to refer to whatever single ref was fetched, instead of needing to name things.

Brew install git-flow-avh

Git config –global alias.pmmm ‘! git pull origin master:master && git merge master’

Git remote branch Git branch -a Check all branches. Git branch -r Check all branches. Git remote show origin Check details about remote branches -a indicates the remote branch that no longer exists. Git remote update origin Refreshes the local list of remote branches.

Git tag -a v1.4 -m ‘My version 1.4’ git tag v1.4-lw Create a tag on commitId Git show v1.4 push tag: git push origin v1.5 checkout tag:

Git checkout -b version2 v2.0.0 Switched to a new branch'version2'
Copy the code

Git rm file_path Git rm file_path git rm file_path git rm file_path git rm file_path git rm file_path Git rm –cached file_path file_path is the file path

Commonly ignored files github.com/github/giti…

The.gitignore file is valid only after the commit. You can delete the files in the staging area using git rm –cached file_path.

Existing code is pushed to Github

Git adds multiple remote repositories.

Git remote add <name> <url> git remote add <name> <url> Git push <name> <branch> where name means the name you gave it in the previous step and branch means a branchCopy the code