Git is a version control software, so to make version updates clear, easy to roll back, etc., the final result should look like the following image. I have the habit of taking notes, study is the referenceBig man Liao Xuefeng’s blog.

1. Introduction of Git

Both SVN and CSV are centralized version control systems and require a central storage device. Each modification needs to be uploaded to this storage device, which requires networking and requires a large amount of modification. Therefore, uploading is slow and requires high network requirements. Git is a distributed version management system, with a complete repository of versions on everyone’s computer and a server that acts as a central switch, but does not store the entire project, just to facilitate the exchange of changes.

  • Install Git and configure user name and user email, which are the identifiers Git requires. –global means that we use this user for all repositories.
  • To create a repository, run a git init in your current directory and generate a.git file in that directory. This is a hidden file that you can view using ls-ah
  • File submission is divided into two steps: Add and COMMIT. Multiple files can be added at one commit. -m is a comment to which some version updates can be added later.

Note: Git commands must be executed in the Git repository directory (except Git init), and it makes no sense to execute outside the repository directory. Git can detect changes in text files, but not in binaries, such as images, which can only detect size changes.

2. The Git a time machine

2.1 Version rollback

We have to go back to the previous version, or we have gone back to the previous version, and we want to go back to the current version, like Doraemon’s time machine. The first step is to print out a log of each changegit log, if the output is too much too messy, you can usegit log --pretty=oneline Commit is followed by a large string of version snapshot numbers. useGit resetTo jump to the specified version, future or past, butgit reset --hard HEAD^Point to the previous versionBut if I go back and regret the next day, I can’t find the latest version number to usegit reflogThis records every command executed

2.2 Work area and temporary storage area

In the workspace are the files we can see, except for.git, but there is a Working tree that stores the files we have modified without adding them. The stage is like a staging area. Multiple modified files are added to the stage via add and then committed to the Master Tree in one go. The master Tree uses a HEAD pointer to point to the current version. Reset means to change the position of the pointer.

2.3 Managing Changes

Git saves changes not in the file where they are made, but in the place where they are made. So I’m going to give you an exampleI changed the readme, ran add, then changed the readme again, and then directly committedgit diff View the differences between the workspace and the master area.It turns out that Git does track changes to files

If you want to undo your project before committing, git status will tell you to git restore –staged file if the project has not been added, or if it has been added, git restore –staged file. Git checkout — file git checkout — file git checkout — file can also be used to rollback commands that have not been passively written into your workspace. This has two cases.

  • After the file is modified, no add is added and the file is directly restored
  • After the file was modified, then added, then modified again, it reverted to the version it had been written in after ADD.

The same is true for deleting files, when deleting a file directly in the workspacerm test.txtIt will not take effect immediatelygit statusCheck it out, we still need to commit to the stage to use itgit rm fileAnd thengit commit

3. Add a remote library

Now, after you’ve created a Git repository locally, you want to create a Git repository on GitHub and synchronize the two repositories remotely, so that the repository on GitHub can be used as a backup and other people can collaborate with the repository. First, log on to GitHub and then, in the upper right corner, find the “Create a new repo” button to Create a new repository: Enter Learngit in the Repository name, keep the default Settings, and click the “Create Repository” button to successfully Create a new Git Repository. Run the following command on our local computer

$ git remote add origin [email protected]:michaelliao/learngit.git

And then we push our native code up thereGit remote rm git remote rm git remote rm git remote rm git remote rm You are advised to use git remote -v to check the remote library information.

$ git remote -v
origin  [email protected]:michaelliao/learn-git.git (fetch)
origin  [email protected]:michaelliao/learn-git.git (push)
Copy the code

Then, delete by name, such as delete origin:

$ git remote rm origin
Copy the code

In this case, “delete” actually unbinds the local and remote, not physically deletes the remote library. Nothing has changed in the remote library itself. To actually delete a remote library, log in to GitHub and go to the delete button on the background page.

Last time we talked about how to associate remote libraries when you have local libraries before remote libraries.

Now, assuming we are developing from scratch, the best way to do this is to create a remote library first, and then clone from the remote library.

