Git Learning Notes

Start by understanding several basic concepts:

Origin: Default remote repository;

Master: Default Development Branch;

(1) Git log

View the commit log. will show you every commit.

。

(2) Git log--pretty=oneline

If you think the output above is too miscellaneous, you can use this command. The information is displayed on one line.

。

(3) Git branch

View the current branch. , I am now in the Master branch.

。

(4) Git reflog

Review the commit history to determine which version you want to roll back to. Depending on the previous hash value or head can be rolled back.

。

(5) Git diff file name

Review the comparison before and after you modify a file. Red "-" for Delete, green "+" for insert. The modification process is first removed and then inserted.

。

(6) Git reset--hard 7-bit hash value

Roll back to a version. A 7-bit hash can be found through Git reflog.

。

(7) Cat file name

View the contents of a file.

。

(8) Git checkout--file name

Undo all changes to the file in the workspace, here are two things:

One is that the file has not been put into staging area (that is, git add has not yet been executed), and now the undo changes go back to the same state as the repository;

One is the file modification has been added to the staging area (git add has been executed), and modified, undo the changes back to the state after adding to staging area;

All in all, let this file go back to the state that was recently executed by Git commit or git Add.

Note that the middle "--" is important, without "-" and becomes the "switch to another branch" command.

.

(9) Git reset HEAD file name

Undo the Staging area changes (Unstage) and put them back in the workspace.

The git reset command either rolls back the version or staging area The changes back to the workspace when we use head to represent the latest version.

。

(Ten) git RM file name

Adds a file to the workspace and adds it to the local branch. But if you don't need this file. You delete the file directly with the RM file name. At this point, git knows you deleted the file, so the workspace and repository are different. Git status can see the current situation.

There are two options at this time:

1. To remove the file from the repository, delete it with the command "git rm file name", and Git commit commits, and the file is actually deleted from the repository.

2. Another situation is the deletion of the wrong, because the repository also has the file, so you can delete the deleted files to the latest version, "Git checkout-file name." "Git Checkout" is to replace the workspace version with the version in the repository, which can be "one-click Restore", regardless of whether the workspace is modified or deleted.

。

.

(one) Git remote add Origin ***github warehouse address

Associate a remote repository. Prior to the first commit.

() git remote-v

View the address of the remote warehouse.

(+) git Remote RM origin

Delete the original remote warehouse address.

Git push-u Origin Master

Pushes all the contents of the master branch for the first time.

() Git push Origin master

This command is used for each subsequent modification.

(16) About branches:

In version rollback, every commit, git strings them into a timeline, which is a branch of the line. So far, there is only one time line, in Git, this branch is called the main branch, the Master branch. The head pointer is strictly not pointing to the commit, but pointing to Master,master is pointing to the commit. So, head is pointing to the current branch.

git checkout-b Dev

Create a dev branch, and then switch to the Dev branch.

.

(17) The above command is equivalent to the following two commands:

Git branch dev: Create a new dev branch;

git checkout dev: switch to Dev branch;

(+) Git branch

View all local branches. The front with an asterisk * indicates the current branch.

。

Attention:

Git branch-a: View all branches, including local and remote branches.

The local branch is shown in green and black, green indicates your current branch, and Black is the other branch. The remote branch is indicated in red.

Git branch-r: View all remote branches, all in red.

git branch-d dev: Deletes a local branch, such as the Dev branch.

(20) Merging branches

1. Git checkout-b dev: first create a dev branch and switch to the Dev branch;

2. Make the modified file and submit it.

.

3.cat main.m

Under Dev Branch

Found inside I added "//dev branch" these words;

4.git Checkout Master: Now that the Dev branch is done, we can switch to the master branch.

.

5.cat Main

The Master branch.

There is no "//dev branch" in the discovery because the commit is on the Dev branch, and the Maser branch is not changed at the present point.

。.

6. Git merge dev

Merge the work of the Dev branch onto the master branch.

The git merge command is used to merge the specified branch into the current branch. After merging, when you look at the contents of the file, you can see that the latest commit to the Dev branch is exactly the same.

。

7. The above "Fast-forward" information, Git tells us that this time the merger is "Fast forward mode", that is, direct master to Dev's current commit, so the merging speed is very fast.

8.git branch-d Dev

Once the merge is complete, you can safely delete the dev branch.

.

9. Branch Summary: Because creating, merging, and deleting branches is very fast, git encourages you to use branches to accomplish a task, merge and then delete the branch, which works the same as working directly on the master branch, but the process is more secure.

(21) Conflict resolution

