Git /gɪt/ is an open source distributed version control system

It was originally an open source version control software developed by Linus Torvalds to help manage Linux kernel development

introduce

Version control

Version control is a system for recording changes in the contents of one or more files for future reference to specific revisions. You can version control any type of file, making it easy for different developers to work together

Centralized version control

A centralized version control system is designed to allow developers on different systems to work together. SVN, for example, has a single, centrally managed server that holds revisions to all files, and collaborators connect to this server via clients to pull the latest files or commit updates

In this system, everyone can see the work of everyone else on the project, and administrators can also have a good grasp and assign permissions to each developer. But because the repository is centralized on the server, if there is a single point of failure from the central server, no one can commit updates during that time, and the entire project’s history is kept in a single location, there is a risk of losing all historical updates

Distributed version control

Distributed versioning solves some of the problems of centralized versioning. Instead of just taking a snapshot of the latest version of the file, the client mirrors the code repository in its entirety. This way, if any of the servers that work together fail, they can be recovered later using any of the mirrored local repositories. Because each clone operation is actually a full backup of the code repository

Further, many of these systems can be specified to interact with several different remote repositories. This allows you to collaborate with different work groups on the same project. You can set up different collaborative processes as needed, such as hierarchical model workflows, which were not possible in previous centralized systems

Git is introduced

Record snapshots directly, not compare differences

Instead of keeping changes or differences in files, Git keeps a series of snapshots of files at different times

Git treats data as a set of snapshots of a small file system. Each time an update is committed, or a project state is saved in Git, it takes a snapshot of all the files at that time and keeps an index of that snapshot. To be efficient, Git does not restore the file if it has not changed, but instead keeps a link to the previously stored file. Git treats data more like a snapshot stream

Almost all operations are performed locally

Most of what you do in Git involves only accessing local files and resources, and since you have the project’s full history on your local disk, most of it can seem instantaneous.

Git ensures integrity

All data in Git is evaluated and referenced with a checksum before being stored

Git generally only adds data

Git operations are performed almost exclusively to add data to a Git database

Git installed

Linux is installed on

# yum install git for Linux

$ sudo yum install git
Copy the code

The Windows are installed on the

Download the installation package from the official website

git-scm.com/downloads

Configuring User Information

You need to set up your user name and email address after the installation. This is important because every Git commit uses this information and it is written to every commit you make

$ git config --global user.name "zou"
$ git config --global user.email [email protected]
Copy the code

Git config –list

If you use the –global option to indicate global configuration, then you only need to run this command once, because Git will use that information for everything you do on the system afterwards. When you want to use a different user name and email address for a particular project, you can configure it by running the command without the –global option in that project directory

Git workspaces, staging areas, and repositories

Before getting into the basics of Git, let’s look at the concepts of Git workspaces, staging areas, and repositories

There are three states committed to a file in Git. Modified: The file has been modified, but has not been saved to the database. Staged: Indicates that the current version of a modified file is marked for inclusion in the next committed snapshot

This also introduces the concept of three work areas for Git projects:

  • Workspace: the directory where the project files are located
  • The staging area:Stage or index. Generally stored.git/indexFile, so we call the staging area sometimes called the index
  • Repository:Hide the directory under the workspace.git, where the version information and history of the warehouse are recorded

The following diagram shows the relationship between the workspace, the staging area in the repository, and the repository:

Let’s understand the relationship between these three work areas by creating the warehouse and basic operations

Git repository creation and basic operations

Creating a Git Repository

A repository, also known as a repository, is simply a directory in which all files can be managed by Git. Git can track every modification or deletion of a file so that it can be traced at any time in history or restored at any point in the future

Create and initialize the repository

Git init is used to initialize a Git repository

git init
Copy the code

This command will create a.git directory within the current directory. This subdirectory will contain all the required files from your initial Git repository. Git add

-m

-m

git add .
git commit -m 'initial project version'
Copy the code

The above is to commit all files in the directory to the repository

Clone an existing warehouse

To get a copy of an existing Git repository, use Git clone

or Git clone

Repo is the repository address and directory is the name of the local repository, that is, the directory name

For example, I want to clone a repository on Github and specify the name of the local repository as mylibName

git clone https://github.com/xxxx/xxxx mylibname
Copy the code

Basic operation

Each file in the working directory has one of two states:

  • Have been trackingFiles that have been versioned and recorded in the last snapshot may be inunmodified.The modified 或 It’s in temporary storage.
  • No traceFiles that have not yet been added to version control

