Git Step by step– (2) Local repo

The previous article introduced Git in a nutshell, and built a git environment on the Windows platform, and now it's official git.

Git Basic concepts

Before you start using git, you need to introduce some concepts that have some basic understanding of git, which will help us a lot later.

In Git, each repository is called a Repository (repository), each repository can be simply understood as a directory, and all of the files in this directory are versioned through git, and git can track and record All updates that occur in the directory.

Now that we know what repository is (abbreviated repo), if we build a warehouse now (repo), there will be a ". Git" folder in this directory where the repository is built. This folder is very important, all the version information, update records, and GIT for warehouse management information are all stored in this folder. Therefore, do not modify/delete the files in order to avoid the loss of data.

For further explanation, please refer to the diagram below, which probably shows the basic knowledge we need to know (note that there are many other things in the ". Git" directory that are not covered in the diagram and are not explained here).

According to the picture above, a brief description of each section is given below:

• Directory: A catalog that is managed by Git, which is a repository that contains our workspaces and the management space of Git.
• WorkSpace: Directories and files that are checkout from the repository and that need to be versioned through git, which make up the workspace.
• . Git: A directory that holds git management information and is created automatically when the repository is initialized.
• Index/stage: Staging Area, or the update area to be submitted, we can put all the updates in staging area before committing to the repo.
• Local Repo: A native repository, a local repository, and a head that indicates the current development Branch (branch).
• Stash: is a working state save stack for saving/recovering temporary state in workspace.

With the understanding of the above concept, the following will start on the local repo on the git operation.

Create a warehouse

The git Bash command-line window allows you to enter the directory where you want to build the repository, and you can easily build a repository with Git init.

At this point, our warehouse directory will automatically generate a ". Git" folder, which is the directory of the Git management information we mentioned earlier.

Add to

Now we create a new "calc.py" file in the warehouse, the file content is as follows.

def Add (A, b):     Print A + b    if__name__"__main__":    Add (2, 3)

with "Git status" You can view the status of the workspace and see that the output shows that "calc.py" is not being tracked by git and that we can use "git add <file> ..." To add the file to the pending area (staging area).

Note that the update is only in workspace.

Use "git add calc.py" or "git Add.", then continue to view the status of workspace. This is the discovery file that has been put into staging area.

The update has been saved from workspace to the stage.

Finally, we can submit the update via "Git Commit-m". -M followed by a description of the commit (message).

The update is now saved from the stage to the local repo.

With the above operation, the file "calc.py" was successfully added to the repository.

Update

Suppose you now need to update the "calc.py", after modifying the file, review the status of workspace, you will find the prompt file is updated, but the update is only in workspace, not saved to staging area.

def Add (A, b):     Print A + b    def  Sub (A, b):    Print  A- b     if __name__ " __main__ " : Add (2, 3)

Similarly, with the add, commit operation, we can put the update of the file to staging area, and then from the staging area submitted to repo.

Note that only updates that are add to staging area will be submitted into repo. For example, the following sequence of operations, after the end of the operation only "multi" function update will be submitted to repo, "div" function update is also in workspace. This should also be easier to understand.

def multi (A, B):     Print A * b    def  Div (A, b):    if b! = 0         :  Print A/b    

Git diff

"Git diff" is a very useful and often used command. Based on the example above, we look at the diff of workspace and stage with "Git diff", and when we add the update to the stage, diff doesn't have any output.

Of course, we can also compare the status in workspace with the state in repo, the command is as follows, the head, will be explained later.

diff Head~n

Undo Update

According to the understanding of the basic concepts before, the update may exist in three places, workspace, stage and repo. Here's how to undo these updates separately.

Undo Updates In Workspace

Then the above example, we want to undo the "Div" function in Workspace update, you can see the "Git status" in the output of the prompt, we can use "Git checkout-<file> ..." (Be careful not to miss--) to undo the update in workspace.

Note that it is important to be cautious when using this method to undo an update, because the update will have no way to retrieve it after it is revoked in this way.

Undo updates in the stage

We added the update to the "div" function in workspace and used "git add" to submit the update to staging area. At this point, the "git status" output prompts us to move the staging area update to workspace via "git reset HEAD <file> ...".

If you want to continue to undo the updates in workspace, refer to the previous step.

Undo Updates in Repo

Before we introduce the update in undo repo, let's take a look at the "git Log" command, which allows us to view the history of commit. You can see the three commits we made.

where "Wilbertian" and "wilber***com" are the user names and mailboxes that we configured in the previous article.

Let's say we want to undo the commit "Add Mulit function in calc.py" Now, in two ways: using the head pointer and using the commit ID.

In Git, there is a head pointer to the latest commit in the current branch, and in the example above, the head is the corresponding 1a72f49ae49c1716e52c12f2b93fdcef6aac0886 (commit ID) this commit.

So you can use the following command to undo the "Add Mulit function in calc.py" commit. Note that the current version, we use "head^", then the previous version can use "head^^", if you want to fallback to the earlier submission, you can use "Head~n". (i.e., head^=head~1,head^^=head~2)

git rest--hard head^

Equivalent to

git rest--hard 1a72f49ae49c1716e52c12f2b93fdcef6aac0886

Again, the "Add Mulit function in calc.py" Commit has been revoked, viewing "calc.py" file, "Multi function" has also been deleted.

So here's the problem, and now I want to restore the "add Mulit function in calc.py" Commit, and of course git supports such operations.

Here's a look at the "Git reflog" command. "Git log" simply includes the commit record in the current branch, and "Git Reflog" records all the update records for all the branches in the repository, including the updates that have been revoked.

With this, we can find the "Add Mulit function in calc.py" commit, and then you can restore the undo operation to "Add Mulit function in calc.py" with the following command.

git reset--hard [email protected]{1}

Equivalent to

git reset--hard 1a72f49

Check again to see that our "Add Mulit function in calc.py" Update is back.

--hard and--soft

Before using reset to undo the update, we are using the "--hard" option, in fact, there is a corresponding "--soft" option, the difference is as follows:

• --hard: Revoke and delete the corresponding update
• --soft: Undo the update and put the updated content in the stage

This is no longer a demonstration of--soft.

deleting files

In git, if we want to delete a file, we can use the following command, "Git rm" compared to "rm" is just one more step to send this deleted update to the stage.

RM <file>

RM <file>

Delete operation is still very simple, there is no more demonstration.

Summarize

Through this article, I learned some basic concepts of git.

Then introduced the git Common command to operate the local repo, the content is more, but all is basic, as long as the hands-on operation once clear.

Here, the commands in the flow graph below are already introduced. We believe that with these commands, we can already do git version management of our local repo.

Finally, the same share the two Visio diagrams in the article.

Git Step by step– (2) Local repo