@ Git notes

create by db on 2018-12-25 12:10:36

Recently revised in 2019-1-4 15:08:40

Hello friends, if you think this article is good, please click a like or a star, your like and star are my motivation to move forward! Making the address

After consulting many online materials and combining with my own learning experience, I wrote this Git learning note to record my learning experience. Now share to everybody, for reference.

As a front end rookie, this is my first post to share with the Nuggets, hoping to kick off 2019. If you are not enough, please give me more advice. Thank you.

preface

References:

  • The Git version control management tutorial | CSDN – lovely clock
  • Git tutorial | – Liao Xuefeng Liao Xuefeng’s official website
  • GIT common commands | blog – genius wolong garden

Version control

Data is transient and easily lost. Especially as developers, we need to update the project code frequently, which is easy to cause incorrect changes or the loss of project files. Therefore, we need to continuously back up and archive our project files throughout the work.

In the current project development environment, a project is often have multiple developers to develop maintenance, that means they need to manipulate the same project file, we need to text records management and project code changes, these changes will constitute a repository, the management of the repository is a version control.

A tool that can manage or track software code is often called a version control system (VCS). Git is a powerful, flexible, and low-cost VCS that can make collaborative development a joy.

The birth of the Git

In fact, there were many VCS on the market before Git was born, such as the big brother of VCS at that time: SVN (which still has a large share in the market now). So why create Git as a new tool?

This, of course, starts with its founder, Linus Torvalds, a man who is worshipped by millions in the tech world! In order to manage Linux kernel development, a reliable and trustworthy VCS is essential. However, the CVS and SVN that Linus always hated are both centralized version control systems, while Git is distributed version control systems. What’s the difference between centralized and distributed version control systems?

Centralized vs distributed

Let’s start with the centralized version control system. The version library is centrally stored in the central server, but when you work, you use your own computer, so you need to get the latest version from the central server, and then start work, finish work, and then push your work to the central server. The central server is like a library. To change a book, you must first borrow it from the library, then go home and change it yourself, and then put it back in the library.

The biggest problem with centralized version control systems is that they have to be connected to the Internet to work. If you are on a LAN, the bandwidth is big enough and the speed is fast enough, but if you are on the Internet, the speed of the network is slow, it may take 5 minutes to submit a 10M file, which is not enough to suffocate people.

How is a distributed version control system different from a centralized version control system? First, there is no “central server” at all. Everyone has a complete repository on their computer, so you don’t need to connect to the Internet to work because the repository is on your own computer. Since everyone has a complete library on their computer, how can multiple people collaborate? For example, if you change file A on your computer and your co-worker changes file A on his computer, the two of you can see each other’s changes simply by pushing each other’s changes.

A distributed version control system is much more secure than a centralized version control system, because everyone has a complete version library on their computer. It doesn’t matter if one person’s computer breaks down, you can just copy it from everyone else. In a centralized version control system, if the central server goes down, everyone can’t work.

How to open Git correctly

To use Git, the first step is, of course, to install Git.

  • Install Git on Linux
  • Install Git on Windows
  • Install Git on your Mac

For more information, please visit Liao Xuefeng’s official website

The body of the

Git Workflow

First above:

These are some simple and common commands, but forget about them and get to know these four proper nouns.

  • Workapace: Workspace
  • Index/Stage: staging area
  • Your Repository is in a local warehouse.
  • Remote: indicates the Remote warehouse

Workspace (Workapace)

The changes that the programmer has made are the ones that you see currently and are the latest.

Normal development is to copy a branch of the remote warehouse and develop based on that branch. In the development process is the operation of the workspace.

Staging area (Index/Stage)

Git add directory index file, the temporary area will record the git add information (file name, size…) , do not save the file entity. You can use Git Status to check the state of the staging area. The staging area marks what is managed by Git in your current workspace.

When you complete a feature that needs to be committed to a remote repository, the first step is to commit the changes to a staging area via Git Add, managed by Git.

Local Repository

It holds all versions of the object that have been committed and is older than the contents of the workspace and staging area.