First, log on to GitHub and create a new repository called GitSkills:

github-init-repo
Copy the code

We checked Initialize this repository with a README and GitHub will automatically create a readme.md file for us. Once created, you can see the readme.md file:

github-init-repo-2
Copy the code

Now that the remote library is ready, the next step is to clone a local library with the git clone command:

$ git clone [email protected]:michaelliao/gitskills.git
Cloning into 'gitskills'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3
Receiving objects: 100% (3/3), done.
Copy the code

Change the Git library address to your own, and then go to the gitskills directory to see the readme. md file:

$ cd gitskills
$ ls
README.md
Copy the code

4. Branch management

Have to sayLiao XuefengBig guy is really too severe, the description of the branch is a what kind of thing, I just do a copy backup here, we must go to see the original Po.

What does branching do in practice? Let’s say you want to develop a new feature, but it takes two weeks to complete. In the first week, you write 50% of the code. If you submit it immediately, the incomplete code base will cause others to be unable to work because the code is not finished. If you wait until all the code is written and then commit again, you run the risk of losing progress on a daily basis.

This means that changes to files and so on are made on branches. Merge and modify operations are made to a single pointer, which may be recorded in a file, but each version time node records a snapshot of where the changes were made.

Git encourages extensive use of branches:

  • Check out the branch: Git Branch
  • Create a branch: Git Branch
  • Switch branches: Git checkout or Git switch
  • Create a + switch branch: git checkout -b or git switch -c
  • Merge a branch into the current branch: git merge
  • Delete branches: git branch -d

4.1 Actual combat

First, we create the dev branch, and then switch to the dev branch:

$ git checkout -b dev
Switched to a new branch 'dev'
Copy the code

Git checkout the git checkout command with the -b parameter creates and switches.

$ git branch dev
$ git checkout dev
Switched to branch 'dev'
Copy the code

Then, use the git branch command to view the current branch:

$ git branch
* dev
  master
Copy the code

The git branch command lists all branches, with the current branch preceded by an asterisk. We can then commit normally on the dev branch, such as making a change to readme.txt and adding the following line: Creating a new branch is quick. Then submit:

$ git add readme.txt 
$ git commit -m "branch test"
[dev b17d20e] branch test
 1 file changed, 1 insertion(+)
Copy the code

Now that the dev branch is done, we can switch back to the master branch:

$ git checkout master
Switched to branch 'master'
Copy the code

After switching back to the master branch and looking at a readme. TXT file, the contents that you added are missing! Because that commit is on the dev branch, and the master branch’s commit point remains the same:

git-br-on-master
Copy the code

Now let’s merge the work of the dev branch onto the master branch:

$ git merge devUpdating d46f35e.. b17d20e Fast-forward readme.txt | 1 + 1 file changed, 1 insertion(+)Copy the code

The git merge command is used to merge a specified branch into the current branch. After the merge, you can look at the readme.txt content and see that it is exactly the same as the dev branch’s latest commit.

Git is going to Fast forward this merge by pointing the master directly to dev’s current commit, so it’s going to be very Fast.

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

$ git branch -d dev
Deleted branch dev (was b17d20e).
Copy the code

After deleting it, look at branch and there is only the master branch left:

$ git branch
* master
Copy the code

Because creating, merging, and deleting branches is very fast, Git encourages you to use branches to accomplish tasks, merge, and then delete branches. This is just as effective as working directly on the Master branch, but it’s a safer process.

4.2 Conflict Resolution

Get ready for the new Feature1 branch and continue with our new branch development:

$ git switch -c feature1Switched to a new branch 'Feature1'Copy the code

Creating a new branch is quick AND simple. Submit on feature1:

$ git add readme.txt
$ git commit -m "AND simple"
[feature1 14096d0] AND simple
 1 file changed, 1 insertion(+), 1 deletion(-)
Copy the code

Switch to the Master branch:

$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
Copy the code

Git will also automatically prompt you that the current master branch is committed 1 commit ahead of the remote master branch.

On the master branch change the last line of the readme. TXT file to:

Creating a new branch is quick & simple. Commit:

