Git command parameters and usage detailed

git command (GNU interactive tools)

Feature Description: File administrator in text mode.

syntax:git command

Supplemental Note:git command is used to manage files of the program, it is very similar to the DOS under the Norton Commander, with an interactive operating interface. It operates in almost the same way as Norton Commander, with a slightly sued as follows:
F1: Execute info instruction, query instruction related information, will ask you to enter the name that wants to inquire.
F2: Executes the cat directive, listing the contents of the file.
F3: Execute Gitview instructions to view the contents of the file.
F4: Execute vi instruction, edit file contents.
F5: Executing the CP Directive, copying a file or directory, will require you to enter a destination file or directory.
F6: Executing the MV command, moving a file or directory, or changing its name will require you to enter a destination file or directory.
F7: Execute mkdir instruction and create directory.
F8: Execute RM directives, delete files or directories.
F9: Executes the make instruction, and the batch process executes instructions or compiles the program, and asks you to enter the relevant command.
F10: Leave git file administrator.

-----------------git command for specific use-------------------------------

Git is a distributed version Control tool, and this article starts with the introduction of Git, focusing on the basic commands and techniques of git to try to use git while experiencing the fact that one version control tool can have so much impact on development that the article is divided into two parts:

The first part introduces some common commands for git, interspersed with the basic concepts and principles of git.

The second part focuses on Git's skills, and eventually creates an open source project on the Git hub to open your Git real-world tour

What is git?

The definition of Git on Wikipedia: It's a free, distributed version Control tool, or a fast source code management tool.

Git was originally developed by Linus Torvalds to manage the development of the Linux kernel. Each git working directory is a completely separate code base with complete history and version tracking capabilities, not dependent on the network and hub servers.

The presence of Git eases the pressure on many developers and Open-source projects to manage branch code, and encourages developers to contribute to projects of interest to them due to good control of the branch. Many open source projects, including Linux kernel, Samba, x.org Server, Ruby on Rails, have transitioned to using Git as their version control tool. For those of us who like to write code, there are two of the biggest benefits, we can submit our own code and view the code version at any location (on the subway to work), we can open many branches to practice our ideas, and the cost of merging these branches is almost negligible.

Git 1+1

Now go to the real theme of this article, and introduce Git's basic commands and operations, starting with the initialization of Git's repository, basic operations, and the unique common commands that allow you to start using Git.

Git usually has two ways to initialize:

git clone: This is a simpler way to initialize, and when you already have a remote Git version library, just clone a copy locally

For example: Git clone git://github.com/someone/some_project.git some_project

The above command is to completely clone the remote version Library of the URL address of ' git://github.com/someone/some_project.git ' to the local some_project directory

Git init and git remote: This is a little more complicated, when you create a working directory locally, you can access this directory and use ' Git Init ' command to initialize, Git will later version control of the files in the directory, this time if you need to put it on the remote server, you can create a directory on the remote server, and the access to the URL record, you can use the ' Git remote Add ' command to add a remote server side,

For example: Git remote add Origin git://github.com/someone/another_project.git

The above command will add a URL to ' git://github.com/someone/another_project.git ', a remote server named Origin, and only use Origin aliases when submitting code later

basic commands for Git

Now that we have a local and remote version library, let's try to use the basic commands for Git:

git Pull: updates code to local from other version libraries (either remotely or locally), such as: ' Git pull origin Master is to update the code for this version of origin to the local master primary, which is similar to the SVN update

git add: Adding the current change or new file to Git's index, adding it to Git's index means that it is recorded in version history, which is a step that needs to be performed before submitting, such as ' git add app/model/user.rb ' Will add app/model/user.rb files to Git's index, which is similar to SVN's add

git rm: deletes files from the current workspace and index, such as ' git rm app/model/user.rb ', which is similar to SVN rm, Del

git commit: commits changes to the current workspace, similar to SVN's commit, such as ' Git commit-m story #3, add user Model ', the submission must use-M to enter a submit information, this function is similar to SVN commit

git push: update the code for a local commit to a remote version library, such as ' Git push origin ' to update the local code to a remote version library named Orgin

git log: View history Log, this feature is similar to SVN log

git revert: restore a version of the modifications that must provide a specific git version number, such as ' git revert Bbaf6fb5060b4875b18ff9ff637ce118256d6f20 ', Git's version number is a generated hash value

Almost all of the above commands are public to every version control tool, so let's start by trying some of Git's unique commands:

