Git Pro-(1) Basics

Nearly all operations can be performed locally

The vast majority of operations in Git require access to local files and resources without a network connection.

Three different states

There are only three states in Git for any file: committed (committed), 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.

The Git repository that gets the project is initialized from the current directory.

Git init

After initialization, a directory named. Git appears in the current directory, and all of the data and resources that git needs are stored in this directory.

Cloning from an existing warehouse

git clone git://github.com/schacon/grit.git

This creates a directory named "Grit" in the current directory, which contains a. git directory and pulls all the data out of the synchronized repository to take out the latest version of the file copy. If you want to define a new project directory name when you clone, you can specify it at the end of the command.

Log each update to the warehouse to check the current file status

git status

Track new files

git add README

Staging modified Files

git add README

This is a multi-function command, depending on the status of the target file, the effect of this command is also different: you can use it to start tracking new files, or to put the tracked files to staging area, but also can be used to merge when the conflicting files are marked as resolved state and so on.

Now the staging area is ready to be submitted. Before you do this, make sure that there are any modified or newly created files that have not been added by git, or that they will not be recorded when they are submitted. So, each time you prepare to submit, first with Git status to see, is not all have been temporarily saved up.

Submit Updates

Git commit

A snapshot that is placed on the staging area is recorded on commit, and any unsaved still remains in the modified state and can be included in version management on the next commit. Every time you run a commit, you take a snapshot of your project and you can go back to that state or compare it later.

Although the use of staging areas can be carefully prepared for the details to be submitted, it is sometimes tedious to do so. GIT provides a way to skip the use of the staging area, and as long as you commit the Git commit with the-a option, Git will automatically save all the tracked files and commit to skip the git add step.

Remove files from

git rm README

To remove a file from Git, you must remove it from the list of tracked files (to be exact, remove it from the staging area) and commit. You can do this with the git RM command and delete the specified file from the working directory, so that it doesn't appear in the list of non-tracked files.

If the deletion was previously modified and placed in the staging area, you must use the force delete option-F.

Another scenario is that we want to remove the file from the Git repository (that is, remove it from the staging area), but still want to keep it in the current working directory. In other words, just remove it from the tracking list and use the--cached option.

git rm--cached README

Moving files

git mv File_from file_to

This can be used when renaming files in Git.

In fact, running git MV is equivalent to running the following three commands:

$ mv README.txt README

$ git rm README.txt

$ git Add README

View history

git log

Undo action Modify Last Commit

git commit--amend

This command will be submitted using the current staging area snapshot. If you just run this command without making any changes to the submission, you have the opportunity to re-edit the submission description, and the file snapshot you submitted is the same as before.

If you forgot to stage some changes just now, you can fill in the staging operation before you run the--amend commit:

$ git commit-m ' initial commit '

$ git Add forgotten_file

$ git commit--amend

The above three commands end up with a commit, and the second commit command corrects the first commit.

Cancel a file that has been staged

git reset HEAD <file>

The file goes back to the previously modified state that was not staged.

To cancel the modification of a file

Git checkout--<file>

This command is a bit dangerous, all the changes to the file are gone, because we just copied the previous version of the file to rewrite the file. So before you use this command, make sure that you don't really need to keep the changes you've made.

Anything that has been committed to Git can be restored. Even commits that have been removed in a branch, or rewritten with--amend, can be restored. So, the data you might lose is limited to not being committed, and for git it's like it never existed.

Remote warehouse Usage view the current remote library

Git remote

It lists a short name for each remote library. After you have cloned a project, you can see at least one remote library named origin, and Git uses that name to identify the original repository you cloned by default. You can also add the-V option to display the corresponding clone address.

Add a remote repository

git remote add [shortname] [url]

For example:

$ git remote
Origin
$ git remote add PB git://github.com/paulboone/ticgit.git $ git remote-v

Origin Git://github.com/schacon/ticgit.git

PB Git://github.com/paulboone/ticgit.git

Fetching data from a remote repository

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.

If a branch is set up to track a branch of a remote repository, you can use the git pull command to automatically crawl the data and then automatically merge 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.

Push data to a remote repository

git push [remote-name] [Branch-name]

This command completes the task as expected only if there are write permissions on the cloned server, or if no one else 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 into your project before you can push them again.

View Remote Warehouse Information

git remote show [remote-name]

In addition to the corresponding clone address, it also gives a lot of additional information. It's a friendly way to tell you that if you're in the Master branch, you can use git pull commands to merge the data locally. It also lists all the remote branches that are in the tracking state. It also tells us what branches are pushed by default when running Git push.

Deletion and renaming of remote warehouses

git remote rename

Git remote RM

Git Pro-(1) Basics