$ git add readme.txt 
$ git commit -m "& simple"
[master 5dc6824] & simple
 1 file changed, 1 insertion(+), 1 deletion(-)
Copy the code

Now, the Master branch and Feature1 branch each have new submissions, which look like this:In this case, Git can’t do a “quick merge”. Instead, it tries to merge the changes together.

$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
Copy the code

Sure enough there was a clash! Git tells us that the readme.txt file has a conflict and must be resolved manually before committing. Git status can also tell us about conflicting files:

$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

	both modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")
Copy the code

We can directly view the contents of readme.txt:

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1
Copy the code

Git uses <<<<<<<, =======, >>>>>>> to mark the contents of different branches, we modify as follows and save:

Creating a new branch is quick and simple. To submit:

$ git add readme.txt 
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed
Copy the code

Now, the Master branch and Feature1 branch look something like this:

You can also see the merge of branches using the parameterized Git log:

$ git log --graph --pretty=oneline --abbrev-commit
*   cf810e4 (HEAD -> master) conflict fixed
|\  
| * 14096d0 (feature1) AND simple
* | 5dc6824 & simple
|/  
* b17d20e branch test
* d46f35e (origin/master) remove test.txt
* b84166e add test.txt
* 519219b git tracks changes
* e43a48b understand how stage works
* 1094adb append GPL
* e475afc add distributed
* eaadf4e wrote a readme file
Copy the code

Finally, delete the Feature1 branch:

$ git branch -d feature1
Deleted branch feature1 (was 14096d0).
Copy the code

4.3 Branch Management

Git usually merges branches in Fast Forward mode if possible, but in this mode, branch information is discarded when the branch is deleted.

If you force the Fast Forward mode to be disabled, Git generates a new COMMIT at merge so that the branch history shows the branch information.

Git merge git merge git merge git merge

First, the dev branch is still created and switched:

$ git switch -c dev
Switched to a new branch 'dev'
Copy the code

Modify the readme. TXT file and commit a new commit:

$ git add readme.txt 
$ git commit -m "add merge"
[dev f52c633] add merge
 1 file changed, 1 insertion(+)
Copy the code

Now, let’s switch back to master:

$ git switch master
Switched to branch 'master'
Copy the code

To merge the dev branch, note that the –no-ff parameter disables Fast Forward:

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 readme.txt | 1 +
 1 file changed, 1 insertion(+)
Copy the code

Since this merge is creating a new COMMIT, add the -m parameter to the commit description. After the merge, let’s use git log to look at the branch history:

$ git log --graph --pretty=oneline --abbrev-commit
*   e1e9c68 (HEAD -> master) merge with no-ff
|\  
| * f52c633 (dev) add merge
|/  
*   cf810e4 conflict fixed
...
Copy the code

As you can see, instead of using Fast Forward mode, merge looks like this:

Git branch -d branch is a branch that has not been merged yet

The principle of branch management: the master branch must be very stable, changes should be made on the dev branch, everyone should have their own branch, and dev should only be merged on the dev branch for testing, and dev should only be merged on the master branch for release updates

4.4 stash command

Bugs are a common occurrence in software development. Bugs need to be fixed, and in Git, because branches are so powerful, each bug can be fixed with a new temporary branch, which is merged, and then removed.

When you receive a task to fix a bug code-named 101, it’s natural that you want to create a branch of issue-101 to fix it, but, wait, the work currently underway on Dev hasn’t been committed yet:

$ git status
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   hello.py

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   readme.txt
Copy the code

It’s not that you don’t want to submit, but that the work is only half done and still can’t be submitted. It’s expected to take another day to complete. But what if the bug has to be fixed within two hours?

Fortunately, Git also provides a stash feature that allows you to “stash” your current work site for later recovery:

$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
Copy the code

Your workspace is now clean (unless you have files managed by Git) with Git status, so you can safely create branches to fix bugs.

First determine which branch to fix the bug on. Assuming you need to fix the bug on the master branch, create a temporary branch from the master:

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git checkout -b issue-101
Switched to a new branch 'issue-101'
Copy the code

