Version Control Git learning notes (i)

1. Centralized vs Distributed

--linus has always hated the CVS and SVN are centralized version control system, and Git is a distributed version control system, centralized and distributed version control system What is the difference?
First of all, the centralized version control system, the repository is centrally stored in the central server, and work, the use of their own computers, so the first from the central server to obtain the latest version, and then began to work, finished living, and then put their own live push to the central server. Central server is like a library, you have to change a book, you must first borrow from the library, and then back home to change, and then put back to the library.

Centralized version control system The biggest problem is the need to network to work, if it is OK in the LAN, the bandwidth is big enough, fast enough, but if on the Internet, if you encounter a slow speed, you may submit a 10M file will take 5 minutes, it is not to suppress the death of people.

--distributed version control system does not have a "central server", everyone's computer is a full version of the library, so that when you work, you do not need to network, because the repository is on your own computer. Since everyone has a full repository on their computers, how can multiple people collaborate? For example, you change the file a on your computer, your colleague also changed the file a on his computer, when you two just push their changes to each other, you can see each other's changes.

Compared with centralized version control system, the security of Distributed version control system is much higher, because everyone's computer has a complete version of the library, a person's computer is broken do not matter, casually from other people to copy one. Centralized version control system central server if there is a problem, everyone can not work.

In the actual use of Distributed version control system, in fact, rarely in the two people on the computer to push the revision of the Repository, because maybe you two are not in a local area network, both computers can not access each other, or your colleague is sick today, his computer did not boot. Therefore, the distributed version control system usually also has a "central server" computer, but the role of this server is only to facilitate "exchange" everyone's changes, without it everyone also work, just exchange changes inconvenient.

2. Install Git on Windows

When you want to use a lot of Linux/unix tools under Windows, you need to cygwin such a simulation environment, GIT is the same. Cygwin installation and configuration are more complex, it is not recommended that you toss. However, a man has already put the simulation environment and git are packaged, called Msysgit, only need to download a separate EXE installation program, and nothing else to install, absolutely good.

Msysgit is a Windows version of Git, downloaded from http://msysgit.github.io/, and then installed by default.

After the installation is complete, find Git Bash in the Start menu and pop out a command-line window that shows that the GIT installation was successful!

After the installation is complete, you will need the final step, and at the command line, enter:

$ git config–global user.name "Your name"

$ git config–global user.email "[Email protected]"

Because Git is a distributed version control system, every machine must be tell: your name and email address. You may be worried, what if someone pretends to be someone else? This does not have to worry, first of all we believe that we are good and ignorant of the masses, and secondly, there is a fake there are ways to check.

注意git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。

3. Create a version library

What is a repository? Repository also known as the Warehouse, English name repository, you can easily understand a directory, all the files in this directory can be managed by git, each file modification, deletion, git can track, so that any moment can be traced to the history, or at some point in the future can be "restored."

Therefore, it is very simple to create a repository, first of all, select a suitable place to create an empty directory:

$ mkdir Learngit

$ CD Learngit

$ pwd

/users/michael/learngit

The PWD command is used to display the current directory. On my Mac, this warehouse is located in/users/michael/learngit.

If you are using a Windows system, in order to avoid any puzzling problems, make sure that the directory name (including the parent directory) does not contain Chinese.

The second step is to turn this directory into a repository that git can manage by using the GIT init command:

$ git init

Initialized Empty Git repository in/users/michael/learngit/.git/

Instantly git has built the warehouse and tells you it's an empty repository (empty git repository), Careful readers can find that the current directory is more than a. Git directory, this directory is git to track the management of the repository, do not manually modify the files in this directory, or change the mess, the Git repository to destroy.

If you don't see the. git directory, that's because the directory is hidden by default and can be seen with the Ls-ah command.

You don't have to create a git repository in an empty directory, and it's also possible to choose a directory that already has something. However, it is not recommended that you use the company project you are developing to learn git, otherwise you will not be responsible for any consequences.

4. Add files to Repository

