An overview of the

This blog post is intended to give beginners a quick start on Git and meet the basics of their work, rather than tease out the details. A follow-up series will explore Git in detail.

Git installation

This part of the website information is very much, according to their own system version to find information and download the installation package to install.

Git configuration before first use

1. Configure the user name and email address

git config --global user.name "user_name" git config --global user.email "email_address" 
Copy the code

2. View the configuration

git config --list
Copy the code

3. Theoretical basis

1. Why master Git commands

Many users may be used to the Windows operating mode and are opposed to the command line. In addition, there are some Git graphics tools like TortoiseGit and SourceTree on the market, and the experience is still ok. However, Git is designed to make users feel more stupid than they think. Git has so many powerful functions, but only a few of them are packaged in the graphical tool, and the command line is full of functionality. Second, many veterans look back and say that Git learning really needs to be a bottom-up process. Master the command line, using graphical tools such as the box. On the contrary, I do not know why, if the back of the problem, will catch blind cough up.

2. How are so many different versions saved

  • SVN Recording Principle

The SVN records the contents of each version change. In other words, SVN only saves differences.

  • Git Recording Principle

Git records each version separately. For example, if there are five versions of File1, there will be five copies. This may seem like a waste of space, but it brings a lot of convenience in branch management.

3. Workspace, staging, and Git repository

  • Workspace: Is where we store code, visible and tangible.
  • Staging area: This is actually a file that holds our changes.
  • Git repository: The ultimate repository for all of our release data. The HEAD pointer points to our most recently committed version.

4. Git workflow

  • Add, delete, and modify files in the working directory;

  • Put the files that need to be versioned into the staging area;

  • Commit the staging files to the Git repository.

5. Git managed file status

  • Modified;

  • Passage Ten;

  • Committed.

Create warehouse, pull code, add to temporary storage area, submit

Take positions 1.

  • Create a new project (blank directory)

Run the following command in the newly created empty directory to create a warehouse:

git init
Copy the code

After the warehouse is created, you can see that a.git directory has been added to the empty directory. This directory is used to track version iterations.

  • Existing project code warehouse

Once in the project code root directory, execute git init.

2. Pull code from the server

  • The default mode

    Git Clone repository addressCopy the code

  • Pulls the specified branch

    Git clone -b branch_nameCopy the code

We can specify clone branches by adding the -b branch_name option

  • Pull all the branches

3. Add the file to the staging area

  • Create a new readme.txt containing part of the description information (this happens in the workspace). Then add it to the staging area:

    git add Readme.txt
Copy the code

  • If we modify many files, adding one by one is too tedious. You can run the following command to add the workspace changes to the staging area:

    git add -u
Copy the code

4. Commit the changes in the staging area to Git repository

  • Commit your changes to the Git repository by typing the following command:

    git commit -m "log"
Copy the code

  • We can also skip adding staging and commit files directly to Git repository:

    git commit -am "log"
Copy the code

View working status and historical submissions

1. Check the status

We can use the following command to view the current status:

git status
Copy the code

2. Update the status of temporary storage area

A file has been added to the staging area, but it has been modified in the workspace, so you can run Git add again to update the state in the staging area.

3. Restore the workspace

If we make changes to a file in the workspace and the changes are no longer needed, we can restore the file in the workspace by executing the following command:

git checkout -- file_name
Copy the code

Note here that if the file is present in the staging area, the workspace is overwritten with the staging version. If the file is not in the staging area, the version in the workspace is overwritten with the version in the Git repository. If you want to restore to a Git repository version, you can use:

git reset HEAD file_name
Copy the code

Remove it from the staging area before using it again:

git checkout -- file_name
Copy the code

This restores the files in your workspace to the state in your Git repository.

4. View historical submissions

Git logs can be used to view historical commits. The COMMIT ID is calculated based on SHA1. Why not sort from 1, like SVN? Because Git is distributed, this can cause conflicts.