git branch: Add, delete, and search operations on branches, such as ' Git branch new_branch ' will create a new branch called New_branch from the current working version, ' Git branch-d new_ Branch ' will force the deletion of the branch called New_branch, ' git branch ' will list all the local branches

git checkout: GIT's checkout has two roles, one is to switch between different branch, for example, ' Git checkout new_branch ' will switch to New_branch branch, and another function is to restore the role of the code, such as ' Git Checkout app/model/user.rb ' will update the user.rb file from the last submitted version, and the uncommitted content will be rolled back

git rebase: explained in the following two diagrams will be more clear, rebase command execution, actually is to move the branch pivot from c to G, so the branch also has the function from C to G

git reset: completely rollback the current working directory to the specified version number, assuming the following figure, we have a-g five submitted versions, where C's version number is Bbaf6fb5060b4875b18ff9ff637ce118256d6f20, We executed the ' git reset bbaf6fb5060b4875b18ff9ff637ce118256d6f20 ' So the result is only the A-C three submitted versions

git stash: put the currently uncommitted work into the GIT stack and apply it back when the time is ripe, here for a moment to mention the usage of the command, followed by a tip on the tips

git config: use this command to add and change the various settings for git, such as ' git config branch.master.remote Origin ' sets the remote version Library of Master to an alias called the Origin version library, and the following tips will use this command to personalize your git, creating a unique git for you.

git tag: You can label a specific version so that you don't need to memorize complex version number hashes, such as you can use ' git tag revert_version Bbaf6fb5060b4875b18ff9ff637ce118256d6f20 ' to mark the version you restored, you can use the revert_version tag name instead of the hash when you want to view the version later.

The fact that Git can provide convenient local branching features is related to its file storage mechanism. When Git stores version control information with its own set of file system storage mechanisms, there is a. git folder under the code root that has the following directory structure:

There are several more important files and directories to explain: The head file holds the root node information, in fact, the directory structure represents a tree structure, git use this tree structure to store version information, then head represents the root The refs directory stores the various references you have under the current version control directory (references refer to information about the branches of each tree that you use locally and remotely), it has heads, remotes, stash, tags four subdirectories, respectively, storage for different root, remote version of the library, Four references to git stacks and tags, you can view reference information more clearly by command ' git show-ref '; The logs directory stores log information according to different references. As a result, git only needs this one in the code root directory to record the full version control information, rather than having an SVN directory under the root directory and subdirectories like SVN. So let's look at the difference between git and SVN.

the difference between git and svn

SVN(Subversion) is the most currently used version control tool. In contrast,Git has the biggest advantage of two: it is easy to add branching and distributed features locally.

Here are two images that show the difference between Git and svn

------------

For easy local branching, the GIT local and server-side structure is flexible, all versions are stored in a directory, and you only need to branch out to achieve the effect of working on a branch. SVN is completely different, if you need to test some of your own code locally, you can only maintain a number of different copies, each copy corresponds to an SVN server address. As a practical example, my team used SVN as a version control tool, and when I was trying to enhance a module, half of the work was done, because the behavior of the original module resulted in the failure of many tests on the code server, no code was submitted. At this time the superiors told me that there is a very urgent bug that needs to be handled and must be completed within two hours. I had to make a diff of all the local changes and output it as a patch file, then roll back all the code on the current task, then start modifying the bug, and wait until it's modified to apply the patch back. There are a number of tedious steps to be done backwards and forwards, regardless of the amount of work that occurs when the intermediate code conflicts. However, if you use git, we just need to open a branch or go back to the main branch, you can start the Bug modified task at any time, after completion, as long as the switch to the original branch can gracefully continue the previous task. As long as you want, each new task can open a branch, complete, and then merge it into the main branch, relaxed and elegant.

Distributed for Git, you can submit your code locally, so in the diagram above, Git is good for breaking down a large task, making local multiple submissions, and SVN can only make a large number of one-time changes locally, resulting in a huge risk of merging into the backbone in the future. Git's code log is local and can be viewed at any time. SVN logs are on the server, and the logs need to be downloaded from the server each time they are viewed. I work in the team, the code server in the United States, every time we look at the work of the Group a few years ago, the log download will take 10 minutes, which can not but be said to be a pain. Then we migrated to Git, leveraging the local nature of git logs, and I wrote a rake script in Ruby that looked at all the code histories for a specific task, and it took only a few seconds to make my job much easier. Of course distributed does not mean that using git does not require a code center server, if you work in a team, or need a server to save all the code.

This article turns from: http://www.linuxso.com/command/git.html