First of all, it is clear that all version control systems, in fact, can only track changes in text files, such as txt files, Web pages, all the program code and so on, Git is no exception. The version control system can tell you every change, such as adding a word "Linux" to line 5th, and deleting a word "Windows" on line 8th. and picture, video these binary files, although can also be managed by version control system, but can't track file changes, only the binary files each change string up, that is, only know the picture changed from 100KB to 120KB, but what changed, version control system do not know, also can not know.

Unfortunately, Microsoft Word format is binary format, so the version control system is not able to track changes in Word files, the previous example is just to demonstrate that if you want to really use version control system, it is necessary to write the file in plain text.

Because the text is encoded, such as Chinese has a common GBK encoding, Japanese has SHIFT_JIS encoding, if there is no historical legacy issues, it is strongly recommended to use the standard UTF-8 encoding, all languages use the same encoding, no conflict, and supported by all platforms.

Children's shoes using Windows should pay special attention to:

Never edit any text file with a notepad that comes with Windows. The reason is that Microsoft Development Notepad team used a very mentally retarded behavior to save UTF-8 encoded files, they are smart to add 0XEFBBBF (hex) characters at the beginning of each file, you will encounter a lot of incredible problems, for example, the first line of the page may show a "?", obviously the correct procedure to compile a report on grammatical errors, and so on, are caused by the mentally retarded behavior of Notepad. Suggest you download notepad++ instead of Notepad, not only powerful, but also free! Remember to set the default encoding for notepad++ to UTF-8 without BOM:

Now, let's write a Readme.txt file that reads as follows:

Git is a version control system.
Git is free software.

Be sure to put it in the Learngit directory (subdirectory is also OK), because this is a git repository, put it elsewhere git can not find this file.

It takes 3 steps to put an elephant in the freezer, and it takes only two steps to put a file into a git repository.

The first step is to use the command git add to tell git to add the file to the repository:

$ git Add readme.txt

Execute the above command without any display, that's right, the Unix philosophy is "No news is good news", stating add success.

In the second step, use the command git commit to tell git to commit the file to the repository:

$ git commit-m "wrote a Readme file"

[Master (Root-commit) Cb926e7] wrote a readme file

1 file changed, 2 insertions (+)

Create mode 100644 readme.txt

Simply explain the git commit command, which is followed by the instructions in this submission, you can enter any content, of course, it is very meaningful, so you can easily find changes in the history record.

Bother not to input-M "xxx" line? There are ways to do this, but it's strongly not recommended, because it's important for you to read to others. I do not want to enter the description of children's shoes please google, I do not tell you this parameter.

When the git commit command succeeds, it tells you that 1 files have been changed (our newly added Readme.txt file), inserting two lines of content (Readme.txt has two lines of content).

Why does git add a file that requires add,commit two steps? Because commit can commit many files at once, you can add different files multiple times, such as:

$ git Add file1.txt

$ git add file2.txt file3.txt

$ git commit-m "Add 3 files."

5. Time Machine Shuttle

We have successfully added and submitted a Readme.txt file, and now it is time to continue working, so we continue to modify the Readme.txt file and change it to the following:

Git is a distributed version control system.
Git is free software.

Now run the git status command to see the results:

The git status command allows us to keep abreast of the current state of the repository, which tells us that Readme.txt has been modified, but not yet ready to commit the changes.

Although Git tells us that Readme.txt has been modified, it's good to see what's changed. For example, you take a vacation two weeks from abroad, the first day of work, you can not remember how the last change Readme.txt, so you need to use Git diff this command to see:

Git diff, as its name implies, is looking at difference, which is the UNIX generic diff format, and can be seen from the command output above, and we've added a "distributed" word to the first line.

Once you know what changes have been made to Readme.txt, it is much more reassuring to submit it to the warehouse, and the first step is to commit the new file with the same two steps as git add:

$ git Add readme.txt

There is also no output. Before we perform the second step of git commit, we run GIT status to see the status of the current repository:

