This article has participated in the “Digitalstar Project” and won a creative gift package to challenge the creative incentive money.

For a programmer or a college student, I suggest you still learn git well, because most of the enterprise code management tools are using Git, in fact, Git is very simple, nothing more than some commands, we usually use it more, you can practice makes perfect. I think you can create your own Gitee and GitHub accounts, host your own code, and manage it. Here is a summary of some of the suggestions you found useful about Git.

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 is different from SVN

Git is not just a version control system, it is also a content management system (CMS), work management system, etc.

If you’re someone with a SVN background, you’ll need to do a bit of a mind-shift to accommodate some of the concepts and features Git offers. Differences between Git and SVN:

  1. Git is distributed, SVN is not: this is the core difference between Git and other non-distributed version control systems, such as SVN, CVS, etc.
  2. Git stores content as metadata, whereas SVN stores content as files: all resource control systems hide meta information about files in folders like.svn,.cvs, etc.
  3. Git branches are different from SVN branches: branches are nothing special on SVN, just another directory in the repository.
  4. Git does not have a global version number, whereas SVN does: this is by far the biggest feature Git lacks compared to SVN.
  5. Git’s content integrity is superior to SVN’s: Git’s content storage uses the SHA-1 hash algorithm. This ensures the integrity of the code content and reduces damage to the repository in the event of disk failures and network problems.

Git Quick Start

Git related Websites

  • Git-scm.com it-scm.com
  • Git command manual: git-scm.com/docs
  • Git command Manual (PDF version) : github-git-cheat-sheet.pdf
  • Git guide: Git guide

Git Workflow

Git works as follows:

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

The following diagram shows Git’s workflow:

Git workspace

Git workspace is divided into:

  • Working Directory:The directory you can see on your computer.
  • Repository:The workspace has a hidden directory.gitThis directory is not a workspace, but a Git repository.
  • Stage/Index:General storage.gitIn the directoryindexFile (.git/index), so we sometimes call the staging area an index.

The following diagram shows the relationship between workspaces, staging areas in repositories, and repositories:

The workspace is on the left and the version library is on the right. Marked in the repository asindexIs the staging area marked as stage/indexmasterismasterThe directory tree represented by a branch. At this timeHEADIt actually points tomasterBranch a “cursor”, so the graphical command appearsHEADWhere you can use itmasterTo replace. In the figureobjectsThe area identified is git’s object library, which is actually located.git/objectsDirectory.

  • When executed on workspace modified (or added) filesgit addCommand, the directory tree of the staging area is updated, and the contents of the files modified (or added) in the workspace are written to a new object in the object library, whose ID is recorded in the staging area’s file index.
  • When performing the commit operationgit commit“, the directory tree of the staging area will be written to the version library (object library), and the master branch will update it accordingly. That is, the last directory tree that the master points to is the original directory tree of the staging area at the time of submission.
  • When you performgit reset HEADCommand, the staging area directory tree is rewritten and replaced by the directory tree pointed to by the master branch, but the workspace is not affected.
  • When you performgit rm --cachedCommand deletes files directly from the staging area, leaving the workspace unchanged.
  • When you performgit checkout . 或 git checkout --Command to replace workspace files with all of the files in the staging area or the specified files. This operation is dangerous because it makes it clear that changes in the workspace have not been added to the staging area.
  • When you performgit checkout HEAD . 或 git checkout HEADCommand to replace files in the staging area and workspace with all or part of the files in the Master branch pointed to by HEAD. This command is also extremely dangerous. Not only are uncommitted changes in the workspace clear, but also uncommitted changes in the staging area are clear.

Git File Status

Git has three states, and your files may be in one of them:

  • Committed:Indicates that data is securely stored in the local database.
  • Modified:Indicates that the file has been modified but not saved to the database.
  • Passage Ten:Indicates that the current version of a modified file is marked for inclusion in the next committed snapshot.

Git installed

Git needs to be installed before you can use it. Git currently runs on Linux/Unix, Solaris, Mac, and Windows platforms. The installation package for each Git platform can be downloaded from git-scm.com/downloads

Install on Linux

If you want to install Git with a binary installer on Linux, you can do so using the base package management tools included with your distribution. If using Fedora as an example, you can use yum:

