Introduction to GIT - Basic Concepts and Operations

[[141900]]

First of all, it must be pointed out that this article is not an article that explains the principles of GIT or is relatively in-depth. It is just a summary of the more commonly used requirements in daily development and a general explanation of the principles of these GIT commands. So mastering this can only be said to be able to cope with certain development needs. But if you are a person who pursues extremes and perfection. You should learn more about the specific model and implementation details of GIT. It should be noted that for technical things, you must first get started and then go deep into the theory. This is very important. Getting started allows you to practice continuously and deepen your understanding, rather than just talking about it on paper and looking at the theory without knowing where to start. In the application of GIT, we mainly master the common commands and scenarios for team development assistance in GIT. Before that, we need to introduce some essential concepts.

A. Basic Concepts

1. Repository

Repository, anyone who has used SVN should know that this is a version library. What is a version library? Simply put, it is a warehouse used to store and retrieve data, but we use it to store code to achieve code sharing in team development, so as to achieve collaborative work. Simply put, it is used to ensure the synchronization of code in a software project.

There are generally two version repositories in GIT, one is the local version repository, and the other is the server version repository (shared version repository). This is because GIT itself is designed as a decentralized (distributed) version controller. Its advantage is that when you don't have a network, you don't have to rely on the server version repository (shared version repository). Think about it, when you use SVN, can you do it without an Internet connection? If you want a project to be managed by GIT, there should be a .GIT folder in the same directory as the project. The local version repository is stored in this folder. At this time, when you don't have a network, you can manage the version locally. When there is a network connection, synchronize the local version repository with the shared version repository.

In GIT, we use the git init command to create and initialize a repository. It will automatically generate a .GIT folder and corresponding files, and then we can use GIT for version management. git init --bare is used (in a shared repository), because in a shared repository, we do not need a project folder (i.e., a workspace), because a shared repository is equivalent to a server that stores code and does not require a workspace.

all in all

1. git init is used in projects that need to be managed in our local workspace.
2. git init --bare is used to create a shared version library, which is used to synchronize with the local version library to realize a version library developed by multiple people.

2. Work Area

The so-called workspace is the folder where your project is located, which can be collectively referred to as a workspace.

3. Temporary storage area (stage, index)

This area is used to store all the files to be submitted to the local version library, called stage or index. When the git commit command is executed, the files in this area will be submitted to the local version library at one time. It can be understood as a cache area, which is used to cache files to be managed by the local version library. To add files to the staging area, you need to use the git add command to add them. In other words, submitting to the local version library requires two steps: git add + git commit. After executing these two steps, it is only submitted to the local version library, which can only be used by yourself. If you are in team development, you need to execute git push to submit to the shared version library.

4. HEAD pointer

In short, the HEAD pointer here is used to identify the current version. That is, we determine the current version by the version pointed to by HEAD, so when we switch versions, we change the direction of the HEAD pointer.

B. Basic Operations

1. Increase

From the GIT model, we know that to manage the local repository, we must first submit it to the stage. Then submit the stage to the local version library. I summarize this step as adding. This is analogous to the concept of adding in the database, which is convenient for learning. So what we call adding here is divided into adding to the stage and adding to the local version library. It should be clear that the addition of the local version library depends on the stage. Specific examples are demonstrated.

Since we want to simulate multi-person development, we must first complete the following preparations.

Preparation

1. Create a SWPTest folder, in which we will create a workspace for user A and a shared code library.

Perform the following operations

 mkdir SWPTest
 cd SWPTest/
 mkdir AWorker sharedRep

2. Create a shared version library (simulating a remote version library)

 cd sharedRep
 git init --bare