Git status tells us that the changes that will be committed include Readme.txt, and the next step, you can safely submit:

$ git commit-m "Add distributed"

Once submitted, we then use the git status command to see the current state of the repository:

Git tells us that there are no changes that need to be committed at this moment, and that the working directory is clean (working directory cleanly).

Summary: To keep abreast of the state of the workspace, use the git status command. If Git status tells you that a file has been modified, use Git diff to see what's changed.

6. Version fallback

Now that you've learned to modify the file and commit the changes to the Git repository, now, practice again and modify the Readme.txt file as follows:

Git is a distributed version control system.
Git is free software distributed under the GPL.

Then try to commit:

g ITad d Read me.TxT Git commit-m "Append GPL"

Like this, you continue to modify the file, and then constantly submit changes to the repository, like playing RPG, every pass through the game will automatically save the state, if there is no past, you can also choose to read the status of the previous level. In some cases, you can manually save the boss before hitting it, so that if the boss fails, you may start again from the nearest place. Git, too, can "save a snapshot" whenever you think a file has been modified to a certain level, a snapshot that is called a commit in Git. Once you've changed the file, or deleted it by mistake, you can recover from a recent commit and continue working instead of losing all of your work for a few months.

Now, let's review how several versions of the Readme.txt file have been submitted to the GIT repository:

Version 1:wrote a Readme file

**git is a version control system.
Git is free software.**

Version 2:add distributed

**git is a distributed version control system.
Git is free software.**

Version 3:append GPL

**git is a distributed version control system.
Git is free software distributed under the gpl.**

Of course, in the actual work, how can we mind remember a thousands of-line file each time the change of what content, or version control system what to do. The version control system must have a command that tells us the history, and in Git we use the git log command to see:

$ git log

The git log command shows the commit log from the most recent to the farthest, and we can see 3 commits, the most recent being the Append GPL, the last time the add distributed, and the oldest was wrote a Readme file.
If too many output information, see dazzling, you can try to add –pretty=oneline parameters:

$ git log–pretty=oneline

The need for a friendly tip is that you see a bunch of similar 3628164 ... 882E1E0 is the commit ID (version number), unlike SVN, GIT's commit ID is not a ... Incrementing the number, but a SHA1 calculated by a very large number, in hexadecimal notation, and you see the commit ID and my affirmation is not the same, whichever is your own. Why does the commit ID need to be represented by such a large number of numbers? Because Git is a distributed version control system, we also want to study how many people work in the same repository, if we all use a three-to-one version ... As a version number, it must have been a conflict.

OK, now we start the time shuttle, ready to Readme.txt back to the previous version, that is, "add distributed" that version, how to do it?

First, git must know which version of the current version, in Git, the current version with Head, that is, the latest commit 3628164 ... 882E1E0 (Note that my submission ID and your affirmation is not the same), the previous version is head^, the last version is head^^, of course, to 100 versions write 100 ^ more easy to count, so written head~100.

Now, we're going to roll back the current version of "Append GPL" to the previous version of "Add distributed", and you can use the git reset command:

$ git reset–hard head^

What does the –hard parameter mean? I'll talk about this later, and now you can use it with ease.

See if the content of Readme.txt is not version add distributed:

$ cat Readme.txt

Sure enough

You can also continue to fallback to the previous version of wrote a Readme file, but wait a moment, and then we'll look at the status of the repository with git log:

$ git log

The latest version of the Append GPL is out of sight! Like you from 21st century to sit time shuttle machine came to 19th century, want to go back already can't go back, swollen?

There is still some way, as long as the above command Line window has not been turned off, you can go up and look for Ah, find the Append GPL's commit ID is 3628164 ..., so you can specify back to a future version:

$ git reset–hard 3628164

The version number is not necessary to write the whole, the first few can be, git will automatically go to find. Of course, you can't just write the top one or two bits, because git might find multiple version numbers, and there's no way to determine which one.

Look carefully at the contents of Readme.txt:

$ cat Readme.txt

Sure enough, I am back again.

Git's version fallback is very fast because git has a head pointer to the current version inside, and when you roll back the version, git just points the head from the Append GPL:

If we turn off the command line after a certain submission, now you fall back to a version, turn off the computer, regret the next morning, and want to revert to the new version? What if I can't find a new version of the commit ID?

In Git, there's always a regret pill to eat. When you head^ back to the Add distributed version with $ git reset–hard, you'll have to find the append GPL's commit ID if you want to revert to the append GPL. git provides a command git reflog used to record every command you make:

$ git Reflog

Finally relieved, the second line shows that the append GPL's commit ID is 3628164, and now you can take the time machine back to the future.

Summary The version that the head points to is the current version, so git allows us to travel between versions of history, using the command git reset–hard commit_id. Before the shuttle, use git log to view the commit history to determine which version to fallback to. To return to the future, use Git reflog to view the command history to determine which version to go back to in the future.

7. Workspaces and Staging Area

One of the differences between Git and other version control systems like SVN is the concept of staging area.

First look at the noun explanation.

Workspaces (Working Directory)

Is the directory you can see on your computer, like my Learngit folder is a workspace:

Version Library (Repository)

The workspace has a hidden directory. Git, this isn't a workspace, it's a git repository.

Git has a lot of stuff in its repository, the most important of which is the staging area called stage (or index), and the first branch master that git automatically creates for us, and a pointer to master called head.

The concept of branching and head we'll talk about later.

When we added the file to the Git repository, it was done in two steps:

The first step is to use git add to add the file, in fact, the file is modified to add to the staging area;

The second step is to commit the change with git commit, which in effect commits all of the staging area content to the current branch.

Because git automatically created the only master branch for us when we created the Git repository, now git commit is committing the changes to the Master branch.

You can simply understand that the file changes that need to be submitted are all put to staging area, and then all changes to staging area are submitted at once.

As the saying goes, practice is the truth. Now, let's practice again and make a change to Readme.txt, such as adding a line of content:

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.

Then, add a license text file in the workspace (the content is written casually).

First look at the status with git status:

Git tells us very clearly that Readme.txt has been modified, and LICENSE.txt has never been added, so its state is untracked.

Now, using the two command git add,git comit Add and submit both Readme.txt and license, and look at git status again:

The git add command actually puts all the changes you want to commit to staging area (Stage), and then executes git commit to commit all the staging area changes to the branch at once.

After git add, the workspace status is as follows:

After Git commits, the status is as follows:

Summary

Staging area is a very important concept of git, figuring out staging area, figuring out what a lot of git's operations are doing.

I don't know what's going on staging area. Children's shoes, please scroll up the page and look again.

8. Management changes

Now, suppose you have mastered the concept of staging area completely. What we're going to talk about here is why Git is better designed than other version control systems because git tracks and manages changes, not files.

You will ask, what is the modification? For example, you add a row, this is a change, delete a row, is also a modification, change some characters, is also a modification, delete some and add some, is also a modification, even create a new file, also counted as a modification.

Why is git managing changes, not files? We still do the experiment. The first step is to make a change to Readme.txt, such as adding a line of content:

Cat Readme.txt

Then, add:

git add readme.txt
$ git status

Then, modify the Readme.txt:

Submit:

$ git commit-m "git tracks changes"

After submitting, look at the status:

Gee, how did the second Amendment not be submitted?

Don't get excited, let's review the operation process:

Git commit, the second modification, git add, first modified

You see, as we said earlier, Git manages the modifications, and when you use the git add command, the first modification in the workspace is put into staging area, ready to commit, but the second modification in the workspace is not put into staging area, so git commit is only responsible for staging area's modifications. That is, the first modification is submitted, and the second change is not committed.

After committing, use the git diff head–readme.txt command to see the difference between the latest version of the workspace and the repository:

As can be seen, the second modification is indeed not committed.

