Git version control tool (2) ---- common operations on local version libraries, git ----

Git version control tool (2) ---- common operations on local version libraries, git ----

[Body]

In the previous chapter, we learned the most basic usage of Git, including installing Git, creating a version library, and submitting local code. More tips will be learned in this section. That is: Git version control tool (1) ---- install git and create a version Library

We must first make preparations and create a version library for a project. Here we will create a new Android project GitTest and create a version library. Open Git Bash, enter the root directory of the project, and execute the git init Command, as shown in:

 

In this way, the preparations are ready.

 

1. Ignore files:

The version library has been created. Next we need to submit the code in the project, but not all files need to be added to version control?

We need to know that in the Android project structure, files under the bin directory and gen are automatically generated, and we should not add these files to version control, otherwise, the file may be generated automatically. So how can this effect be achieved?

In fact, Git checks whether there is a file named. if a gitignore file exists, read the content of the file in one row and exclude the specified files or directories in each row from version control. Note that the "*" wildcard can be used for the specified file or directory in the. gitignore file.

[STEP]

Now, create a file named. gitignore under the root directory of the GitTest project, and then edit the content in the file. As shown in:

In this way, the files under the bin directory and gen are ignored so that they are not added to version control.

Remember, the encoding of The. gitignore file must be UTF-8:

Then you can use add to submit the Code:

git add .

Then run the commit command to complete the submission:

git commit -m "First commit" 

Note: After you modify and ignore the file, or add the file againMust be submitted again.

Q: If a file is added to the ignore file, even if the content is modified, the modification records can still be viewed through git status and git diff. Why? Is the ignore file invalid?

 

Ii. view the modified content: (before submission)

Git is better designed than other version control systems, because Git tracks and manages changes rather than files.

After a code submission, we need to continuously maintain the project and add new functions. Ideally, a commit is executed every time a small part of the function is completed. Git remembers the status of each commit.

Note: The changes shown here refer to the changes made before submission. If you have already submitted the file, enter this command immediately and you will not be able to see the modified content.

1. view the modified file:Git status

The method for viewing file modifications is very simple. You only need to execute the following command in the root directory:

git status 

Then Git will prompt that there are no files to be submitted in the current project, because we have just submitted them. Add a Button in the layout file. The Code is as follows:

<Button android: layout_width = "wrap_content" android: layout_height = "wrap_content" android: text = "first Button"/>

Then, enter git status to View Details:

The git status command allows us to keep abreast of the current status of the repository. The above command tells us that activity_main.xml has been modified, but this is only not submitted.

2. view the specific modification content of the file:Git diff

The previous git status command can view the modified file. To view the specific modification content, enter the following command:

git diff 

The execution result is as follows:

Git diff, as its name implies, is to view difference. The displayed format is the common diff format for Unix.

If you only want to view the changes in the activity_main.xml file, run the following command:

git diff res/layout/activity_main.xml 

The execution result is as follows:

3. Undo unadded changes:Git checkout

All modifications can be undone as long as the code is not submitted. You can run the git checkout command. Execute the following command:

git checkout -- res/layout/activity_main.xml 

After the script is executed, all the modifications made to the activity_main.xml file before the add operation are revoked.

Run the git status command again to check whether:

As you can see, the current project does not have any files that can be submitted, and the cancellation is successful.

4. Undo uncommitted changes: git reset andGit checkout

However, the above method only applies to files that have not executed the add command. If a file has been added, this method is invalid.

The following steps should be taken: first use the reset command to cancel adding (in this case, the content in the temporary storage area will be cleared, and all previous add operations will be invalid ), then, use the checkout command to undo the modified content. Execute the following command:

git reset HEAD res/layout/activity_main.xmlgit checkout -- res/layout/activity_main.xml

[Summary]

The command git checkout -- filename indicates that all modifications to the file filename in the workspace are revoked.

There are two cases:

• Readme.txt has not been put into the temporary storage zone after modification. Now, undo the modification and return to the same status as the version database;
• One is that readme.txt has been added to the temporary storage area and is modified again. Now, undo the modification and return to the status after it is added to the temporary storage area.

In one sentence, that is:Use the filename file in the temporary storage area to overwrite the filename file in the workspace..

Note: The "--" in the git checkout -- file command is very important. Without "--", it becomes the "Create a new branch" command, we will run into the git checkout command again in the branch management. 

5. delete an object:

When you delete useless files directly in the File Manager (ignore files here as an example), Git knows that you have deleted the files. Therefore, the workspace and version library are different. The git status Command will immediately tell you which files have been deleted:

 

Now you have two options. First, if you want to delete the file from the version library, run git rm to delete the file and commit:

git rm .gitignoregit commit -m "delete .gitignore"

