Git入门

2017-12-08|Categories: Git|

英文内容(包括示例)摘自 https://www.codeschool.com/courses/try-git

Staging Area

A place where we can group files together before we "commit" them to Git.

git add <file_name>之后,该文件就被加入「Staging area」,也就是「暂存区」,也叫做「索引区 Index area」。设置暂存区的好处是,可以修改多个文件之后再统一提交。

git commit之后,文件进入Git仓库(.git目录)。

Commit

A "commit" is a snapshot of our repository. This way if we ever need to look back at the changes we've made (or if someone else does), we will see a nice timeline of all changes.

Wildcards

git add '*.txt'

We need quotes so that Git will receive the wildcard before our shell can interfere with it. Without quotes our shell will only execute the wildcard search within the current directory. Git will receive the list of files the shell found instead of the wildcard and it will not be able to add the files inside of the octofamily directory.

用单引号包围*.txt之后,git add递归添加当前目录和所有子目录下的txt文件。

When using wildcards you want to be extra careful when doing commits. Make sure to check what files and folders are staged by using git status before you do the actual commit. This way you can be sure you're committing only the things you want.

git remote

Git doesn't care what you name your remotes, but it's typical to name your main one origin.

git remote add origin https://github.com/liyang85/scripts-during-mage-linux-training.git

git push

git push -u origin master

The name of our remote is origin and the default local branch name is master. The -u tells Git to remember the parameters, so that next time we can simply run git push and Git will know what to do.

git stash

Sometimes when you go to pull you may have changes you don't want to commit just yet. One option you have, other than committing, is to stash the changes.

Use the command git stash to stash your changes, and git stash apply to re-apply your changes after your pull.

git diff

Let's take a look at what is different from our last commit by using the git diff command.

In this case we want the diff of our most recent commit, which we can refer to using the HEAD pointer.

git diff HEAD

以下内容摘自 http://www.ruanyifeng.com/blog/2012/08/how_to_read_diff.html

Git使用的是「合并格式diff」的变体。

git diff

显示结果如下:

diff --git a/f1 b/f1
index 6f8a38c..449b072 100644
--- a/f1
+++ b/f1
@@ -1,7 +1,7 @@
 a
 a
 a
-a
+b
 a
 a
 a

第一行表示结果为git格式的diff,进行比较的是a版本的f1(即变动前)和b版本的f1(即变动后)。

diff --git a/f1 b/f1

第二行表示两个版本的git哈希值(index区域的6f8a38c对象,与工作目录区域的449b072对象进行比较),最后的六位数字是对象的模式(普通文件,644权限)。

index 6f8a38c..449b072 100644

第三行表示进行比较的两个文件,"—"表示变动前的版本,"+++"表示变动后的版本。

--- a/f1
+++ b/f1

后面的行都与官方的「合并格式diff」相同。

1990年,GNU diff率先推出了「合并格式」的diff,将f1和f2的上下文合并在一起显示。它的使用方法是加入u参数(代表unified)。

diff -u f1 f2

显示结果如下:

--- f1  2012-08-29 16:45:41.000000000 +0800
+++ f2  2012-08-29 16:45:51.000000000 +0800
@@ -1,7 +1,7 @@
 a
 a
 a
-a
+b
 a
 a
 a

它的第一部分,也是文件的基本信息,"—"表示变动前的文件,"+++"表示变动后的文件。

--- f1  2012-08-29 16:45:41.000000000 +0800
+++ f2  2012-08-29 16:45:51.000000000 +0800

第二部分,变动的位置用两个@作为起首和结束。

@@ -1,7 +1,7 @@

前面的"-1,7"分成三个部分:减号表示第一个文件(即f1),"1"表示第1行,"7"表示连续7行。合在一起,就表示下面是第一个文件从第1行开始的连续7行。同样的,"+1,7"表示变动后,成为第二个文件从第1行开始的连续7行。

HEAD

The HEAD is a pointer that holds your position within all your different commits. By default HEAD points to your most recent commit, so it can be used as a quick way to reference that commit without having to look up the SHA.

git reset

You can unstage files by using the git reset command. Go ahead and remove octofamily/octodog.txt.

git reset octofamily/octodog.txt

git reset [HEAD] <file_name>可以把文件从暂存区移出,也就是撤销上一次git add <file_name>操作,前提是git add之后没有git commit

git checkout

Files can be changed back to how they were at the last commit by using the command: git checkout -- <target>. Go ahead and get rid of all the changes since the last commit for octocat.txt.

git checkout -- octocat.txt

The --

So you may be wondering, why do I have to use this -- thing? git checkout seems to work fine without it. It's simply promising the command line that there are no more options after the --. This way if you happen to have a branch named octocat.txt, it will still revert the file, instead of switching to the branch of the same name.

git branch

When developers are working on a feature or bug they'll often create a copy (aka. branch) of their code they can make separate commits to. Then when they're done they can merge this branch back into their main master branch.

We want to remove all these pesky octocats, so let's create a branch called clean_up, where we'll do all the work:

git branch clean_up

Branches are what naturally happens when you want to work on multiple features at the same time. You wouldn't want to end up with a master branch which has Feature A half done and Feature B half done.

Rather you'd separate the code base into two "snapshots" (branches) and work on and commit to them separately. As soon as one was ready, you might merge this branch back into the master branch and push it to the remote server.

Now if you type git branch you'll see two local branches: a main branch named master and your new branch named clean_up.

You can switch branches using the git checkout <branch> command. Try it now to switch to the clean_up branch:

git checkout clean_up

You can use:

git checkout -b new_branch

to checkout and create a branch at the same time. This is the same thing as doing:

git branch new_branch
git checkout new_branch

git rm

Ok, so you're in the clean_up branch. You can finally remove all those pesky octocats by using the git rm command which will not only remove the actual files from disk, but will also stage the removal of the files for us.

Removing one file is great and all, but what if you want to remove an entire folder? You can use the recursive option on git rm:

git rm -r folder_of_cats

If you happen to delete a file without using git rm you'll find that you still have to git rm the deleted files from the working tree. You can save this step by using the -a option on git commit, which auto removes deleted files with the commit.

git commit -am "Delete stuff"

Great, you're almost finished with the cat… er the bug fix, you just need to switch back to the master branch so you can copy (or merge) your changes from the clean_up branch back into the master branch.

Go ahead and checkout the master branch:

git checkout master

Pull Requests

If you're hosting your repo on GitHub, you can do something called a pull request.
A pull request allows the boss of the project to look through your changes and make comments before deciding to merge in the change. It's a really great feature that is used all the time for remote workers and open-source projects.

Check out the pull request help page for more information.

git merge

We're already on the master branch, so we just need to tell Git to merge the clean_up branch into it:

git merge clean_up

Merge Conflicts

Merge Conflicts can occur when changes are made to a file at the same time. A lot of people get really scared when a conflict happens, but fear not! They aren't that scary, you just need to decide which code to keep.

Delete branch

Congratulations! You just accomplished your first successful bugfix and merge. All that's left to do is clean up after yourself. Since you're done with the clean_up branch you don't need it anymore.

You can use git branch -d <branch name> to delete a branch. Go ahead and delete the clean_up branch now:

git branch -d clean_up

Force delete

What if you have been working on a feature branch and you decide you really don't want this feature anymore? You might decide to delete the branch since you're scrapping the idea. You'll notice that git branch -d bad_feature doesn't work. This is because -d won't let you delete something that hasn't been merged.

You can either add the --force (-f) option or use -D which combines -d -f together into one command.

Leave A Comment