After git commit, you can synchronize the index directory tree to the local repository, which is convenient for you to synchronize the local repository and remote repository through Git push.

Remote Warehouse

The content of a remote repository can be modified by collaborating local repositories in multiple locations, so it may or may not be in sync with the local repository. We need git pull to make the local repository pull down the code before committing.

HEAD

Before mastering the specific commands, understand HEAD.

HEAD, which always points to the latest commit point of the currently deployed support. If your branch changes or a new commit point is created, the HEAD will change.

No picture, no truth!

summary

  1. Any object is born and modified in the workspace;
  2. Any changes are versioned from the moment they enter the index section;
  3. Changes can only leave footprints in the repository if they are committed to the local repository;
  4. Sharing local changes with collaborators requires pushing the changes to a remote repository

Common Git commands

Keep going!

Create a new code base

  • Create a New Git code base in your current new directory

$ git init

  • Create a new directory and initialize it as the First code base

$ git init [project-name]

  • Download a project and its entire code history

$ git clone [url]

Second, the configuration

The Git Settings file is.gitconfig, which can be either in the user’s home directory (global configuration) or in the project directory (Project configuration).

  1. Displays the current Git configuration

$git config –list

  1. Edit Git configuration files

$ git config -e [–global]

  1. Set the user information when the code is submitted

$ git config [–global] user.name “[name]”

$ git config [–global] user.email “[email address]”

Add/delete files

  • Adds the specified file to the staging area

$ git add [file1] [file2] …

  • Adds a file of the specified type (batch commit using wildcard mode) to the staging area

$ git add *.html

  • Adds the specified directory to the staging area

$ git add [dir]

  • Adds all files that have changed in the current directory to the staging area
  • (This includes submitted new files and modified files, but not deleted files)

$ git add .

  • Add files that have been added and have changed (all files below Git root) to the staging area
  • (Submit modified and deleted files, not new files)

$ git add -u

  • Add all changes (all files below Git root) to the staging area
  • (This includes submitting new, modified, and deleted files)

$ git add –all

$git add -a //

  • Before each change is added, it is required to confirm that multiple changes to the same file can be committed by several times

$ git add -p

  • Delete the workspace file and place the delete in the staging area

$ git rm [file1] [file2] …

  • Stops tracing the specified file, but the file remains in the workspace

$ git rm -cached [file]

  • Rename the file and place the rename in the staging area

$ git mv [file-origin] [file-rename]

  • Rename the folder and upload the change

git mv -f oldfolder newfolder

Git add -u newFolder

git commit -m “changed the foldername whaddup”

  • Delete the folder and upload this change

$ git rm -r –cached [dir]

$git commit -m ‘delete dir’

$ git push -u origin master

4. Code submission

  • Submit temporary storage area to warehouse district

$ git commit -m [message]

  • Submit the files specified in the staging area to the warehouse district

$ git commit [file1] [file2] … -m [message]

  • Commit changes to the workspace since the last commit, directly to the warehouse district

$ git commit -a

  • All diFF information is displayed upon submission

$ git commit -v

  • A new commit is used to replace the previous commit or, if nothing has changed, to override the previous commit

$ git commit –amend -m [message]

  • Redo the previous commit, including new changes to the specified files

$ git commit -amend [file1] [file2]…

Five, the branch

  • List all local branches

$git branch

  • List all remote branches

git branch -r

  • List all local and remote branches

$ git branch -a

  • Create a new branch, but stay in the current branch

$ git branch [branch-name]

  • Create a new branch and switch to it

$ git branch -b [branch-name]

  • Create a new branch that points to the specified COMMIT

$ git branch [branch] [commit]

  • Create a branch to establish a tracing relationship with the specified remote branch

$ git branch –track [branch] [remote-branch]

  • Switch to the specified branch and update the workspace

$ git checkout [branch-name]

  • Switch to the previous branch

$ git checkout –

  • Establishes a trace relationship between an existing branch and the specified remote branch

$ git branch –set-up-tream [branch] [remote-branch]

  • Merges the specified branch into the current branch