The newly added untracked file, and the edited file that Git recorded as modified. Staged files are put into git Add, and git Commit all staged changes, making the committed files unmodified, and so on

Operation command:

  • git statusViewing file Status
  • git addAdds files to the staging area, including untracked and modified files
  • git diffViewing modifications
  • git commitCommit updates to add the staging area’s contents to the local repository
  • git reset HEADCancel the staging
  • git rmRemove the file
  • git mvMove files

Here I create a new demo directory as the repository and initialize the repository

Next, we use the new warehouse demo above and do some operations on the files inside

First create a new file touch readme.txt

View the current file status

To see which files in the repository directory are in the state, use the git status command

  • Untracked filesUntracked files
  • Changes not staged for commitModified file
  • Changes to be committedTemporary status file

You can see that the newly created file readme.txt has a file status of untracked, prompting us to use the git add

command to track the file we need to commit

If you use the git status -s command or the git status –short command, you’ll get a more compact format

Track new files/save modified files

Using the git add

command to start tracking a file or staging modified files will add the file to the staging area

git add readme.txt
Copy the code

Using the git status command again, you can see that the readme.txt file has been traced and is in temporary state. Files that change to be committed are in a temporary state

The git add command takes the path of a file or directory as an argument. If the argument is the path of a directory, the command recursively tracks all the files in that directory

This command is also used to stage modified files, that is, files under Changes not staged for COMMIT

View the staged and unstaged changes

At this point, suppose we make changes to the temporary file

echo 'My Project' > readme.txt
Copy the code

Git diff: git diff: git diff: git diff: git diff: git diff: git diff: git diff

Type Git diff to see the unsaved part of the file updated

This command compares the current file in the working directory to a snapshot of the staging area, that is, changes that have not yet been staged after modification. To see what has been staged to be added to the next commit, use the git diff –cached command

  • git diffChanges that have not yet been provisioned
  • git diff --cachedView the changes that have been provisionally saved

Submit the updates

When the staging file is ready to commit, you can either run the git commit command or join the git commit -m

command.

git commit
Copy the code

This will launch a text editor (vim in this case) for the submission.

Git commit -m

Remember that you are recording the snapshot in the staging area at commit time. Anything not yet staged remains modified and can be versioned at the next commit. Each time you run a commit operation, you take a snapshot of your project, and you can return to that state later, or make comparisons

Skip using the staging area

Git provides a way to skip the staging area. If you add the -a option to Git commit, Git will automatically save and commit all the files that have been tracked, skipping the Git add step

Cancel the staging

git reset HEAD

… Used to cancel content that has been provisioned

Let’s modify readme.txt and git add to the staging area

echo 'modify content' > readme.txt
git add readme.txt
Copy the code

Git status shows that readme.txt has been added to the staging area

If you don’t want to commit it to the next snapshot, you can use git reset HEAD

to cancel the cached content

git reset HEAD readme.txt
Copy the code

Undo the changes to the file

If you want to undo the changes to the file, that is, restore it to its original state, you can use the git checkout — [file] command. This command cancels any changes you have made to the file.

Remove the file

Let’s delete the readme.txt file and check git status

It will record our deletion as an unstaged file

Then run git rm

to record the operation

After the next Commit to update Git commit, the file is no longer under version control

Git rm -f

= git rm -f

If you want to remove the file from the staging area but still want to keep it in the current working directory — in other words, just remove it from the trace list — use the –cached option

Move files

The git mv command is used to move or rename a file, directory, or softlink.

Let’s undo the deletion of the readme.txt file

 git reset HEAD readme.txt
 git checkout -- readme.txt
Copy the code

Then use git mv to rename it

git mv readme.txt README.md
Copy the code

Git main Functions

Remote Repository (Github)

All of our naming operations are performed locally, so if you want to share code or work with other developers, you need to connect to a remote repository. A remote repository is a repository of your projects hosted on the Internet or other networks

Here we use Github as the remote repository

Adding a remote Repository

Run git remote add

to add a new remote Git repository

In this example, github is used as a remote repository. The transmission between the local Git repository and Github repository is encrypted through SSH, so we need to configure authentication information first

Run the following command to generate an SSH Key

ssh-keygen -t rsa -C "[email protected]"
Copy the code

After the SSH Key is generated, we go to its saved path ~/. SSH and open id_rsa.pub to copy the public Key inside

Then go to Github’s Settings Center, find SSH and GPG Keys, and click New SSH Key to set the SSH public key

Add and save the copied SSH public key

To verify the success, run the SSH -t [email protected] command

Next, let’s build a new repository on Github

After the creation is successful, the following information is displayed

