Git Learning (ii) _ Using Git

The Git tool has been installed and tested successfully, and the next step is to use it specifically.

First, set up the developer's personal information

There are multiple developers in any system (multi-person collaborative development), and in Git, for each developer (stand-alone), developers need to define their own name and email address to contact.

Setting Global information

Git is a distributed version control system, each single machine has its own basic information: developer name, email address, etc.

姓名：git config --global user.name"shmily"email:git config --global user.email"[email protected]"查询全局信息：git config -l

Ii. Creating a warehouse (repository)

Create a repository (repository)
Repository is the repository, everything in this warehouse will be managed by git, all the files in the repository are changed, deleted, updated, and can be restored to a certain state at any time.
Initialize the warehouse: git init
If you are developing a project, you must first create a warehouse and select a disk in your computer to create a folder, such as:

d:md myproject

At this time to define the D disk created in the MyProject file for the warehouse, first into the folder;

cd myproject

Then initialize the repository (change this directory into a repository that can be managed by git)

git init

Note at this point in the MyProject file, a " .git " directory is created, which is the repository information, cannot be changed, and cannot be deleted. Unlike the SVN, CVS, and other version control systems, SVN, for example, creates an. svn folder under each subdirectory that contains configuration files that establish a trace of the repository (in fact, this is the commonality of the version control system). These profiles record information such as the file name, modification time, and version of the workspace, and can quickly scan the workspace for changes by comparing timestamps. A copy of the original file is also included under the. SVN folder, which can be operated independently from the repository. In addition, the SVN repository is detached from the workspace.

Note: The SVN directory is not a local repository, but a configuration file introduced to establish an association with the remote repository, so SVN's repository is detached from the workspace.

The advantage of the SVN design is that it can be submitted at the time of submission only for the variance section, since the modified file can be compared to the original copy of the file. However, the disadvantage is that it doubles the workspace space, and when searching for file content in the workspace directory, it .svn doubles the search results because the catalog also has copies of the original files, confusing the real search results.

Third, add the file

Once the warehouse is created, the basic management of the file can be done. It is recommended that all the files are in UTF-8 encoded format to avoid problems such as coding errors.
Create a new file that is hello.java stored D:/myproject under a file that belongs to the GIT repository management directory. Use the following command to view the current status:

git status

git statusThere are a few hints that can be found on the status query operation:

• The current development belongs to the main branch: on Branch master;
• Initialization of the warehouse submission: Initial commit;
• unlabeled file: untracked files
• There are also prompt commands: (use "git add ..." to include-in-what'll be committed)
• A list of unmarked files, with only one example: Hello.java

Add File to Warehouse

• Add files to Staging area: git add 文件名称 ;

• Submit file:git commit -m"注释"

  add hello.java

  Then query the status git status
  

Now the file is not actually committed to the main branch (the main branch is all the code for the program that really wants to run).

Note: All modified code will be automatically monitored by git, and all code must be added to staging area before using commit, otherwise no code will be submitted.
The code is submitted here and can be add commit combined and executed in one stepgit commit -a -m"注释"

Submit file information, after executing this command, the hello.java file is submitted to the main branch, which means the program is published successfully. For example:

commit -m"new java file to be create"

Each commit the user commits under the Git tool is actually logged, and the commit log information can be viewed at this time. git log 文件名you can use it to view detailed log information.

Note: A string of strings in the commit message can be interpreted as a unique ID number for each commit, and multiple commits.

Iv. Modification of warehouse files

After the file has been modified

• View the results of the changes: git status ;
• Modified before and after file comparison: git diff 文件名称 ;
• View operation log: git log 文件名称 ;

Here I have modified the Java file just created hello.java using git status view modified state as shown in:

Can be a single-pole now git prompt user, the file is not saved to staging area, prompt to either save the file to staging area or restore the file, but also explained that has been modified hello.java .
View files before and after differences

git diff hello.java

After confirming the modification, add the modified code content to staging area and submit it.

-a-m"update hello.java file add one print"

V. Work area and Staging area

In the GIT learning process, there are several important concepts that must be understood: workspaces, staging Area, and repositories. These concepts make Git version control more convenient and efficient. While git differs from other version control systems in that it is staging area, in fact, if you understand staging area, other commands for Git will be understood quickly.

Workspace: A simple understanding is a folder that needs to be versioned (here my folder is MyProject), this folder has some special--more .git this hidden folder

Repository : folders under the MyProject folder .git are repository

Staging Area: Staging area can be understood as a virtual workspace that tracks file changes in the workspace (actions such as add-ins). This workspace is located under .git the directory under the folder index

It's important to understand that when you need to commit changes to a workspace, staging area will compare to the workspace, and if the workspace is inconsistent with the staging area file, you'll need to synchronize the modifications of the workspace to staging area before you can commit to the repository. In this sense, staging area can be said to be a bridge between workspace and repository. The benefit is that you can do whatever you want before actually committing to the repository and push it to the repository when you need to commit it.

Git's father Linus originally designed staging area because each time in SVN commit need to select the file to be submitted to the repository, found that this feature is too chicken. So he thought if you can really commit make any changes, these changes can be placed in the staging area, if you regret not only can be very convenient to undo, and will not affect the existing repository.

The following diagram understands the relationships between workspaces, staging area, and repository:

The following information can be drawn from this diagram:

Git's operations revolve around the workspace, staging area (the index in the diagram), the repository (the master in the diagram, which is actually the main branch of the repository), the object library (the objects in the diagram) Several sections of the
Workspace, staging area, and repository maintain a directory tree
objects identified by the Git object library, which is actually located in the . Git/objects Directory
The staging area trace records the file name and status (modification time, file size, and so on) of the workspace
The head in the figure is a reference to the latest commit, which can be changed by the version fallback by changing the HEAD's point
Execute git The Add updates the staging area tree and generates an object for the workspace's file contents into the Objects object library, where staging area records the index of the object index
execution git commit the repository's directory tree is updated, commit succeeds after the repository points to the directory tree is the staging area tree
in the diagram there are other commands, here can be temporarily ignored, will slowly understand later. Now you just need to understand the two commands, git add and git commit .
Since staging area keeps track of file changes in the workspace, how is git implemented? The answer is time stamp. You can use the command git status to view the differences between your workspace and staging area, and when you execute git status , you will first go to . Git/index To view the timestamp of the workspace file being tracked, if the timestamp of the file has changed since the last time that git add was executed (execution of git add allows the workspace file to be tracked), then the file has been altered. The original file with staging area is then compared to the file in the workspace, and if two files are found to be inconsistent, the difference is given.
The following specific implementation process, the last few pictures, it is clear:
First step: Workspace Authoring Program

Step Two: Add Files to Staging area (git add)

Step Three: Submit to master Branch

Six, version fallback

Each time a user submits their own code to the repository, a record is automatically generated to commit save the operation, and each record is automatically generated commit ID with a unique identity.
View logs: git log --pretty=oneline 文件

Note: A commit ID is generated whenever the user commits the code, and the commit ID is the primary way to do the code fallback, and fallback is to find the historical version based on the ID to do the fallback operation.

Fallback pointer:HEAD~次数

The HEAD last commit point is saved by default

There will be a head pointer on the master branch, and this pointer will always point to the last commit location by default.

HEAD Change Save submission Point after fallback once

When the fallback operation is used, the location that you will find HEAD has changed, and if you just step back, the previous action will not be deleted, and all the code will fall back to the state at the specified location.

gitreset--hardHEAD~1

If you want to get back to the latest state at this point, then you need to use the commit ID action.

--找到所有的已经删除的信息的commit IDgit reflog--恢复最后一次提交git reset --hard ff44521

Vii. Management Changes

With the concept of staging area and master Master branching, it is necessary to avoid a problem, only the content stored in staging area can be really modified, not for the file.

Viii. Revocation of changes

There will be undo changes after the modification, sometimes this situation, when you modify, it may be unreasonable to find such a modification, when you want to withdraw to the previous state, this time you need to undo the operation.

1. Situation one: In order to add (git add) and pre-commit (Git commit) users can directly revoke the changes made to the file.

Undo the modifications you have made: git checkout -- 文件名称
If the code in the workspace is not added to staging area, it is simple to revert to the original state.
For example the code is as follows (this code is obviously problematic, but as soon as the code is modified, git can monitor it):

publicclass hello{    publicstaticvoidmain(String args[]){        System.out.println("hello world");        System.out.println("today is bad day");        你好世界！！！！！    }}

At this point the code is not added to the staging area, at which point you can revert to the previous state using the following operation.

gitcheckout--hello.java

Modern code returns to normal state

publicclass hello{    publicstaticvoidmain(String args[]){        System.out.println("hello world");        System.out.println("today is bad day");    }}

2. Situation two: Before the added (git add) and uncommitted (git commit) users can directly revoke the changes made to the file.

To undo staging Area modification: git reset HEAD 文件名
Discard the contents of the file that has been modified:git checkout -- 文件名称

Now assume that the code has been submitted to staging area. Use git add . , and then query the status git status .

Exit from Staging Area

reset HEAD hello.java

has been restored from staging area to the workspace and then executed

gitcheckout--hello.java

Ix. deletion of files

Create a new Demo.java sample file in the previously created MyProject, and then delete it, but in git strictly speaking, the delete operation also belongs to the modification operation.
Use the following command

--del 要删除的文件名del demo.java--删除之后查看状态git status

After the file has been deleted, it can only be restored using version control. It is generally not recommended to use a delete operation.

Git Learning (ii) _ Using Git