$ git merge [branch]

  • Select a COMMIT and merge into the current branch

$ git cherry-pick [commit]

  • Delete the branch

$ git branch -d [branch-name]

  • Deleting a remote branch

$ git push origin –delete [branch-name]

$ git branch -dr [remote/branch]

Six, labels,

  • List all tags

$ git tag

  • Create a tag in the current commit

$ git tag [tag]

  • Create a new tag and specify commit

$ git tag [tag] [commit]

  • Deleting a Local Tag

$ git tag -d [tag]

  • Deleting a Remote Tag

$ git push origin :refs/tags/[tagName]

  • Viewing Tag Information

$ git show [tag]

  • + Submit the specified tag

$ git push [remote] [tag]

  • Submit all tags

$ git push [remote] –tages

  • Create a branch that points to some TEg

$ git checkout -b [branch] [tag]

Check information

  • The changed files are displayed

$ git status

  • Displays the version history of the current branch

$ git log

  • Displays the history of a commit and the files that have changed for each commit

$ git log [tag] HEAD –grep feature

  • Displays all changes after a commit, whose commit notes must match the search criteria

$ git log [tag] HEAD –grop feature

  • Displays the version history of a file, including file name changes

$ git log –follow [file]

$ git whatchanged [file]

  • Show the last five commits

$ git log -5 –pretty –oneline

  • Displays all users who have submitted, sorted by the number of submissions

$ git shortlog -sn

  • Show whom and when the specified file was modified

$ git blame [file]

  • Shows code differences between staging and working areas

$ git diff

  • Shows the difference between the staging area and the previous COMMIT

$ git diff -cached [file]

  • Shows the difference between the workspace and the latest commit for the current branch

$ git diff HEAD

  • Shows the difference between the two commits

$ git diff [first-btanch]… [second-branch]

  • Displays the element data and content changes for a particular commit

$ git show [commit]

  • Displays the contents of a file at the time of a commit

$ git show [commit]:[filename]

  • Displays the last commits of the current branch

$ git reflog

  • Update the current branch by pulling the code from the local master: Branch is usually master

$ git rebase [branch]

Eight, remote branch

  • Update remote storage

$ git remote update

  • Display all remote repositories

$ git remote -v

  • Displays information about a remote repository

$ git remote show [remote]

  • Add a new remote repository and name it

$ git remote add [shortname] [url]

  • Retrieves changes from the remote repository and merges them with the local branch

$ git push [remote] [branch]

  • Upload the local branch to the remote repository

$ git push [remote] [branch]

  • Forcibly pushes the current branch to the remote repository

$ git push [remote] –force

  • Push all branches to the remote repository

git push [remote] –all

Nine, cancellation

  • Restores the specified file in the staging area to the workspace

$ git checkout [commit] [file]

  • Restores the specified file of a COMMIT to the staging area and workspace

$ git chechout .

  • Resets the specified file in the staging area, the same as the last COMMIT, but the workspace remains the same

$ git reset [file]

  • Resets the staging area and workspace, consistent with the last COMMIT

$ git reset –hard

  • Reset the pointer to the current branch to specify COMMIT, and reset the staging area, but the workspace remains the same

$ git reset [commit]

  • Reset the HEAD of the current branch to commit, and reset the staging area and workspace to be consistent with the commit

$git reset –hard [commit]

  • Reset the current HEAD to specify COMMIT, but leave the staging area and workspace unchanged

$ git reset –keep [commit]

  • Create a new commit to undo the specified commit. Changes to the latter are cancelled by the former and applied to the current branch

$ git revert [commit]

  • Remove uncommitted changes temporarily and move them in later

$ git stash

$ git stash pop

10 and other

  • Generate a publishable package

$ git archive

Version of the shuttle

Once again: the version referred to by HEAD is the current version!

Back to the past