There are hints above that allow us to create a new local repository or push an existing repository to the Github repository. Here we upload the direct demo directly to the Github repository

git remote add origin https://github.com/Morgan412/demo.git
git push -u origin master
Copy the code

The first time we were asked to enter our Github account password

Git Push pushes content from the local repository to the remote repository. You can refresh the Github repository page to see that the content has already been uploaded

Git push [remote-name] [branchname]

View the current remote repository

To view the remote repository servers you have configured, you can run the git remote command, which lists the abbreviations for each remote server you specify. You can also specify the -v option, which displays the git abbreviations you want to use to read and write the remote repository and their corresponding urls

To view more information about a particular remote repository, run the git remote show [remote-name] command

Grab and pull from remote storage

A command to get data from a remote repository

git fetch [remote-name]
Copy the code

This command accesses the remote repository and pulls all data from it that you don’t already have. Git Fetch Origin will fetch all the work that has been pushed since the clone (or the last fetch). It is important to note that the Git fetch command will pull data to your local repository. While it does not automatically merge or modify your current work, you can run Git merge [alias]/[branch] to merge branches

Now we modify the readme.md file in the remote repository on Github and run Git Fetch Origin

Git merge Origin /master

The readme. md file is merged and updated

If you have a branch set to track a remote branch, you can use the git pull

command to automatically fetch and merge the remote branch into the current branch. By default, the git clone command automatically sets the local master branch to the master branch of the remote repository where the clone is tracked. Running Git pull usually pulls data from the server where it was originally cloned and automatically attempts to merge it into the branch where it is currently located.

Remote repository removal and renaming

Git remote rm [name] can be used to remove a remote repository

Label management

Git can tag a commit in its history. You can use this to tag a release node (such as V1.0). The tag is also a snapshot of the repository

Command:

  • git tagView all labels
  • git tag <name>Create a label
  • git tag -v <name> -m <message>Create a note label
  • git push origin [tagname]Push the label to the remote repository
  • git tag -d <tagname>Delete the local repository label
  • git push <remote> :refs/tags/<tagname>Update the remote warehouse label

Create a label

Git tag

Git tag -v

-m

creates a note tag

Git tag

Git tag v1.0.0Copy the code

Git Tag allows you to view all tags

Late labeling

By default, the tag is on the latest commit. What if I want to tag a past snapshot? Well, you can

Git log –pretty=oneline –abbrev-commit

$ git log --pretty=oneline --abbrev-commitA9dec5d first commit 459f6FC (HEAD -> master, origin/master) Update readme.md e241626Copy the code

For example, I want to tag the “modify content” this commit

Git tag v1.0.1 e241626Copy the code

Tags operate

Shared label

By default, git push does not pass labels to the remote repository server. After creating the tag you must explicitly push the tag to the shared server. You can run git push Origin [tagname]

If you want to push many tags at once, you can also use git push with the –tags option. This will send all tags that are not on the remote repository server there

Remove the label

You can use the git tag -d

command to delete the tag from the local repository

Git push

:refs/tags/

= git push

:refs/tags/

= git push

:refs

Branch management

Branching is like a parallel universe in a science fiction movie, where while you’re trying to learn Git at your computer, the other you are trying to learn SVN in another parallel universe

If two universes don’t interfere with each other, it doesn’t matter who you are now. At some point, however, the two parallel universes merged, and you ended up learning both Git and SVN!

In practice, when you need to complete a requirement that may take 2 days to complete, you can create a new branch. Any changes to the branch will not affect the other branches. When you complete the requirement, you can merge the branches

Command:

  • git branchList branches with one in front of the current branch*No.
  • git branch <branchname>Create a branch
  • git checkout <branchname>Switch branch
  • git checkout -b <branchname>Create and switch branches
  • git mergeMerging branches
  • git branch -d <branchname>Delete the branch

Branch creation and merge

Create a branch

git branch <branchname>
git checkout <branchname>
Copy the code

To create a branch and switch to that branch at the same time, you can run a git checkout command with the -b argument, which is equivalent to the above two commands

git checkout -b newb
Copy the code

Git branch lists branches. The current branch is preceded by an asterisk

Merging branches

Once a branch has its own content, you will eventually want to merge it back into your main branch

Use the git merge command to merge any branches into the current branch

Let’s say we now have changes to the new branch, and now we want to merge it into the main branch

Merge conflicts

When Git cannot merge branches automatically, conflicts must be resolved first. After resolving the conflict, submit again, and the merge is complete

Conflict resolution is to manually edit the failed Git merge file into what we want and then commit it