Git commit commit error

When errors are found after the commit, the simple and straightforward method is to modify the code and commit the second time.

Git log can see the information of two commits

Other ideas

If you haven’t pushed your commit to a remote repository, you can reset your commit version to the hashid of your Git log.

git reset

Git reset - mixedCopy the code

Git reset this is the default git reset with no parameters. Even if git reset is the default git reset, it reverses back to a version with only the source code and the commit and index information

Git reset - softCopy the code

Rollback to a version, only the COMMIT information is rolled back, but the index file level is not restored. If you want to commit, simply commit

Git reset - hardCopy the code

If you go back to a version completely, the native source code will become the content of the previous version

Modifying Remarks

git commit -amend
Copy the code

---

How to add ignored files or directories correctly at the start of a project/project?

Ignore files

Git rm — git rm

When we need to delete a file on the staging area or branch, and the workspace does not need the file, we can use it

git rm file_path
git commit -m 'delete somefile'
git push
Copy the code

When we need to delete a file on the staging area or branch, but we need to use it locally, we just don’t want the file to be versioned, we can use it

git rm --cached file_path
git commit -m 'delete remote somefile'
git push
Copy the code

Ignore a directory that has been traced (never again) :

git rm -r --cached dir
echo dir/ >> .gitignore
git add .gitignore
git commit -am 'ignore dir forever'
Copy the code

How to create a shortcut for git command?

git alias
Copy the code

The first way

By configuring Git itself:

git config --global alias.s status
Copy the code

Git s is git status

The second way

vim ~/.gitconfig
Copy the code

Third method: Configure the alias of the system

vi ~/zssrc
Copy the code

Git stach: What is git stach?

Git Stash is used to hold ongoing work, such as when you want to pull the latest code without adding a new commit, or in another case, To fix an urgent bug, stash first and return to your previous commit. After fixing the bug stash pop and continue with the original work.

Basic commands

$git stash
$do some work
$git stash pop
Copy the code

The advanced

   git stash save "work in progress for foo feature"
Copy the code

When you use the ‘git stash’ command multiple times, your stack will be full of uncommitted code and you will be a little confused about which version to apply back.

With the ‘git stash list’ command, you can print out the current version of your git stack. For example, with the ‘git stash apply stash@{1}’ command, you can take out your stash@{1}. When you apply all stacks back, use the ‘git Stash Clear’ to clear the stack.

git stash          # save uncommitted changes
# pull, edit, etc.
git stash list     # list stashed changes in this git
git show stash@{0} # see the last stash 
git stash pop      # apply last stash and remove it from the list

git stash --help   # for more info
Copy the code

Git rebase is a git rebase.

The concept/function of rebase is very simple — it is “rebase”. Specifically, changing the “base point” of a branch causes the original branch to grow back at the specified place (commit). And, because it is a new branch, you can arbitrarily change the commits, which are rewriting branch history.

The main purpose of Rebase is to simplify.

Here are the key steps:

git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]    [<upstream> [<branch>]]
git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]    --root [<branch>]
git rebase --continue | --skip | --abort | --edit-todo
Copy the code

All rebase action objects are commit. (You can rebase a branch git rebase -i branchX, but it still works on the branch’s latest commit.)

After rebase is initiated with this commit as the “new base point,” a Commit history is printed out for you to modify.

The most common modification is to change the pre-commit pick to S (/ SKW ɔ /), which preserves the commit’s changes but deletes the object, giving it only a chance to be named. (In technical terms — do not keep historical information on the branch to be merged, and do not commit or move the HEAD.) Multiple commits prefixed with s are eventually consolidated into a single commit, and the descriptions of each commit are consolidated.

The ultimate modification is simply to delete commit(s) — tampering with history. This means that the corresponding changes are also dead. (So why rebase is a dangerous operation is because it falsified history! Think what happens if someone forks based on your official history and you become gay!)

After the change 😡 (Vim save exit command), Git will detect the conflict, which is similar to merge. Merge will repeat the history of the commit(s) you left, and you can modify the specific code for each commit. And if you’re not trying to modify, you’re just trying to simplify the tree… My solution was to just leave a COMMIT and completely override the latest project to resolve the conflict. (I don’t know if there’s a better way)

Git rebase –continue once the conflict is resolved, you can officially “write” history by writing a new commit description. At this time that really, want to write how to write ~

When this local rebase is complete, remember git push -f, which is used to force the new history to be pushed to the remote repository. At this point, rebase is completely over.

Look at your new tree, isn’t it so simple and beautiful? If it were not for… Why are you rebase…)

When a system has enough proper nouns (slang), culture is created.

Git rebase can directly synchronize the logs from git merge when contributing the open source code.

How? What’s the point of labeling?

tagging

Like most VCS, Git can tag versions at a point in time. People often do this when releasing a software version (v1.0, etc.). In this section we will learn how to list all available tags, how to create new tags, and the differences between different types of tags. Lists existing labels

The command to list existing tags is as simple as simply running git tag:

Git tag v0.1 v1.3Copy the code

The labels are displayed in alphabetical order, so the order of the labels does not indicate the importance of the labels.

We can list matching tags with a specific search pattern. Git has more than 240 tags in its own project repository. If you’re only interested in 1.4.2 releases, run the following command:

Git tag - l 'v1.4.2. *' v1.4.2.1 v1.4.2.2 v1.4.2.3 v1.4.2.4Copy the code

The new label

Git uses two types of tags: Lightweight and annotated. A lightweight tag is like a branch that doesn’t change, but is actually a reference to a particular submitted object. The tagged tag, on the other hand, is actually a separate object stored in the repository. It has its own checksum information, including the tag name, email address and date, as well as the label description. The tag itself also allows signing or validation using the GNU Privacy Guard (GPG). It is generally recommended to use annotated labels in order to retain relevant information. Of course, lightweight tags are fine if they are only for temporary tagging, or if you don’t need to marginalize additional information. Labels with annotations

Creating a annotated tag is simple, specifying the tag name with -a:

Git tag -a v1.4 -m 'My version 1.4' git tag v0.1 v1.3 v1.4Copy the code

The -m option specifies the tag description, which Git stores with the tag object. If this option is not provided, Git will start the text editing software for you to enter the tag description.

You can use the git show command to view the version information for the tag, along with the submitted object at the time of the tag.

Git show push_v1.2 Tagger: machuang <[email protected]> Date: Sun Sep 10 12:06:50 2017 +0800 Version 1.2 Project coding end at 2017-8-23. This tag create at 2017-9-10 s commit f1759f45b598611231d9e768 Merge: f8f4 saf9 Author: XScarletAngel <[email protected]> Date: Wed Aug 23 18:30:27 2017 +0800 Merge branch 'branch1.2' of git.du.com:admin/admin into branch1.2 * 'branch1.2' of git.du.com:admin/admin: TestCopy the code

We can see that in the submission object information, the submitter and submission time of this label are listed, along with the corresponding label description.

Label according to CommITID

Git tag -a <tag name > <commitCopy the code

The tag is pushed to the remote repository

By default, Git Push does not transfer tag tags to the remote server; tags can only be shared to the remote repository by explicit command. 1. Push a single tag. The command format is as follows:

git push origin [tagname]
Copy the code

Such as:

Git push Origin v1.0 # push local V1.0 tags to remote serversCopy the code

2. Push all the tags in the following format:

git push [origin] --tags
Copy the code

Such as:

git push --tags
Copy the code

or

git push origin --tags
Copy the code

The above command is verified. If it does not work, please confirm on Git console whether your account has permission to push Tag.