preface

Recently, I tried to upload the code to GitHub, but I found that the NPM of demo was all installed locally. After searching for how not to upload node_modules to GitHub, I did not succeed, so I decided to take a moment to learn about Git and use it as a note to read in the future. I only knew five commands before the study

$ git init 
$ git add .
$ git commit -m "Submitted XXXXX"
$ git pull
$ git push
Copy the code

What is Git

Git is an open source distributed version control system designed to handle any project, small or large, with agility and efficiency. Git is an open source version control software developed by Linus Torvalds to help manage Linux kernel development. Git is different from the common version control tools such as CVS and Subversion. It adopts the way of distributed version library without the support of server-side software.

Git workflow

  1. Clone the Git resource as the working directory.
  2. Adds or modifies files on cloned resources.
  3. If someone else makes changes, you can update the resource.
  4. Review the changes before committing.
  5. Commit changes.
  6. After the changes are made, if errors are found, the commit can be withdrawn and modified and committed again.

The basic concept

Local repository (Version library)

Git repository: A workspace has a hidden directory, git, which is not a workspace, but a git repository.

What is the local repository (version library)

What is a version library? Git keeps track of all changes and deletions of files in a repository, so that they can be traced at any time in history or “restored” at some point in the future.

The staging area

Temporary storage area: Stage, or index. Git /index. This is why the staging area is sometimes called an index.

The workspace

Workspace: the directory you see on your computer.

Basic use of Git

I’m not going to go into the details, but I think you can do it, but there’s a picture on it, and there’s a few commands on it

Git diff: $git diff: $git diff: $git diff: $git diff: $git diff: $git diff: $git diff: $git diff: $git add file path // to add changes to the staging area $git commit -m"Information"Git add XXX and git commit -m are used to commit changes to the.git repository'xxx'$git with two commandslog// View the change historyCopy the code

Version back

When I commit several commits, let’s say we now have 3 releases (1,2,3), now version 3, realize that the commit was wrong, and want to withdraw back to version 2

$git reset --hard // Resets the staging area and workspace as the last commitCopy the code

Then you find that the commit is correct and want to go back to version 3, and type the following command

$git reset --hard [commitid] // Reset the HEAD of the current branch to the specified commit, reset the staging area and workspace to the same as the specified commitlog- stat viewCopy the code

The next day, you will find that version 3 is correct, but you can’t find the commit information using git log.

Git reflog $git reflog $git reflogCopy the code

Scenario 1: When you tamper with the contents of a file in your workspace and want to discard the workspace changes directly, use the command $git checkout — file

Scenario 2: If you change the contents of a file in your workspace and add it to the staging area, you want to discard the changes. In the first step, run the $git reset HEAD file command to return to scenario 1. In the second step, follow scenario 1.

Scenario 3: If you want to undo an inappropriate change that has been committed to the repository, git reset –hard, but only if it has not been pushed to the remote repository.

Delete the file

$ git rm [file1] [file2] ... // Delete the workspace file and place the deletion in the staging areaCopy the code

You can easily restore the deleted file to the latest version because it is still in the repository:

$ git checkout -- test.txt
Copy the code

Branch (branch)

  • 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.

  • Now that we have branches, we don’t have to be afraid. You create a branch of your own, which no one else can see, and continue to work on the original branch, while you work on your own branch, commit as you like, until the development is finished, and then merge into the original branch once, so that it is safe and does not affect the work of others.

  • As you already know, every commit, Git strings them together into a timeline, which is a branch. So far, there is only one timeline. In Git, this branch is called the master branch. HEAD doesn’t technically point to the commit, it points to the master, and the master points to the commit, so HEAD points to the current branch.

  1. Git creates a new branch, such as dev, and creates a new pointer called dev to point to the same commit as master.
  2. You see, creating a branch in Git is very quick, because apart from adding a dev pointer and changing the HEAD point, nothing changes in the workspace files!

However, from now on, changes and commits to the workspace are for the dev branch. For example, after a new commit, the dev pointer moves forward, while the master pointer stays the same:

How to use branches

$git checkout -b [branch] // Create a branch and switch to it. $git branch // Lists all branches. $ git add . $ git commit -m"Submit branch branch"$git branch $git branch $git branch $git branch $git branch-dBranch // Delete the branch branch after the mergeCopy the code
Git checkout -b <name> merge a branch with the current branch: Git merge <name> Delete a branch: git branch-d <name>
Copy the code

Branch conflict

So let’s say we have this file right now

fuck 'webpack'/ / the master branchCopy the code

We create and switch to the Parcel branch

$ git checkout -b parcel     
Copy the code

Modify text content

Fuck ‘webpack –> Parcel No.1 is submitted to staging

$ git add .
$ git commit "Hee hee"/ / parcel branchCopy the code

Cut back to the master branch

$ git checkout master
Copy the code

Modify text content

Fuck ‘webpack’ –> Fuck ‘webpack’ commit to staging area

$ git add .
$ git commit "Ha ha"/ / maser branchCopy the code

So our two branches are different, and there’s a conflict, so let’s try it out

$git merge parcel // Merge a parcel branch into the master branchCopy the code

And then there’s the conflict