1.git Checkout-b testconflict

git Add.

Git commit-m "testconflict commit, test conflict"

Create a new Testconflict branch to test for conflicts. and modify one line of code; commit.

.

2. Git checkout Master

git Add.

git commit-m "test"

Under the Master branch, also modify the same line of code, and commit;

.

3.git Merge Testconflict

At this point, two branches each have a new commit, at this time, git cannot perform a "quick merge", only the view to merge the individual changes, but this merge will conflict. The results of this merge are as follows:

.

4.git prompted us to have a conflict. You can see which file is in conflict with the "Git status" command.

。

5. We can go directly to the conflict file view, you can see the following code:

。

Among them <<<<<,=====,>>>>>>, this kind of place indicates there is conflict. Can be modified manually, the following code is modified:

。

Then submit it under Master.

。

6.git Log--graph

You can see the merge of the branches,

。

Note above: "merge:5da331c 1225c73" is the merging of the later branches into the previous branch. That is, merging the testconfict branches onto the master branch. This 7-digit number is the first 7 digits of the number behind the commit.

The number after commit is the hash value, using the SHA-1 hash algorithm, 40 bits in length. Is the hash value calculated based on the content of your file.

7.git Log--graph--pretty=oneline

You can have the output appear on one line,

.

8. Finally delete the Testconflict branch. Note: When git cannot merge branches automatically, you must first resolve the conflict. After resolving the conflict, submit again, and the merge is complete.

(22) Branch management policy

1. When merging branches, GIT uses fast forward fast-forward mode, but in this mode, the branch information is discarded after the branch is removed. We can use git merge in--no-ff mode.

2.git Checkout-b Dev

Still creates and switches to the dev branch.

3.git Add.

git commit-m "Merge--no-ff"

Submit under the Dev branch.

4.git Checkout Master

Switch to the Master branch.

5.git Merge--no-ff-m "merge with No-ff" Dev

Merging uses the--NO-FF parameter, which means that fast Forward is disabled. Because this merge will create a new commit, add the-m parameter.

6.git Log--graph--pretty=oneline--abbrev-commit

View Branch history. Note Using the--abbrev-commit parameter can shorten the commit's 40 hash value to 7 bits for easy viewing.

7. Branching policy:

First of all, the master branch should be very stable, that is, only to release the new version, usually do not work on it. Work is on the Dev branch, that is, the dev branch is unstable, at some point, such as the 1.0 release, then merge the Dev branch to master and Release version 1.0 on Master. Everyone has their own branch, and sometimes it's time to merge on the Dev branch.

Merging branches, plus the--NO-FF parameter can be combined with normal mode, the merged history has branches, you can see that have been merged. The Fast forward merger does not see a merger. The default is "Fast forward".

(+) Bug Branch

Each bug can be repaired by a new temporary branch, after the repair, merge the branch, and then delete the temporary branch.

1.git Stash

The current work site storage, and so on after the return to the site to continue to use.

git stash List

View the stash stored in the current branch

。

2.git status

The workspace is now viewable in the Dev branch, which is clean. So you can safely create a branch to fix the bug.

。

3.git Checkout Master

Git checkout-b issue-101

First determine which branch to fix the bug on, assuming that you want to fix it on the master branch, create a temporary branch from master.

。

4. Fix the bug on issue-101, submit.

。

5.git Checkout Master

git merge--no-ff-m "fix complete, merge issue-101 branch" issue-101

git log--graph--pretty=oneline--abbrev-commit

Merge bug branches.

。

6.git branch-d issue-101

Delete the bug branch.

。

7.git Checkout Dev

git status

Back to the Dev branch and work, the job site is completely clean.

。

8.git Stash List

View the current work site. Git stores the stash content somewhere. We need to restore the scene.

.

9.git Stash Pop

git stash List

The contents of the stash were also deleted while the contents were restored.

.

10.git Stash Apply

git stash Drop

These two lines of command are equivalent to "Git stash pops". With "Git stash apply" recovery, but after the recovery, stash content is not deleted, you need to use "Git stash drop" to delete.

。

11.git Add.

Git commit-m "submit in Dev Branch"

Submit the content of the dev branch work. Wait to merge to the Master branch.

。

12.git Checkout Master

Git merge--no-ff-m "merging the work of the dev branch" Dev

If there is a conflict, modify it manually.

。

13.git Add.

git commit-m "Merge master commit after Dev"

git branch-d Dev

After you manually resolve the conflict, submit it in master, and then delete the dev branch.

。

