Source Control System (SCM) and VersioningVersioning is a system that records changes in the content of several files to enable future review of specific revisions.
local version control systemMany people are accustomed to copy the entire project directory in a way to save different versions, and perhaps also change the name plus backup time to distinguish. The only good thing to do is to be simple and bad: Sometimes it confuses the working directory, and once the file data is mistaken, there is no way to undo the recovery. To solve this problem, many local version control systems have been developed long ago, mostly using some simple database to record the changes in the file.
Centralized version control systemThen there is the question of how to get developers working together on different systems. As a result, the centralized version control system (centralized) was born. Such systems, such as CVS, Subversion, and so on, all have a single centralized management server that keeps revisions of all files, and the people who work together connect to the server through the client, take out the latest files, or submit updates. Over the years, this has become a standard practice for version control systems.
This brings a lot of benefits, especially relative to the local version control system. Now, to some extent, everyone can see what other people in the project are doing, and administrators can easily master each developer's permissions and see each person's commit record every day. The biggest drawback to this is the single point of failure of the central server. If you're down for an hour, you won't be able to submit updates in an hour, and you won't be able to work together. If a central server's disk fails, it happens that there is no backup or backup, and there is a risk of data loss. The worst-case scenario is the total loss of all historical change records for the entire project, with the exception of some snapshot data extracted by the client, but it is not guaranteed that all data has been fully extracted beforehand. The local version control system also has a similar problem, as long as the entire project history is saved in a single location, there is a risk of losing all historical update records.
distributed version control systemDistributed version management system is to solve this single point, in such systems, such as Git, Mercurial, Bazaar and Darcs, and so on, the client does not just extract the latest file snapshot, but the original code warehouse completely mirrored down. As a result, any server that works together fails and can be recovered using any of the mirrored local repositories afterwards. Because each fetch operation is actually a full backup of the code warehouse at one time. Further, this type of system can be specified to interact with several different remote code warehouses. As a result, you can collaborate with people from different working groups on the same project. You can set up different collaboration processes as needed.
the difference between git and SVN's regular version control softwareGit is a fast, extensible, distributed version control system with an extremely rich set of commands that provides advanced operations and full access to internal systems. Git was born in 2005 because the version control system BitKeeper used by the Linux kernel Open source project was retracted, forcing the Linux open source community (especially the creator of Linux Linus Torvalds) to learn lessons, Only by developing a set of own version control system will not repeat the same. Their goals for the new system are as follows: fast, simple design, strong support for non-linear development patterns (allowing thousands of parallel development branches), fully distributed, and the ability to efficiently manage ultra-large projects like the Linux kernel (speed and quantity). After continuous improvement, GIT has always maintained the following features: 1, direct recording of snapshots, rather than differential comparison. The main difference between Git and other version control systems is that git only cares about whether the overall file data is changing, while most other systems only care about the specific differences in file content. This type of system (CVS, subversion, and so on) records what files are updated each time, and what rows are updated, such as:
Git does not store the variance data that changes before and after. In fact, Git is more like taking a snapshot of a changed file and recording it in a tiny file system. Each time you submit an update, it will take a snapshot of all of the file's fingerprint information, and then save an index that points to the snapshot. To improve performance, if the file does not change, Git does not save it again, but only a link to the last saved snapshot. Git works the way it looks like:
This is an important difference between Git and other systems. It completely overturned the traditional version control of the routine, and the implementation of the various aspects of the way to make a new design. Git is more of a small file system, but it also provides a number of powerful tools based on this, not just a simple VCS. 2, support offline work (almost all operations are local execution), local submission can be submitted to the server later, 3, the time to maintain data integrity; 4, most operations only add data; three states of a file there are only three states in Git for any file: committed (Commi tted), modified (modified) and staged (staged). Submitted indicates that the file has been safely stored in the local database, modified to indicate that a file has been modified, but has not yet been committed, and that a staged representation puts the modified file on the list to be saved on the next commit. This is where we see the three working areas of the file flow when Git manages the project: the working directory of Git, the staging area, and the local repository.
Each project has a git directory: If git clone comes out, it's the. git directory, and if Git clone--bare, the new directory itself is the GIT directory. ), which is where Git stores metadata and object databases. This directory is very important, each time you clone a mirrored warehouse, the actual copy is the data in this directory. Remove all files and directories of a version from the project, which is called the working directory to begin the follow-up work. These files are actually extracted from the compacted object database in the Git directory and can then be edited in the working directory. The so-called staging area is just a simple file that is typically placed in a Git directory. Sometimes people call this file an index file, but the standard term is called a staging area. The basic Git workflow is as follows: 1. Modify some files in the working directory. 2. Take a snapshot of the modified file and save it to the staging area. 3. Commit the update to permanently dump the file snapshot saved in the staging area to the Git directory. Therefore, we can judge the status from the location of the file: if it is a specific version of the file saved in the Git directory, it is a committed state, if modified and placed in the staging area, it is a staged state, if it has been modified since the last time, but has not been placed in the staging area, is the modified state.
the use of Git git supports many data transfer protocols, including local transport, git://protocol, HTTP (s)://or SSH Transfer Protocol [email protected]:/ Path.git, except for the HTTP protocol, all other protocols require that GIT be installed and running on the server side. , using local warehouse for local project management, some specific ways of doing this can be consulted in this article: Git basics explains in detail how git works with each operation. Because the main purpose of this article is to demonstrate how to use GitHub to participate in open source projects, it is no longer time to describe the use of details, but I think it is helpful to take a closer look at these usage methods to improve productivity. Using a local warehouse, the user is just a person, so there is no problem of co-operation, no matter how to play, generally do not have problems. With remote repositories, it can be a lot more complicated and interesting. Using remote warehouses to participate in the collaboration of any Git project, you must know how to manage the remote repository. A remote repository is a project repository that is hosted on a network, and there may be several, some of which you can only read, and others that you write. When you collaborate with others to develop a project, you need to manage these remote warehouses to push or pull data and share the progress of your work. Manage remote repositories, including adding remote libraries, removing obsolete remote libraries, managing various remote library branches, defining whether to track these branches, and so on. Take the now-popular GitHub example, if I create a project above, it's actually the equivalent of creating a new server-side repository using GIT init. If I want to develop locally, then I need git clone to my local. After doing some development, I can push the local changes to the server repository with Git push. As the project evolved, someone else wanted to get involved in the project, and he could fork me on GitHub so he could write permissions on the project and save his work on GitHub's servers. If he wants to submit his work to me, first he needs to add my remote repository git remotes in the local development environment. Then git push remotename master initiates the push request, and if I accept it, his work can be merged into the trunk. Because we are parallel development at this time, if he wants to see my work, I can use git pull RemoteName's Way of drawing my changes to the local, very convenient. The above paragraphs describe some of the remote warehouses that we use to work with the remote repository and the process of collaborating with others as follows:  1, View currently configured remote warehouses You can use Git remote-v to see which remote warehouses are added in the current project Where origin is generally its own remote repository on the server, other remote repositories for others.  2, add a new remote repository To add a new remote repository, you can specify a simple name for future reference, run git remote add [ ShortName] [url] git remote add PB git://github.com/paulboone/ticgit.git & NBSP;3, crawling remote Repository information git fetch [remote-name] This command pulls all data that is not in your local repository to the remote repository. Once the operation is complete, you can access all the branches in the remote repository locally, merge one of the branches locally, or simply take out a branch to explore. If a repository is cloned, this command automatically attributes the remote repository to Origin. So, GIT fetch origin crawls all the updates that someone else uploaded to the remote repository since you last cloned (or someone else has submitted an update since the last fetch). It is important to remember that the fetch command simply pulls the remote data to the local repository and does not automatically merge into the current branch of work, but only when you are ready to do so manually. 4, crawling information from remote warehouses and merging git pull [remote-name] can be used Git pulThe l command automatically fetches the data and then automatically merges the remote branch into the current branch in the local repository. We often use this in our daily work, both fast and well. In fact, by default, the git clone command essentially automatically creates a local master branch to track the master branch in the remote repository (assuming the remote repository does have a master branch). So we typically run git pull to merge the data from the remote repository of the original clone into the current branch in the working directory.  5, push data to remote warehouse  GIT push [remote-name] [branch-name] Project to a stage, to share the current results with others, you can push data from the local repository to the remote repository. The command to implement this task is simple: git push [remote-name] [branch-name]. If you want to push the local master branch to the origin server (again, the clone operation will automatically use the default Master and Origin names), you can run the following command: git Push Origi N master This command completes the task as expected only if there is write permission on the cloned server, or no other person is pushing the data at the same time. If someone else has pushed a few updates before you push the data, your push will be dismissed. You have to crawl their updates locally and merge them into your project before you can push them again. 6, view remote Warehouse information  GIT remote show [remote-name] 7, Delete and rename remote warehouses git remote rename [old name] [new name] git remote RM [Remot e-name]
git and GitHub github is a Web site that uses git to provide free code hosting services (similar sites and veteran SourceForge), and many well-known projects are hosted on it. to participate in open source projects on GitHub, there are two ways to do this, depending on how you use Git. The first is that the creator of the project adds you to the project's partner contributors list so you can push the code directly to the project. The second is to fork a piece of code into their own space, such a copy of the code itself has the permission to push. If development is progressing well, the creator of the project can add the fork to the remote repository, fetch the code to his or her warehouse when he thinks it is appropriate, or we can initiate the request and ask the founders to merge the code. What is advocated on GitHub is the use of this approach for development cooperation. below take Php-daemon as an example of how to participate in open source projects hosted in GitHub. 0, install the configuration git 1, first sign up for a GitHub account.  2, choose a project you like and fork. 3, establish a local resource pool (locally Repo). You can use the following command to copy the project locally, the address can be either SSH or HTTP, and the specific address can be seen in the project page. git Clone [email protected]:cocowool/php-daemon.git 4, configuring the source project address. When the project cloning is complete, the default has a remote named "origin" pointing to my project on GitHub, not the original project. To be able to get updates on the original project in a timely manner, we need to add another remote, named "Upstream". git remote add upstream https://github.com/shaneharter/php-daemon.git git fetch upstream 5, the next thing you can do. Push submission push commits
some small tipsMac OS X Lion comes with Git's command line and graphical interface, although his graphical interface is crude to vomit. There is also a gitk under the Mac that provides a graphical tool for historical review. It's written in TCL/TK, basically the visual version of the git log command, and the options that git log can use are also available on GITK. You can see it by entering/DEVELOPER/USR/BIN/GITK in the project directory.
Git's in-depth understanding and the use of GitHub managed services