5. Git log options

  • — Decorate: Displays each commit reference (branches, tags, etc.);

  • — Oneline: single line display (simplified version of log)

  • –graph: Graphically view commit

  • –all: View the commit of all branches

6. Go back in time

1. Reset command — overwrite the staging area with the version in the Git repository

  • Overwrite staging area with the version referred to in Git repository HEAD (specified file)

    git reset HEAD file_name
Copy the code

  • Overwrite staging area (all files) with the version referred to in Git repository HEAD

    git reset HEAD
Copy the code

How do I override the staging area with another version in the Git repository

First, assuming that all of our changes in the workspace have been added and committed, the current state can be represented as follows:

Next, use the reset command to roll the snapshot back and forth:

git reset HEAD~ 
Copy the code

~ indicates the previous version to which HEAD refers, and so on. If ~ is too much, you can add a number after ~ to specify it

The rollback status is as follows:

Note that the reset command actually contains two actions:

  • Moving the HEAD pointer points it to the previous snapshot. (The HEAD pointer has been changed so that when you look at the log, you don’t see the last committed information. Git reflog to see all the logs).
  • Overwrite the staging area with the snapshot pointed to after the HEAD move.

2. Reset option

  •  –mixed

    git reset --mixed HEAD~ 
Copy the code

— Mixed is the default option and will be added automatically if it is not written

Move the HEAD to point to the previous snapshot. Overwrite the staging area with the snapshot pointed to after the HEAD move.

  •  –soft

    git reset --soft HEAD~
Copy the code

With the –soft option, just move the HEAD pointing to the previous snapshot, but not overwrite the contents of the staging area.

This usage is usually used to undo a bad COMMIT.

  • –hard

    git reset --hard HEAD~6
Copy the code

Move the HEAD to point to the previous snapshot. Overwrite the contents of the staging area with the snapshot pointed to after the HEAD move. In addition, files in the staging area are restored to the workspace (the state of the Git repository version referred to by HEAD).

3. Use commit ID to reset

git reset  commit_ID 
Copy the code

We can also use the commit ID to specify which version to reset to (not all ids, just enough to identify it).

4. Roll back certain files

git reset commit_ID file_name
Copy the code

When individual files are rolled back, the HEAD pointer does not move.

If you reset your computer, you can move it forward

git reset commit_ID
Copy the code

Use as necessary –hard

Vii. Version comparison

1. Compare the difference between workspace and staging area

git diff
Copy the code

2. Compare two historical commits

git diff commit_ID1 commit_ID2
Copy the code

3. Compare the commit in your workspace and Git repository

git diff commit_ID 
Copy the code

The commit ID can also be HEAD

4. Compare staging and Git repository snapshots

git diff --cached/--staged [commit ID]
Copy the code

If you do not specify a snapshot ID, the snapshot will be compared with the latest commit in the repository by default

5. Diff function overview diagram

Eight, commonly used tips

1. Modify the last submission

  • Scenario 1: The code has been committed to the repository and suddenly remembers that there are two files that have not been added.

  • Scenario 2: The code has been committed to the repository and suddenly remembered that the log was not fully written.

Git “corrects” the last commit by executing the commit command with the –amend option.

Git commit — Amend can modify the log in the next interface

Git commit — amend-m “new log” commit the new log directly

2. Delete files

git rm file_name
Copy the code

This command deletes only files in the workspace and staging area, that is, untrace them, and does not put them under version control the next time they commit. Files that have been committed to the Git repository are not deleted and need to be removed by moving the HEAD pointer.

If it is deleted by mistake, you can run the following command to restore it:

 git checkout -- file_name
Copy the code
  • There are differences between workspaces and staging areas

Git RM will report an error if the contents of a file are inconsistent between the workspace and staging. We can use:

git rm -f file_name
Copy the code

This will delete the files in both the workspace and staging area.

To delete only the files in the staging area and save the files in the workspace, run:

git rm --cached file_name
Copy the code

3. Rename the file

git mv old_name new_name
Copy the code

Ix. Branch and branch management