14. Summary: When fixing a bug, we will fix it by creating a new bug branch, then merging and finally deleting it.

When the work is not finished, first put the work site Git stash, and then to fix the bug, repair, then git stash pop, back to the job site.

(Feature Branch)

1. Add a new feature, you certainly do not want to because some of the experimental nature of the code, the main branch messed up. So, with each new feature added, it is best to create a new feature branch, which is developed on top, completed, merged, and finally deleted by the feature branch.

When the development is complete, this new feature is not required until the merge has been completed. You need to delete the branch.

Git branch-d feature-net

.

2.git branch-d feature-net

Note: The deletion in 1 cannot succeed because the branch has not been merged and if deleted, modifications will be lost. If you want to forcibly delete, use the git branch-d feature-net command.

。

3. Summary: To develop a new feature, it is best to create a new branch. If you want to discard a branch that has not been merged, you can use git branch-d <name> forcibly delete it.

(+) Git remote

View information for the remote library.

Git remote-v

Displays the details. Shows the origin address that can be crawled and pushed. If you do not have permission to push, you cannot see the address of the push.

。

(26) Multi-person collaboration

1. Push branch: Pushes all local commits on the branch to the remote library. When pushing, you specify a local branch so that git pushes the branch to the remote branch of the remote library.

Git push Origin Master

If you want to push to another branch, such as Dev, change it to:

Git push Origin Dev

However, it is not necessary to push local branches remotely, so which branches need to be pushed and which ones do not?

The--master branch is the main branch, so synchronize with the remote at all times;

--dev Branch is a development branch, all members of the team need to work on it, so also need to synchronize with the remote;

--bug Branch is only used to fix bugs locally, no need to push to remote;

--feature branches can be seen in actual development needs.

2. Crawling branches

git checkout-b Dev Origin/dev

Create a remote Origin's dev branch to local.

Git branch--set-upstream Dev origin/dev

Set up a link to the local dev and remote Origin/dev branch.

3. Multi-person Collaboration mode:

--First, you can try to push your own changes with GIT push Origin branch-name;

--If the push fails because the remote branch is newer than your local branch version, it needs to be merged with the Git pull view first;

-If there is a conflict in the merge, resolve the conflict and submit it locally;

-No conflict or conflict resolution, and then GIT push origin branch-name push will succeed.

--If Git pull hints "No tracking information", then the link relationship between the local branch and the remote branch is not created, with the command "Git branch--set-upstream branch-name origin/ Branch-name ".

4. Summary

--View Remote library information, using "Git remote-v";

--The locally created branch is not visible to others if it is not pushed to the remote;

--Push the branch from the local, use "Git push origin branch-name", if push fails, first crawl the remote new commit with "Git pull";

--In the local library creation and remote branch corresponding branch, using "Git checkout-b branch-name origin/branch-name", local and remote branch names are best consistent;

--Establish the association of local and remote branches, "Git branch--set-upstream branch-name origin/branch-name";

--From the remote crawl branch, use git pull. If there is a conflict, you must first handle the conflict.

(27) Label Management

When we publish a version, we usually start with a tag in the repository, so that it's the only version that determines the time of the tag. Any time in the future, the version of a tag is taken out of the historical version of that tag. Therefore, the tag is also a snapshot of the repository.

The gitde tag is a snapshot of the repository, but in fact he is a pointer to a commit. Therefore, creating and deleting tags is instantaneous.

(28) Create a label

git Tag v1.0

Switch to the branch you want to tag, and execute "git tag v1.0", which is the default on the latest commit.

git tag

See all the tags.

.

git tag v1.1 commit_id

Tags can be hit on any one commit.

Git Show v1.0

View the label information.

.

(29) Operation label

1.git tag-d v1.0

Because the created labels are stored only locally, they are not automatically pushed to the remote. Therefore, the wrong tag can be safely deleted locally.

。

2.git Push Origin v1.0

Pushes a tag to a remote branch.

。

3.git Push Origin--tags

All-in-one push is not yet pushed to the remote local label.

。

4. If the label has been pushed to the remote, to remove the remote label is a bit troublesome, first removed from the local

Git tag-d v1.0

Then remove from remote. The Delete command is also push, but the format is as follows:

git push origin:refs/tags/v1.0

.

5. Summary:

--command "Git push Origin <tagname>": You can push a local tag;

--command "Git push Origin--tags": You can push all the local tags that are not pushed;

--command "Git tag-d <tagname>": can delete a local tag;

--command "Git push origin:refs/tags/<tagname>": You can delete a remote tag.

Git Learning Notes