Then how to submit a second Amendment? You can continue git add git commit, or do not worry about submitting the first modification, git add the second modification, and then git commit, it is equivalent to the two changes after merging a piece submitted:

Git add-a git commit for the first time, git add, and the second modification,

OK, now, submit the second change and start the summary.

Summary: Now that you understand how Git keeps track of changes, each time you change it, if you don't add to staging area, you won't be added to the commit.

9. Undo Changes

Naturally, you are not going to make a mistake. But it's two o'clock in the morning, and you're working on a job report, and you've added a line to Readme.txt:

Before you prepare to submit, a cup of coffee has played a role, you suddenly found that "stupid boss" may let you lose this month's bonus!

Now that the error has been found in time, it can be easily corrected. You can delete the last line, manually restore the file to the previous version of the state. If you look at git status:

You can see that git will tell you that git checkout–file can discard changes to the workspace:

$ git checkout–readme.txt

The command git checkout–readme.txt means to undo all changes to the Readme.txt file in the workspace, here are two things:

One is that Readme.txt has not been put into the staging area since the modification, and now, the undo changes back to the same state as the repository;

One is that the Readme.txt has been added to the staging area and modified, and now the undo changes go back to the state that was added to the staging area.

All in all, let this file go back to the state of the last git commit or git Add.

Now, look at the contents of the Readme.txt file:

The contents of the document were restored.

The git checkout–file command – very important, no – becomes the "switch to another branch" command, and we will encounter the git checkout command again in later branch management.

Now, assuming it's 3 o'clock in the morning, you're not only writing nonsense, but git add to staging area:

Fortunately, you found this problem before commit. With Git status, the changes are just added to the staging area, not yet committed:

Git also tells us that with the command git reset HEAD file can undo staging area's changes (unstage) and back into the workspace:

$ git reset HEAD readme.txt

The git reset command either rolls back the version or rolls back the staging area changes to the workspace. When we use head, we represent the latest version.

Then use git status to view, now staging area is clean, the workspace has been modified:

Remember how to discard changes to the workspace?

$ git checkout–readme.txt

The whole world is finally quiet!

Now, suppose you have not only changed the wrong thing, but also submitted it from staging area to the repository, what should I do? Do you remember the version fallback section? Can be rolled back to the previous version. However, this is conditional, that you have not yet pushed your local repository to remote. Remember Git is a distributed version control system? We'll talk about the remote repository later, and once you push the "stupid boss" commit to the remote repository, you're really miserable ...

Summary

Scenario 1: When you mess up the contents of a file in your workspace and want to discard changes to the workspace directly, use the command git checkout–file.

Scenario 2: When you not only changed the contents of a file in the workspace, but also added to the staging area, want to discard the changes, two steps, the first step with the command git reset HEAD file, back to scene 1, the second step by scene 1 operation.

Scenario 3: When an inappropriate modification to the repository has been submitted, you want to revoke this commit, refer to the version fallback section, but only if it is not pushed to the remote library.

10. deleting files

In Git, the deletion is also a modification operation, we do the actual combat, first add a new file Test.txt to Git and commit:

In general, you usually delete the unused files directly in the File Manager, or delete them with the RM command:

$ RM test.txt

At this point, git knows that you deleted the file, so the workspace and repository are inconsistent, and the git status command immediately tells you which files were deleted:

Now that you have two options, one is to remove the file from the repository, delete it with the command git rm and git commit:

$ git rm test.txt

Git commit-m "Remove test.txt"

The file is now deleted from the repository.

The other is wrong, because the repository is still there, so it is easy to restore the deleted files to the latest version:

$ git checkout–test.txt

Git checkout is actually replacing the workspace version with the version in the repository, which can be "one-click Restore", regardless of whether the workspace is modified or deleted.

Summary: Command git rm to delete a file. If a file has been submitted to the repository, then you never have to worry about accidentally deleting it, but be careful that you can only recover files to the latest version and you will lose what you modified after the last commit.

Original link: The most understandable git tutorial ever!

Version Control Git learning notes (i)