$git status //# On branch master
# Your branch is ahead of 'origin/master' by 2 commits.
#
# Unmerged paths:
# (use "git add/rm 
      
       ..." as appropriate to mark resolution)
      
#
# both modified: fuck.txt
#
Copy the code

We have to manually change the contents of the current Master branch to be the same as the contents of the Parcel branch

Fuck fuck ‘webpack’ –> Parcel No.1 is submitted again

$ git add .
$ git commit "My daughter"/ / maser branchCopy the code

Finally, delete the Parcel branch

 git branch -d parcel
Copy the code

Branch Management Strategy

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

If you forcibly disable the Fast Forward mode, Git generates a new COMMIT when the branch is merged so that the branch history shows the branch information.

Columns such as

$git checkout -b dev // $git merge --no-ff -m $git merge --no-ff -m"merge with no-ff"Dev // ready to merge the dev branch, note that the --no-ff parameter disables Fast forward $gitlog--graph --pretty=oneline --abbrev -- commitlog// Merge a branch with --no-ff; // merge a branch with --no-ff; // merge a branch with --no-ffCopy the code

Team branch management

In actual development, we should follow a few basic principles for branch management:

First of all, the Master branch should be very stable, that is, it should only be used to release new versions, and not work on it.

So where do you work? All the work is on the dev branch, that is, the dev branch is not stable, and at some point, such as a 1.0 release, the dev branch is merged with the master branch, and the 1.0 release is released on the master branch.

You and your friends each work on the Dev branch, and each has his or her own branch, so you can merge into the Dev branch from time to time.

So, the teamwork branch would look something like this:

This should be true of team branches

| - master / / formal | - | - Michael/dev / / beta/player Michael - adc | | - Bob / / players Bob - meat - bibi / / players bibi - the thighCopy the code

Bug branch

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

------------ // There is a $git stash bug on the dev branch with code 101. $git checkout -b issue-101 $git checkout -b issue-101 $git add $git commit -m"fix bug 101"$git merge --no-ff -m $git merge --no-ff -m"merged bug fix 101"Issue-101 // Merge branches, note that $git branch is not used in fast Forward mode-d$git checkout dev // $git stash pop $git stash pop $git stash pop // The first is to restore with a Git Stash apply, but the stash content is not deleted. You need to remove it with a git Stash dropCopy the code

Develop a new test function

To develop a new feature, it is better to create a branch.

Git branch -d

collaboration

When you clone from a remote repository, Git actually automatically maps the local master branch to the remote master branch, and the default name of the remote repository is Origin. To view information about remote libraries, use git remote -v

Push the branch

A push branch pushes all local commits on that branch to a remote repository. Git will push this branch to the corresponding remote branch of the remote library:

$ git push origin master
Copy the code

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

$ git push origin dev
Copy the code

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

  • The master branch is the primary branch and therefore needs to be synchronized with the remote at all times.

  • The dev branch is the development branch where all team members work, so remote synchronization is also required;

  • The bug branch is only used to fix bugs locally, so there’s no need to push it remotely unless your boss wants to see how many bugs you fix per week.

  • Whether the feature branch is pushed to remote depends on whether you work with your friends on it.

When a group collaborates, everyone pushes their changes to the Master and Dev branches. When your buddy from the remote librarycloneBy default, your partner will only see the local master branch. Dev branch = dev branch = dev branch = dev branch = dev branch = dev branch = dev branch = dev branch = dev branch $git checkout -b dev origin/dev $git checkout -b dev origin/dev $git checkout -b dev origin/dev /dev/origin/dev/origin/dev/origin/dev/origin/dev/origin/dev/origin/dev Git pull fails because the origin/dev branch is not linked to the origin/dev branch. $git branch --set-upstream dev origin/dev pull Once resolved, commit and push again:Copy the code

Therefore, the working mode of multi-person collaboration usually looks like this:

First, you can try pushing your own changes with git push Origin branch-name.

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 branch-name git push origin branch-name

If no tracking information is displayed in Git pull, the link between the local branch and remote branch is not created. Run the git branch –set-upstream branch-name origin/branch-name command

This is how people work together, and once you get used to it, it’s pretty easy.

To check the remote library information, use 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.

Label management

Create a label

  • 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.

  • git tag -s

    -m “blablabla…” Tags can be signed with PGP;

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

  • You can also create a label with a caption, using -a to specify the label name and -m to specify the caption:

$ git tag -aV0.1 -m"version 0.1 released" 3628164
Copy the code

Operating the label

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

$ git tag -d v0.1
Copy the code

To push a label remotely, use the command

$ git push origin <tagname>
Copy the code

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

$ git push origin --tags
Copy 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 tag -d v0.9
Copy the code

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

git push origin :refs/tags/<tagname>
Copy the code

Ignore special files

Create a special.gitignore file at the root of your Git workspace and fill it with the names you want to ignore. Git ignores these files automatically. There is no need to write a.gitignore file from scratch. GitHub already has a variety of configuration files ready for us to use. All configuration files can be viewed directly online:.gitignore

The statement

This article is based on liao Xuefeng’s Git tutorial, with some of my personal understanding and illustrations. If you want to know more about Git, you can check out the following links

Gitbook Git Community Book gitbook git Community Book