1. What are branches? Why branches?

2. Create a branch

git branch branch_name
Copy the code

Example Create branch Branch_name

git checkout -b branch_name
Copy the code

Create branch Branch_name and switch to this branch

3. Switch branches

git checkout branch_name
Copy the code

4. View branches

  • Viewing local branches

    git branch -v
Copy the code

  • Viewing remote branches

    git branch -r
Copy the code

  • View local and remote branches

    git branch -a
Copy the code

5. Merge branches

git merge branch_name
Copy the code

Merge branch_name into the current branch.

If conflict is displayed during merge, resolve the conflict manually. Git adds hints to conflicting files.

6. Delete the branch

git branch -d branch_name
Copy the code

When you look at the log after deleting the branches, you can see that although the branches are gone, the Commit IDS on those branches still exist.

7. Anonymous branches

git checkout commit_ID
Copy the code

This is the detached header pointer state. Because we used the checkout command but didn’t create a new branch, Git created an anonymous branch. Since it is an anonymous branch, if we switch to another branch, all operations in the anonymous branch are discarded. So we can do some experiments with anonymous branches, but it doesn’t really matter. If you want to keep anonymous branches, follow Git’s instructions to create a formal branch.

8. The local branch is associated with the remote branch

git branch --set-upstream-to=origin/<remote_branch> local_branch
Copy the code

After creating a local branch with Git, you need to do remote branch association. If there is no association, Git will prompt you to add the association as shown in the following operations.

The purpose of the association is to perform git pull, Git push operations do not need to specify the corresponding remote branch, as long as you do not display the specified, Git pull, will prompt you.

10. Push local changes to the server

As mentioned earlier, Git is a distributed VCS tool. We have our own repository locally and we have a server-side repository. To ensure that someone else’s Clone code includes our changes, we push our local changes to the server side.

We push local changes to the server using git push:

Git push < remote hostname > < local branch name >Copy the code

Origin is usually used for remote host names.

1. Omit the remote branch name

Represents pushing a local branch to a remote branch with which it has a tracing relationship (usually with the same name). If the remote branch does not exist, it is created.

  • Origin: indicates the name of the remote host

  • Master: local branch name

    git push origin master
Copy the code

2. Omit the local branch name

Deletes a remote branch. This operation is equivalent to pushing an empty local branch to a remote branch.

  • Origin: indicates the name of the remote host

  • Refs /for/master: name of the remote branch

    git push origin :dev
Copy the code

3. Omit both the local and remote branch names

If the current branch is traced to the remote branch, both the local and remote branches can be omitted and the current branch can be pushed to the corresponding branch of the Origin host.

git push origin
Copy the code

4. Omit the remote host name, local branch name, and remote branch name

If the current branch has only one remote branch, then the host name can be omitted:

git push
Copy the code

5. Push, reject, reject

If our native code is not the latest version on the server, the push code will be rejected. At this point we need to update the local code before pushing it to the server.

git reset --hard
Copy the code

Restore the local code to its latest COMMIT state

git pull --rebase
Copy the code

Merge server updates locally

Update local code

As mentioned above, Git is a distributed VCS, and many people push changes to the server. Let’s see how we can synchronize updates locally from the server.

1. The local branch has only the master branch and is not modified

At this point, the native code is clean, so you can update it directly using Git pull.

2. The local node has only the master branch and has been modified

  • Modification Needs to be Retained

Push the changes to the server and then use Git pull to update them.

  • Modification is not required.

Since the changes don’t need to be kept, you can use git reset –hard to restore the code to a clean state and use it again

Git pull to update.

3. Modify data locally on its own branch

Since we made the change on our branch (let’s say myBranch), the master is in clean state. At this point, there are four steps:

  • Switch to the Master branch:

    git checkout master
Copy the code

  • Update master branch:

    git pull
Copy the code

  • Switch to the MyBranch branch:

    git checkout mybranch
Copy the code

  • Merge the master branch into myBranch:

    git merge master
Copy the code