Git is free software… Git is a free software… And then submit:

$ git add readme.txt 
$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)
Copy the code

When the fix is complete, switch to the Master branch, complete the merge, and finally remove the issue-101 branch:

$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Copy the code

Great, what was supposed to be a two-hour bug fix only took 5 minutes! Now, it’s time to get back to work on the Dev branch!

$ git switch dev
Switched to branch 'dev'

$ git status
On branch dev
nothing to commit, working tree clean
Copy the code

The workspace is clean. Where is the work site? Take a look with the git stash list command:

$ git stash list
stash@{0}: WIP on dev: f52c633 add merge
Copy the code

The workspace is still there, Git has stash content somewhere, but you need to restore it. There are two ways to do this:

One is to restore with a Git Stash apply, but the stash content is not deleted. You need to remove it with a Git Stash drop.

Another way to do this is to use git stash pop, which removes the stash content at the same time:

$ git stash pop
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   hello.py

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   readme.txt

Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)
Copy the code

If you look at the Git Stash list, you won’t see any stash content:

$ git stash list
Copy the code

You can do this multiple times with the git Stash list and then restore the specified stash with the following command:

$ git stash apply stash@{0}
Copy the code

To fix the same bug on dev, we simply “copy” the changes made by the 4c805e2 fix Bug 101 commit to the dev branch. Note: We only want to copy the changes made in the 4c805e2 fix Bug 101 commit, not merge the whole master branch.

Git provides a cherry-pick command that lets you copy a particular commit to the current branch for ease of use:

$ git branch
* dev
  master
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)
Copy the code

Git made an automatic commit to the dev branch. Note that this time the commit is 1d4b803, which is not the same as 4c805e2 for master. With git cherry-pick, we don’t need to manually fix the bug all over again on the dev branch.

4.5 Multi-Party Collaboration

Multi-person collaboration process

  • First, you can try to push your own changes with Git push Origin;
  • If the push fails, the remote branch is newer than your local branch and you need to use Git pull to try merging.
  • If the merge has conflicts, resolve the conflicts and commit locally;
  • Git push Origin if there is no conflict or the conflict is resolved, git push Origin will be successful!
  • If git pull displays no tracking information, the link between the local branch and remote branch has not been created. Run the git branch –set-upstream to origin/ command.

Common operations

  • Git remote -v
  • Branches created locally are not visible to others unless they are pushed remotely.
  • If the push fails, use Git pull to grab the new commit from the remote branch.
  • To create a branch corresponding to the remote branch, run the git checkout -b branch-name origin/branch-name command. The name of the local branch and the remote branch must be the same.
  • Git branch –set-upstream branch-name origin/branch-name
  • Grab branches remotely, using Git pull, and if there are conflicts, handle them first.

5. Label management

The git tag

command is used to create a new tag. The default tag is HEAD. You can also specify a commit ID.

Git tag -a

-m “blablabla…” You can specify label information.

You can run the git tag command to view all tags.

If the label is incorrectly typed, it can also be deleted:

$Git v0.1 tag - d
Deleted tag 'v0.1' (was f15b0dd)
Copy the code

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

To push a tag to a remote location, use git push origin:

$Git push origin v1.0Total zero (0) delta, reused zero (0) delta To github.com: michaelliao/learngit git * [new tag] v1.0 - > v1.0Copy the code

Alternatively, push all local tags that have not been pushed remotely at once:

$ git push origin --tagsTotal zero (0) delta, reused zero (0) delta To github.com: michaelliao/learngit git * [new tag] v0.9 - > v0.9Copy the code

If the tag has been pushed to a remote location, it is difficult to delete the remote tag from the local location:

$Git v0.9 tag - d
Deleted tag 'v0.9' (was f52c633)
Copy the code

Then, delete it from remote. The delete command is also push, but in the following format:

$Git push origin: refs/tags/v0.9To github.com: michaelliao/learngit. Git - [does] v0.9Copy the code

To see if the tag is actually removed from the remote library, go to GitHub and check.

6. Using a lot

At Github, you can fork out your own online project, just like the original project, and clone it from the repository of your own fork