$ sudo yum install git
Copy the code

If on a Debian-based distribution, try apt-get:

$ sudo apt-get install git
Copy the code

Git’s official web site provides instructions for installing Git on various Unix-style systems at git-scm.com/download/li… .

Install on a Mac

There are several ways to install Git on a Mac. The easiest way to do this is to install Xcode Command Line Tools. On Mavericks 10.9 or later, run the git command in Terminal for the first time. If you have not installed the command-line developer tools, you will be prompted to do so.

If you want to install a newer version, you can use a binary installer. The officially maintained OSX Git installer can be downloaded from the official Git website at git-scm.com/download/ma… .

You can also install the Git OS X installer as part of GitHub for Mac. Their graphical Git tools have an option to install command-line tools. The tool can be downloaded from GitHub for Mac at mac.github.com.

Install on Windows

There are also several ways to install Git on Windows. The official version can be downloaded from the official Git website. Open git-scm.com/download/wi… , the download will start automatically. Note that this is a project called Git for Windows (also known as msysGit), and Git is a separate project; For more information, visit msysgit.github. IO.

Another easy way is to install GitHub for Windows. This installer contains both graphical and command-line versions of Git. It also supports Powershell, providing stable credential caching and robust CRLF Settings. It can be downloaded at GitHub for Windows, windows.github.com.

Install from source

Some people find it more useful to install Git from the source code because you can get the latest version. Binary installers tend to lag a bit, but as Git has matured in recent years, this difference is no longer significant.

If you want to install Git from source code, you need to install Git dependent libraries: curl, Zlib, OpenSSL, expat, and libiconV. If you have yum(such as Fedora) or apt-get(such as Debian-based systems) on your system, you can use one of the following commands to install minimal dependencies to compile and install Git binaries:

$sudo yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel
$sudo apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev
Copy the code

To be able to add documents in more formats (doc, HTML, INFO), you need to install the following dependency packages:

$ sudo yum install asciidoc xmlto docbook2x
$ sudo apt-get install asciidoc xmlto docbook2x
Copy the code

Once all the necessary dependencies are installed, you can continue to get the latest release tar from several places. Can be obtained from kernel.org, www.kernel.org/pub/softwar… Or from the image on GitHub at github.com/git/git/rel… . Usually the latest version is available on GitHub, but Kernel.org includes the file download signature, which you can use if you want to verify that the download is correct.

Next, compile and install:

$The tar - ZXF git - 2.0.0. Tar. Gz
$ cdGit - 2.0.0
$ make configure
$ ./configure --prefix=/usr
$ make all doc info
$ sudo make install install-doc install-html install-info
Copy the code

When you’re done, you can use Git to get Git updates:

$ git clone git://git.kernel.org/pub/scm/git/git.git
Copy the code

Git configuration

Git provides a tool called Git Config that is used to configure or read the corresponding workspace variables.

Location where the configuration file is stored

These environment variables determine the specific working mode and behavior of Git in each link. These variables can be stored in three different places:

  • /etc/gitconfig file: a configuration in the system that is universally applicable to all users. If you use git config with the — system option, this is the file you read and write to.
  • ~/. Gitconfig file: The configuration file in the user directory applies only to the user. If you use git config with the -global option, this is the file to read and write from.
  • Configuration files in the current project’s Git directory (that is, the.git/config file in the working directory) : The configuration here is only valid for the current project. Each level of configuration overrides the same configuration above, so the configuration in.git/config overrides the variable of the same name in /etc/gitconfig.

On Windows, Git looks for the.gitconfig file in the user’s home directory. The HOME directory is the directory specified by the HOME variable, usually C:\Users\USER. Git will also try to locate the /etc/gitconfig file as its root directory.

Check git version information

Git version information:

git --version
Copy the code

Configuring User Information

The first thing to do when Git is installed is to configure your user name and email address. This is important because this information is used for every Git commit. It’s embedded in your submission forever:

git config --global user.name 'user_name'
git config --global user.email 'user_email'
Copy the code

For details, see Git Configuration

Configure the text editor

Set Git’s default text editor to Vi or Vim. If you have other preferences, such as Emacs, you can reset:

git config --global core.editor emacs
Copy the code

Configure the difference analysis tool

Another common question is which difference analysis tool to use when resolving merge conflicts. For example, to switch to vimdiff:

git config --global merge.tool vimdiff
Copy the code

Viewing Configuration Information

To check the existing configuration, use git config -list:

git config --list
Copy the code

Sometimes you see duplicate variable names because Git reads the same variable name from different configuration files such as /etc/gitconfig and ~/.gitconfig. In this case, Git uses the last value for each unique variable name.

Git config {key} git config {key}

git config user.name
Copy the code

You can also view the configuration information of a configuration file:

git config --local  --list
or
git config --global  --list
or
git config --system --list
Copy the code

The preceding three commands are: View the current warehouse configuration information, view the current user (global) configuration information, and view the system configuration information.

Git configuration files

  1. System level file $(prefix)/etc/gitconfig. This is the /usr/etc/gitconfig file. Git config-system specifies whether to read and write system-level files. It does not exist initially. If it does not exist, it has no impact.
  2. User-level files ~/. Gitconfig gitconfig – global Specifies that only user-level files are operated. It does not exist initially. If it does not exist, it has no impact.
  3. Git /config git config – local Writes only Repository files (default). For read operations, read only from the Repository file.
  4. Git config-file config-file specifies config-file.

Clearing Authentication Information

git config --global --unset credential.helper
or
git config --system --unset credential.helper
Copy the code

Remote: HTTP Basic: Access denied

Save authentication Information

git config --local credential.helper store
or
git config --system credential.helper store
Copy the code

The above command solves the problem of entering a username and password for each submission. Git Credential Storage

Git Git

Create a code repository

git init

Git init command format:

git init [-q | --quiet] [--bare] [--template=]
      [--separate-git-dir ]
      [--shared[=]] [directory]
Copy the code

Step 1: Creating a code repository is very simple. First, choose a suitable place to create an empty directory:

mkdir repository
cd repository
pwd
Copy the code

The mkdir command is used to create a directory, the CD command is used to enter a directory, and the PWD command is used to display the current directory. Git init

specifies a directory as a Gi repository:

git init
Copy the code

Git repository: Git repository: Git repository: Git repository: Git repository: Git repository: Git repository: Git Repository Git repository is destroyed. If you do not see the.git directory, that is because it is hidden by default and can be seen with the ls-ah command.

git clone

Git clone command format:

git clone [--template=]
      [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
      [-o ] [-b ] [-u ] [--reference ]
      [--dissociate] [--separate-git-dir ]
      [--depth ] [--[no-]single-branch]
      [--recurse-submodules] [--[no-]shallow-submodules]
      [--jobs ] [--]  []
Copy the code

To clone to the current directory, use the following command format:

git clone 
Copy the code

Parameter Description:

  • repositoryGit repository.
  • directory: Local directory.

Add staging area

Git add command format:

git add [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] [--edit | -e] [--[no-]all |  --[no-]ignore-removal | [--update | -u]] [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [-- chmod = (+ | -) x] [-] [...].Copy the code

The git add command can be executed multiple times before committing. It only adds the contents of the specified file when the git add command is run; If you want subsequent changes to be included in the next commit, you must run Git Add again to add the new content to the index. By default, the git add command does not add ignored files.

Basic usage

git add [path]
Copy the code

Git add [path] : git add [path] : git add [path] : git add [path] : git add [path] : git add [path] : git add [path] : git add [path] Git not only identifies files in [path] that have been modified (excluding deleted files), it also identifies new files that have been added and adds their information to the index library.

Common commands

Git add Base git add Base git add Base Add all begin with the Base file modifications to the staging area (for example: BaseActivity. Java, BaseFragment. Java) git add Model? Git add Model /*.java git add Model /*.java git add Model /*.javaCopy the code

Submit code

Git commit:

git commit [-a | --interactive | --patch] [-s] [-v] [-u] [--amend] [--dry-run] [(-c | -C | --fixup | --squash) ] [-F | -m ] [--reset-author] [--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=] [--date=] [--cleanup=] [- [no] - status] [-] I | - o [-s []] [-] [...].Copy the code

The git commit command stores the current contents of the index in a new commit along with user and log messages describing the changes.

Submit temporary storage area to local warehouse area

git commit -m [message]
Copy the code

Files that are not added to the staging area are also submitted to the local warehouse

Git commit -- am Git commit -- a -- mCopy the code

Submit documents designated for the staging area to the warehouse area

git commit   ... -m 
Copy the code

Display all diff information when committing

git commit -v
Copy the code

Modify the last commit

git commit --amend
Copy the code

Modifies the last commit and overwrites the commit information of the last commit

git commit --amend -m 
Copy the code

Branch management

Git branch commands are in the following format:

git branch [--color[=] | --no-color] [-r | -a]
    [--list] [-v [--abbrev= | --no-abbrev]]
    [--column[=] | --no-column] [--sort=]
    [(--merged | --no-merged) []]
    [--contains []]
    [--points-at 
Copy the code

The git branch command is used to list, create, or delete branches.

Lists all local branches

git branch
Copy the code

List all remote branches

git branch -r
Copy the code

Lists all local and remote branches

git branch -a
Copy the code

Create a new branch, but remain in the current branch

git branch 
Copy the code

Create a new branch and switch to it

git checkout -b 
Copy the code

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

git branch 
git checkout 
Copy the code

Create a new branch that points to the commit

git branch  
Copy the code

Create a new branch and establish a trace relationship with the specified remote branch

git branch --track  
Copy the code

Switch to the specified branch and update the workspace

git checkout 
Copy the code

Switch to the previous branch

git checkout -
Copy the code

Establish a trace relationship between an existing branch and a specified remote branch

git branch --set-upstream  
Copy the code

Merges the specified branch into the current branch

git merge 
Copy the code

Select a COMMIT and merge it into the current branch

git cherry-pick 
Copy the code

Deleting a Local Branch

git branch -d 
Copy the code

Deleting a Remote Branch

Git push origin: or git push origin --deleteCopy the code

Label management

Git tag command is in the following format:

git tag [-a | -s | -u ] [-f] [-m  | -F ]
     [ | 
Copy the code

The git tag command is used to create, list, delete, or verify gPG-signed tag objects.

List all labels

git tag
Copy the code

Create a new label at the current COMMIT

git tag 
Copy the code

Create a new label before specifying commit

git tag  
Copy the code

Create a new label with label information at the current COMMIT

git tag -a  -m [message]
Copy the code

Deleting a Local Label

git tag -d 
Copy the code

Deleting a Remote Label

Method 1: Delete the remote label directly:

git push origin --delete tag 
Copy the code

Method 2: Delete the local label and then the remote label.

git tag -d 
git push origin :refs/tags/
Copy the code

Viewing Label Information

git show 
Copy the code

Push a label to the remote

git push origin 
Copy the code

Push all local tabs that have not yet been pushed to the remote at once

git push origin --tags
Copy the code

Check the information

Check the Git version number

git --version
Copy the code

The changed file is displayed

git status
Copy the code

Displays the commit history for the current branch

The following table describes some common options supported by git log commands and their definitions:

options instructions
-p Shows the differences between each update in patch format.
– word – the diff Show differences in Word diff format.
– the stat Display file modification statistics for each update.
– shortstat Only the last row number modification in -stat is displayed.
– the name – only A list of modified files is displayed only after the information has been submitted.
– the name – the status Displays the list of new, modified, and deleted files.
– abbrev – commit Only the first few characters of SHA-1 are displayed, not all 40 characters.
– relative to the date Use a short relative time display (for example, “2 weeks ago”).
– graph Displays branch merge history for ASCII graphical representation.
– pretty Display historical submission information in another format. Available options include oneline, short, Full, Fuller, and format(followed by the specified format).
– oneline — pretty=oneline — abbrev-commit

By default, without any parameters, git log lists all updates by commit time, with the most recent update at the top. As you can see, each update has a SHA-1 checksum, the author’s name and E-mail address, the commit time, and finally an indented paragraph showing the commit instructions.

git log
Copy the code

Git log has many options to help you search for submissions of interest. Here are some of the most common.

We often use the -p option to expand the content differences of each submission, and use –

to display only the last two updates:

git log -p -2
Copy the code

This option displays the basic information along with each commit change. This parameter is useful when doing code reviews, or when quickly scanning the changes to a commit committed by a partner.

–stat, showing only a brief count of row increments and changes.

git log --stat
Copy the code

— Pretty option, which specifies that the submission history is displayed in a completely different way than the default format. For example, oneline displays each submission on a single line, which is useful when the number of submissions is large. You can also use short, full, and Fuller to display more or less different information. You can also specify the number of times to submit the history (e.g. –

).

git log --pretty=oneline
Copy the code

Format option, you can customize the format of the record to display, such output for later programming extraction analysis.

git log --pretty=format:"%h - %an, %ar : %s"
Copy the code

The following table lists the common format placeholders and their meanings:

options instructions
%H The full hash string of the commit object
%h A short hash string of the submitted object
%T The full hash string of a tree object
%t A short hash string for a tree object
%P The full hash string of the parent object
%p A short hash string of the parent object
%an Name of the author
%ae Email address of the author
%ad Author revision date (– date= formulated format)
%aD Date revised by author (RFC2822 format)
%ar Date revised by author (relative format, e.g. 1 day ago)
%at Update date (UNIX TIMESTAMP)
%ai Revised by author (ISO 8601 format)
%cn The name of the committer
%ce Email address of the submitter
%cd Submission date (-date = defined format)
%cD Submission date (RFC2822 format)
%cr Submission date (relative format, e.g. 1 day ago)
%ct Submission date (UNIX TIMESTAMP)
%ci Date of submission (ISO 8601 format)
%s Submit instructions

In addition to the option to customize the output format, git logs also have a number of very useful options to limit the length of the output to only partial commits. Use the -since and -until options to display commits restricted by time, such as a specific day (” 2008-01-15 “) or how long ago (” 2 years 1 day 3 minutes ago “). Use the -author option to display submissions for the specified author, and use the -grep option to search for keywords in the submission instructions. The following table lists other commonly used similar options:

options instructions
-(n) Only the last n commits are displayed
– since, – after Only commits after the specified time are displayed
– until, – before Displays only commits prior to the specified time
– the author Only submissions related to the specified author are displayed
– 4-8 Displays only the commits associated with the specified submitter

Remote synchronization

Display all remote warehouses

git remote -v
Copy the code

Gets all updates for a remote host

git fetch 
Copy the code

Gets updates for a branch of a remote host

git fetch  
Copy the code

For example, get the update from the Master branch of the Origin host:

git fetch origin master
Copy the code

Displays information about a remote repository

git remote show 
Copy the code

Gets updates for a branch of a remote host to merge with the current branch

git pull  
Copy the code

For example, to retrieve the Dev branch of the Origin host, merge it with the current branch:

git pull origin dev
Copy the code

Fetch the origin/dev branch and merge it with the current branch. Essentially, this is the same as doing git fetch first and then git merge.

git fetch origin
git merge origin/dev
Copy the code

Gets updates for a branch of a remote host to merge with a local branch

git pull  :
Copy the code

For example, to fetch the dev branch of origin and merge it with the local master branch:

git pull origin dev:master
Copy the code

The current local branch is automatically merged with the corresponding remote host “trace branch”

git pull 
Copy the code

Push the current branch to the corresponding branch of the remote host

git push
Copy the code

Branches the current to the corresponding branch of the remote host

git push 
Copy the code

Branches the local specified branch to the corresponding branch of the remote host

git push  
Copy the code

Forcibly push the current branch to the corresponding branch of the remote host (ignoring conflicts)

git push  --force
Copy the code

Push all branches to the remote repository

git push  --all
Copy the code

Code the rollback

Restores the specified file from the staging area to the workspace

git checkout 
Copy the code

Restores the specified files of a COMMIT to the staging and workspace

git checkout  
Copy the code

Restores all files from the staging area to the workspace

git checkout .
Copy the code

Roll back the add operation

git reset
Copy the code

Rollback the most recent commit

git reset --soft HEAD^
Copy the code

Permanently delete the last few commits

git reset --hard HEAD~3
Copy the code