Another case is that the file is deleted incorrectly and you do not want to delete it now. Because there is still a version library, you can easily restore the accidentally deleted file to the latest version:

git checkout -- .gitignore

Note:Git checkout replaces the version of the workspace with the version in the version Library (precisely the version of the temporary storage zone). You can "Restore it with one click" Whether the workspace is modified or deleted".

 

Iii. view submission records: (log command)

Whenever you think that the file is modified to a certain extent, you can "Save a snapshot", which is called commit in Git. Once you change or accidentally delete the file, you can restore it from the latest commit, and continue to work, instead of losing all the work in a few months.

After a project has been developed for several months, we may have performed hundreds of submissions. At this time, it is estimated that you have forgotten what you have modified each submission. But it doesn't matter. Git has always helped us record it.

We will now submit the previous changes:

git add .git commit -m "add button1"

Run the following command to view the submission record:

git log

The execution result is as follows:

As you can see, each submission contains four information: Submission id, Submitter, submission date, and submission description.

A large string similar to "3628164... 882e1e0" is the commit id (Version Number). Unlike SVN, Git's commit id is not 1, 2, 3 ...... The incremental number is a very large number calculated by a SHA1, expressed in hexadecimal notation, And the commit id you see is definitely different from mine, whichever is your own. Why does the commit id need to be represented by such a large number? Because Git is a distributed version control system, we need several people to work in the same version library later. If you use 1, 2, 3 ...... As the version number, it must conflict.

When many records are submitted, we only want to view one of the records. You can add the id of the corresponding record to the end of the log command and add the-l parameter. That is, git log [id]-l

If you want to view the modified content of the record submission record, you can add the-p parameter. That is, git log [id]-l-p

 

Iv. Version rollback:

Now we make the second modification. That is to say, add a button button2 to the layout file and execute the git log command. The result is as follows:

Show, we submitted three times in total.

Each time you submit a new version, Git will automatically concatenate them into a timeline. Run the following command to enter the visual interface:

gitk

The following page is displayed:

Now let's start our version rollback.

First, Git must know which version the current version is. In Git, use HEAD to indicate the current version. The previous version is HEAD ^, and the previous version is HEAD ^, of course it is troublesome to write 100 ^ in 100 versions, so it is written as HEAD ~ 100.

[Return the new version to the old version]

Now we can use the git reset command to roll back from Version 3 to version 2:

git reset --hard HEAD^

The execution result is as follows:

-- What is the significance of the hard parameter? I will talk about this later And feel free to use it for the moment.

Run the git log command again and find that version 3 is missing:

[Old version back to New Version]

What should I do if I want to return to "version 3" from "version 2? There are still some solutions.

As long as the preceding command line window has not been closed, you can search for it as long as you find the idnumber of version 3, that is, enter the following command:

git reset --hard 508972a

You do not need to write the version number completely. You can write the first seven digits, and Git will automatically find the version number.

If you want to roll back to a certain version, but the computer has been disabled, you cannot find the new version of commit id. What should you do? There are always methods. Git provides a commandGit reflogUsed to record each of your commands. Enter the following command:

git reflog

So we finally found the commit id of version 3. You can enter the same command back to version 3.

Now we can make a summary:

• HEAD points to the current version. Therefore,Git allows us to shuttle between version history and run the git reset -- hard commit_id command.
• You can use git log to check the versions to be rolled back.
• To return to the future, use git reflog to view the command history to determine which version to return.

 

5. Concept of workspace and temporary storage zone:

A difference between Git and other version control systems, such as SVN, is the concept of a temporary storage zone.

• Working Directory ):Is the directory you can see on your computer;
• Version Library (Repository ):There is a hidden directory ". git" in the workspace. This is not the workspace, but the Git version library.

The Git version library stores many things, the most important of which is calledStage (or index)And the first branch master automatically created by Git for us, and a pointer to the master is HEAD.

Note: The concept of branch and HEAD will be discussed later.

When we add files to the Git repository, we perform the following two steps:

• The first step is to use "git add" to add the file.Add file modifications to the temporary storage area;
• The second step is to use "git commit" to submit changes.Submit all content in the temporary storage area to the current Branch.

When we create a Git version library, Git automatically creates a unique master branch for us. Therefore, commit is to submit changes to the master branch. It can be simply understood that all file modifications to be submitted are stored in the temporary storage area, and all modifications to the temporary storage area are submitted at one time. Once submitted, if you have not made any changes to the workspace, the workspace will be "clean. That is: nothing to commit (working directory clean ).

Note: run the "git diff HEAD -- filename" command to view the differences between the latest version in the workspace and the temporary storage area.

We will explain how to use a remote repository in the next section.

 

Reference link: http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013743858312764dca7ad6d0754f76aa562e3789478044000