3. User A downloads the version library from the server and prepares to work. And adds the .gitigonre ignore file (used to filter out files in the project that are not submitted to the version library for management). (Remember to execute the command in the root directory of SWPTest)

 cd AWorder
 git clone ../sharedRep/
 touch .gitignore // Create a .gitignore file in the workspace  
 open .gitignore
 git add .gitignore // After executing this step, the .gitignore file in the workspace is submitted to the temporary storage area (cache area)  
 git status -s //Query the file status of the working area and the temporary storage area (understanding the file status is the key point)  
 git commit -m "add gitignore file"      // After execution, submit the contents of the temporary storage area to the local version library at one time. At this time, the temporary storage area is cleared.  

Then paste the ignore information of object-c into the .gitignore file. (Search gitignore on Github)

Summary: The above three steps are to create the server-side version library (1, 2), and clone it to the local client (3) (if the project does not have a gitignore file, it is best to add it yourself, and add it to the local version library and the server version library (shared version library)).

Summary of additions (three different additions)

 1. Add to stage (submit): git add <file> // <file> value is the file to be managed by git. The last small step of the third step above is to add to stage   
 
 2. Add (commit) to the local version library: git commit // Based on stage cache   
 
 3. Add (submit) to the shared version library: git push origin master // Submit all data in the current staging area to the shared version library (remote version library)   
 
 
 After completing the above three steps, you can also immediately synchronize the file to the shared code library for the convenience of other colleagues.
 git push origin master // Commit to the main branch  

2. Delete

Before deleting the simulation, we first do the following preparations to create three source files: am, bm, cm. And prepare to hand them over to the local version library for management. So add them to the stage. The details are as follows

 suweipeng:sharedRep sixleaves$ touch am bm cm
 suweipeng:sharedRep sixleaves$ git add *.m
 suweipeng:sharedRep sixleaves$ git status -s
 A am
 A bm
 A cm
 suweipeng:sharedRep sixleaves$

When you query the file status of the current staging area, you will find that it has become A (the first column indicates the staging area, and the second column indicates the working area), which means it has been added to the staging area and the status is A (add). Then we start to study deletion. Through the model, we can know that there are three places to store files in git, namely the working area, the staging area (stage), and the branch. Therefore, we should ask ourselves a question before learning, if there is a deletion operation, which area is it for. Let's understand it through specific operations, as follows (delete the cache area and the working area together)

 suweipeng:sharedRep sixleaves$ git rm am
    error: the following file has changes staged in the index:
 2.
    (use --cached to keep the file, or -f to force removal)
    suweipeng:sharedRep sixleaves$ git rm -f am
 rm 'a.m'  
    suweipeng:sharedRep sixleaves$ ls -al
 total 8  
    drwxr-xr-x 6 sixleaves staff 204    7   twenty one   16 : 43 .
    drwxr-xr-x 3 sixleaves staff 102    7   twenty one   11 : 34 ..
    drwxr-xr-x 13 sixleaves staff 442    7   twenty one   16 : 43 .git
    -rw-r--r--@ 1 sixleaves staff 836    7   twenty one   15 : 59 .gitignore
    -rw-r--r-- 1 sixleaves staff 0    7   twenty one   16 : 27 bm
    -rw-r--r-- 1 sixleaves staff 0    7   twenty one   16 : 27 cm
    suweipeng:sharedRep sixleaves$

The first line means to remove the file am from the workspace and mark the corresponding file in the temporary storage area for deletion. However, an error message appears. According to the prompt, we can use -f to force execution.

Git 2.0 already supports a more understandable way to delete files.

New Method:

Now we can use the system's own rm program to delete it directly instead of using git rm. The steps are as follows