For Git, going back in time is easier than putting an elephant in the fridge, in two steps:

  1. If you need to switch versions, first check which versions are available!

    • Displays the commit log from the most recent to the furthest

    $ git log

    • If you feel too dazzled, you can choose a single line display

    $ git log –pretty=oneline

  2. See the commit fcef4ce4280229e2d4a9c914677f6e94e3539ede? This is our commit_id, which is the address to go to. Of course, we don’t need that long, just take the first five.

    Now we activate the time shuttle!

    $ git reset –hard commit_id

Back to the future

There are also two steps to getting back to the future:

  1. If you need to go back to the future, the first step is to determine which version of the future to go back to

    • Viewing Command History

    $ git reflog

  2. See 989 d9ce HEAD @ {… } : commit:… Yet? Choose the future you want and go!

    $ git reset –hard commit_id

The process of creating a project locally using Git

  1. $ makdir ~/hello-world// Create a project hello-world
  2. $ cd ~/hello-world// Open the project
  3. $ git init/ / initialization
  4. $ touch README
  5. $ git add README// Update README file
  6. $ git commit -m 'first commit'// Commit the update and comment “first commit”
  7. $ git remote add origin [email protected]:dedsf/hello-world.git// Connect to remote Github projects
  8. $ git push -u origin master// Update local projects to github projects

GitHub

What is a lot

Github is a Git-based code hosting platform. Paying users can set up private repositories. Our regular free users can only use the public repository, which means the code is open to the public.

Git is fully versioned on its own, but all of its content and versioning records can only be stored locally. If you want to keep both files and versioning records remote, you need to use them in conjunction with GitHub. Usage scenario:

  • None GitHub: Maintain the history file in the local.git folder
  • There’s GitHub: You maintain your lifetime files locally in the.git folder, but also host your lifetime files in a remote repository

How to use GitHub?

What can we do with GitHub

We’ve always used GitHub as a free remote repository, and if it’s a personal open source project, there’s no problem putting it on GitHub. GitHub is also an open source collaboration community that allows people to participate in both your own and others’ open source projects.

Before making appeared, easy open source project, but let the people involved are difficult, because want to participate in, will commit the code, and to every people want to commit the code to open an account that is not realistic, as a result, the crowd is confined to report a bug, even if can get rid of the bug, can only send in the past, the diff file by email It’s very inconvenient.

But on GitHub, with Git’s extremely powerful cloning and branching capabilities, the public is truly free to participate in open source projects for the first time.

How do you get involved in an open source project?

Hugely popular the bootstrap program, for example, it is a very powerful CSS framework, you can access the project home page https://github.com/twbs/bootstrap, point “Fork” on his own account under the cloned a bootstrap warehouse, then, Clone from your own account:

clone [email protected]:michaelliao/bootstrap.git

Be sure to clone the repository from your own account so that you can push changes. If [email protected]: from the author of the bootstrap storehouse TWBS/bootstrap git clone, because do not have permission, you will not be able to push changes.

  • If you want to fix a bug in Bootstrap or add a feature, you can immediately start working on it and push it to your own repository.

  • If you want the bootstrap library to accept your changes, you can start a Pull request on GitHub. Of course, whether the other party accepts your pull request is not certain.

  • If you don’t have the ability to modify the bootstrap, but want to try a pull request, then Fork https://github.com/michaelliao/learngit Liao Xuefeng teacher’s warehouse, Create a text file of your-github-ID.txt, write about your experience in learning Git, and then push a pull request to me. I will accept it depending on my mood.

summary

  • On GitHub, you can Fork open repositories at will;

  • You have read and write access to the forked repository.

  • You can contribute code by pushing a pull request to the official repository.

conclusion

There is a long way to go. I hope Git and GitHub can help us record every step and growth. Let me share with you.

I wish you a better 2019!

Postscript: Hello friends, if you think this article is good, remember to click a “like” or “star”, your “like” and “star” are the motivation for me to write more and richer articles!Making the address



dbThe document library 由 dbusingCreative Commons Attribution – Non-commercial – Share in the same way 4.0 International licenseLicense.

Based on thegithub.com/danygitgitOn the creation of works.

Permissions outside of this license agreement may be obtained fromCreativecommons.org/licenses/by…Obtained.