Git Adventures (i)

"Editor's note" as an important representative of Distributed version control system--git has been recognized by more and more people, it is relative to our familiar CVS, SVN and even distributed control system Mercurial, what are the advantages and disadvantages. The Infoq Chinese station was fortunate enough to invite Liu Hui, a translator for Git Community book, to open the "Git Adventures" column in Infoq, sharing his experience with git and his view of Git.

Git is an open source Distributed version control system (DVCS) that Linus.torvald has initiated and developed to manage the Linux kernel. Since 2002, the Linux kernel has been using BitKeeper for version management, but in 2005 BitKeeper and the Linux kernel Open source Community partnership ended, BitKeeper could no longer be used for free, This forced Linus to decide to develop a self-contained version control system for the open source world.

Traditional SVN, CVS and other version control systems, only one warehouse (repository), the user must connect to the warehouse to start submitting, and Git and other distributed version control system (also including BitKeeper, mercurial, etc.), Each of its working directories contains a full repository that supports offline work, commits the work to the local repository, and then submits it to the repository on the remote server. Distributed processing also makes development more convenient, developers can easily create branches locally for daily development, everyone's local warehouse is equal and independent, not because your local submissions directly affect others.

To be honest, Git's speed is the fastest in my version control system (SVN Mercurial Git). I'm talking about speed, including local commit (commit), Local checkout (checkout), Commit to remote repository (git push) and get from remote repository (git fetch, git pull), its local operation speed and local filesystem at one level, Remote warehouse operation speed and SFTP file transfer at one level. This is certainly related to the internal implementation mechanism of GIT, there is not much to expand, interested friends can look here: Git is the next Unix.

When we are learning a new language, often starting with a "Hello World" program, the Git journey begins with a "Hello git".

Here is the assumption that everyone's computer is loaded git, if not installed, you can first look here (install git). Of course, the later chapters will focus on the problems that may come up with the installation.

We first open the git command line: Under Windows is click "git Bash Shortcut", Linux or Unix like platform, you can open the command line interface directly.

Note:the string following the $ symbol represents the command line input, and the bold string that starts with # in the command line represents the comment, and the other part is the command line output.

Let's start by building a warehouse:

#建立仓库目录 #进入仓库目录$git init #这会在当前的目录下建一个仓库

OK, the previous three-line command builds a local git repository. This warehouse is now an empty warehouse.

We execute under the command line:

#查看当前仓库的状态 #查看当前仓库的历史日志

Now let's add some content to this warehouse.

#建立一个含有 A text file for Hello Git #将readme. txt added to staging area

Well, the file is then staged into the staging area, and we can now submit it to the repository:)

#将刚才的修改提交到本地仓库中

Now you execute the git log command and you see the commit record.

The string "8223db3b064a9826375041c8fea020cb2e3b17d1" is the name of the submission we created this time. It seems to be not very familiar, if you often use the donkey's friends will find that it is the same as the electric donkey content identifier, are SHA1 string. Git obtains their SHA1 string values as a unique identifier for each commit by SHA1 hash operations on the commits. According to the general cryptography principle, if the content of two commits is not the same, then their names will not be the same, and conversely, if their names are the same, it means that their contents are the same.

Now I want to change the contents of the file in the warehouse, and now submit it to the warehouse.

#在文件的最后添加一行 #查看当前仓库的状态# on Branch Master # Changed Yet not updated: (modified, but no staged content) # (use "git add <file> ..." to upd Ate what would be committed) # (use "Git checkout--<file> ..." to discard changes in working directory) # # Modified : Readme.txt # No changes added to commit (use "git add" and/or "Git Commit-a")

(no changes can be committed, use "git add" command to add files to staging area, or use "git commit-a" command to force the submission of all files in the current directory)

OK, now that we have modified the files that are submitted in the repository, I would like to have a look at our

Change the place, and then decide whether to submit.

#查看仓库里未暂存内容和仓库已提交内容的差异

Well, as we wish, we just added a line of "Git is Cool" on the last line of Readme.txt.

OK, let's put Readme.txt in the staging area now:

Let's look at the state of the warehouse now:

Can submit:

Look at the new log again:

"45ff89198f08365bff32364034aed98126009e44" This is the commit we created when we just submitted the changes.

It's a bit confusing for everyone to look at it all the way. But it doesn't matter if your computer has git, then you will have a perceptual understanding of all of the commands above.

In the following chapters, I'll talk about how to configure Git in Windows and Linux installation, as well as the issues needing attention:)

Git Adventures (i)