1. Use rm to delete files in the workspace.
2. Use git add <deleted file name> to add the deletion of the working area to the staging area. (Delete the specified files in the working area and staging area)
3. Use git commit -m "delete file b". Delete the file from the local repository. (Delete the workspace, temporary storage area, and the file specified in the local version library)
4. Use git push origin master. At this time, not only the files in the local repository can be deleted, but also the files in the shared repository. ((Delete the files in the workspace, temporary storage area, local repository, and shared repository).

You may wonder, what if the file has been submitted to the local repository? If you just want to delete it from the local repository, you cannot use this new method, because this method requires you to delete the file in the working area and delete it in the repository as well. So how to deal with this requirement, please see below.

Analysis of git rm: Now let's verify the scope of git rm. When verifying, I only have one em file left, and it has been handed over to git for management. Now recreate bm and cm and hand them over to git for management.

Specific analysis: First, how to verify that git rm -f am deletes these two areas? If a file has been submitted to the version library, will the use of this operation affect the version library at this time? The answer is no, it only affects the temporary storage area and the working area, that is, it only deletes the elements of these two areas. The verification idea is very simple. We create a file zm and then submit it to the local version library for management. After submission, the temporary storage area is cleared, so only the version library and the working area have this file. At this time, we execute git rm, then synchronize to the shared version library, and then clone the shared version library in the working directory of another employee to see if zm exists. If zm exists, then git rm will not affect the existing files in the version library.

In AWorker's workspace, there are two files in AWork's staging area at this time, which are submitted to the local version library for management. And synchronized to the shared version library. Then we delete the bm file with git rm. Since the file does not exist in the staging area at this time, but exists in the work area, git rm will not prompt an error. At this time, assuming that git rm has an impact on the local version library, we synchronize the local version library to the shared version library. If there is an impact, the file will not exist in the shared version library at this time. So we perform git pull instructions in BWorker to verify.

AWorker

 suweipeng:sharedRep sixleaves$ git status -s
 A bm
 A cm
 suweipeng:sharedRep sixleaves$ git commit -m "add b, c files"  
 [master b8e8cc9] Add b and c files
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bm
 create mode 100644 cm
    suweipeng:sharedRep sixleaves$ git push origin master
    Counting objects: 2 , done.
    Delta compression using up to 4 threads.
    Compressing objects: 100 % ( 2 / 2 ), done.
    Writing objects: 100 % ( 2 / 2 ), 288 bytes | 0 bytes/s, done.
    Total 2 (delta 0 ), reused 0 (delta 0 )
    To /Users/sixleaves/SWPTest/AWorker/../sharedRep/
       97b6aa0..b8e8cc9 master -> master
    suweipeng:sharedRep sixleaves$ git rm bm
 rm 'b.m'  
    suweipeng:sharedRep sixleaves$ ls -l
 total 0  
    -rw-r--r-- 1 sixleaves staff 0    7   twenty one   17 : 27 cm
    -rw-r--r-- 1 sixleaves staff 0    7   twenty one   17 : 16 em
    suweipeng:sharedRep sixleaves$ git push origin master
 Everything up-to-date
    suweipeng:sharedRep sixleaves$

Execute the git pull command in BWorker. The details are as follows. We can see that after the pull, bm cm em exists in the BWorker working area. So we can conclude that git rm only targets the working area and the temporary storage area. When the file exists in both areas at the same time, the deletion operation will fail. We need to explain in detail whether we want to save the files in the working area.

BWorker

 suweipeng:sharedRep sixleaves$ pwd
    /Users/sixleaves/SWPTest/BWorker/sharedRep
    suweipeng:sharedRep sixleaves$ git pull
    remote: Counting objects: 2 , done.
    remote: Compressing objects: 100 % ( 2 / 2 ), done.
    remote: Total 2 (delta 0 ), reused 0 (delta 0 )
    Unpacking objects: 100 % ( 2 / 2 ), done.
    From /Users/sixleaves/SWPTest/BWorker/../sharedRep
       97b6aa0..b8e8cc9 master -> origin/master
 Updating 97b6aa0..b8e8cc9
 Fast-forward
 bm | 0  
 cm | 0  
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bm
 create mode 100644 cm
    suweipeng:sharedRep sixleaves$ ls -al
 total 8  
    drwxr-xr-x 7 sixleaves staff 238    7   twenty one   19 : 00 .
    drwxr-xr-x 3 sixleaves staff 102    7   twenty one   17 : 18 ..
    drwxr-xr-x 15 sixleaves staff 510    7   twenty one   19 : 00 .git
    -rw-r--r-- 1 sixleaves staff 836    7   twenty one   17 : 18 .gitignore
    -rw-r--r-- 1 sixleaves staff 0    7   twenty one   19 : 00 bm
    -rw-r--r-- 1 sixleaves staff 0    7   twenty one   19 : 00 cm
    -rw-r--r-- 1 sixleaves staff 0    7   twenty one   17 : 18 em
    suweipeng:sharedRep sixleaves$

Finally, the summary for these three areas is as follows

1. Deletion of the working area: (If the file has been submitted to git management) In this case, the version library must also be synchronized, so it is actually the complete process of the new method. If it has not been submitted to git management, you can directly delete it with rm.
2. Deleting the staging area (without deleting the working area): git rm <file name> --cached
3. Deleting branches (version repositories): Deleting branches is actually unnecessary, because a new version is generated every time a commit is made. If something goes wrong, we can directly use git reset to roll back the version. So if you want to delete the version repository, you can only use version rollback. Others:
4. To delete both the working area and the staging area: git rm -f <file>

3. Change

One thing that needs to be made clear is that when you give a file to git for management, once you modify a file (regardless of line breaks or spaces), git will track the changes to the file. That is, you must add it to the staging area after each modification, and then commit it. There are always three things to do! ! ! Each time you modify it, you must add it to the staging area to keep the latest status of the file in the staging area, so that after committing, the file saved in the version library is the file we modified! ! ! ! I think it is relatively simple to modify it with just this point in mind, so you can refer to the official documents for specific operations.

So I divide changes into two types: one is the "change" for coding your own programming tasks, and the other is the "change" for updating the latest code from the shared version library. I will not repeat the former, but briefly talk about the latter.

In git, we can use git pull to update a local repository that has been associated with a shared repository, and the corresponding workspace. Strictly speaking, git pull = git fetch + merge. That is, one step is to fetch data, and the other step is to merge data, so git pull may cause data conflicts when merging. The solutions to conflicts will be introduced in detail later. For now, just master the simple update operation.

4. Check

There are two types of checking: one is to check the version record, and the other is to check the difference between the files in the temporary area and the working area to determine when to update the files in the temporary area.

View version records: This is to view the version (git log, git reflog). The former is the currently traceable version, and the latter is the version in the history. Generally, if we want to roll back a version, it is more convenient to use git reflog, which should be able to view the history of all versions.

suweipeng:sharedRep sixleaves$ git log
commit 7f0486eda9bfcaaae56ec8382be580d446d854d3
Author: sixleaves <[email protected]>
Date: Tue Jul 21 20:09:53 2015 +0800

Added main.m

commit 97b6aa090388d0fc1b73eaeb615d86faf83807f7
Author: sixleaves <[email protected]>
Date: Tue Jul 21 17:20:05 2015 +0800

Delete file b

commit ef1169ef156294cfd68ac10b568781ca9ab4a15c
Author: sixleaves <[email protected]>
Date: Tue Jul 21 17:16:46 2015 +0800

Added e-file

commit 4eb100209198d1f5c7bf914bdf9776795f7753f1
Author: sixleaves <[email protected]>
Date: Tue Jul 21 17:15:00 2015 +0800

Added b-file

suweipeng:sharedRep sixleaves$ git reflog
7f0486e HEAD@{0}: commit: added main.m
97b6aa0 HEAD@{1}: reset: moving to 97b6aa0
b8e8cc9 HEAD@{2}: commit: add files b and c
97b6aa0 HEAD@{3}: commit: delete file b
ef1169e HEAD@{4}: commit: added e file
4eb1002 HEAD@{5}: commit: added b file
a18151c HEAD@{6}: commit (initial): add gitignore file
suweipeng:sharedRep sixleaves$

View the file status of the workspace:

The git status command will compare the staging area with the working area. If the staging area does not exist but the working area does, two "?" will be displayed, indicating that it has not been submitted to git for management. At this time, you can execute the git add command to submit it to the staging area. At this time, the file status of the staging area becomes A, indicating that it has been added to the staging area. At this time, if it is submitted to the local version library, git can manage the file. Therefore, using git status to query at this time will have no results, because the staging area has been emptied (emptied after executing git commit), and the files in the working area have been handed over to git for management, and no changes have been sent.

suweipeng:sharedRep sixleaves$ git status -s
?? 1.m
suweipeng:sharedRep sixleaves$ git add 1.m
suweipeng:sharedRep sixleaves$ git status -s
A 1.m
suweipeng:sharedRep sixleaves$ vim 1.m
suweipeng:sharedRep sixleaves$ git status -s
A 1.m
suweipeng:sharedRep sixleaves$ vim 1.m
suweipeng:sharedRep sixleaves$ git status -s
AM 1.m
suweipeng:sharedRep sixleaves$ git add 1.m
suweipeng:sharedRep sixleaves$ git status -s
A 1.m
suweipeng:sharedRep sixleaves$ git commit -m "Add 1.m"
[master f6378aa] Add 1.m
 1 file changed, 1 insertion(+)
 create mode 100644 1.m
suweipeng:sharedRep sixleaves$ git status -s
suweipeng:sharedRep sixleaves$

If you modify the main.m file and check it again, the second column will become a red M, indicating that the file in the working area has been modified. At this time, the file in the git version library is different from the file, so if we want to synchronize them, we must first perform git add. At this time, the file status changes from M in the working area to M in the staging area, and turns green, and the M in the working area disappears.

At this point, you can use git diff to view the specific changes in the working area and the staging area.

suweipeng:sharedRep sixleaves$ touch 2.m
suweipeng:sharedRep sixleaves$ git add 2.m
suweipeng:sharedRep sixleaves$ vim 2.m
suweipeng:sharedRep sixleaves$ git status -s
AM 2.m
suweipeng:sharedRep sixleaves$ git diff
diff --git a/2.mb/2.m
index e69de29..abe4786 100644
--- a/2.m
+++ b/2.m
@@ -0,0 +1 @@
+ddddd
suweipeng:sharedRep sixleaves$

The above picture means that after the change, a new line ddddd is added to the file

Check summary

1. Use git log or git reflog to query version records.
The former records the iteration order of the current version number (which may be overwritten due to rollback).
The latter records all historical version records. (The latter includes the former).
2. Use git status -s to know whether the data in the temporary storage area is the latest and whether there are any files that have not been added to the temporary storage.
3. If the data in the staging area is not up to date, you can use git diff to view the changed data.

Format description in git diff

---: Indicates the file before the change (workspace file).
+++: Indicates the changed file (temporary storage area file).
Lines without minus or plus signs indicate unchanged lines.
The - sign indicates the lines deleted from the first file, and the + sign indicates the lines added to the second file.
@@ -1,7 +1,7 @@ The minus sign and plus sign in this sentence represent the first file and the second file respectively.

Summary of file status:

Supplement: The difference between D in the temporary storage area and D in the working area:

1. If the first column, that is, the temporary storage area, displays a green D, it means that the file has been deleted from the workspace and the deletion mark has been submitted to the temporary storage area. At this time, if git commit is executed again, it will be deleted from the version library.
2. The red D in the second column indicates that the file in the workspace has been deleted, but the deletion operation has not been submitted to the temporary storage area.
Only when it is submitted to the temporary storage area will there be a chance to delete it in git.

The red and green colors are just to allow you to quickly distinguish the modification status of the file status in the temporary storage area and the working area.

This is the first article about GIT. If you have any questions, please leave me a message and we can communicate with each other. The following articles will introduce conflict resolution and other issues in GIT.