Git learning portal notes

1. Centralized distributed VS

• Centralized: CVS, SVN
  slow, must be networked, in a central repository server, simple to use
• Distributed: Git
  fast, without networking, safe, everyone's computer has a complete repository, a central server for the exchange of all of the changes, a strong branch management, use more complex

Note: GitHub: Git provides storage for free. Provided Git repository hosting services, acting as a central server for free exchange.
Local and remote warehouse warehouse actually nothing different, purely for 7x24 hours a day and exchange changes

2. version rollback and forward

• Version rollback / forward (reset HEAD pointer)
  git reset --hard HEAD~to fall back to the previous version
  git reset --hard 91588fbto fall back to the specified version
  version of Git rollback very fast, because Git inside there is a point to the current version of the HEAD pointer when you roll back versions time, Git is just one point from the HEAD version.
  git resetCommand can either rollback version, can also modify the temporary area to fall back to the work area. When we use HEAD, represent the latest version.
• View historical operating record
  git reflogwith git reflog view the command history in order to determine what you want to return to a future version
• git log -n 3View the latest three commit log
  

3. The work area and staging area

Workspace has a hidden directory .git, this is not the work area, but Git repository.
Git version Curry save a lot of things, most important of which is called stage(or called index) staging area, as well as the first branch of our Git automatically created mastercalled, and a pointer to the master of HEAD

speaking in front of when we add files to the Git repository, and is performed in two steps:

• The first step is git addto add into the file, the file is actually added to modify the staging area;

• The second step is git committo commit the changes, in fact, is to submit all the contents of the staging area to the current branch.

Because when we created the Git repository, Git automatically creates a unique for our masterbranch, so, now, git commitit is to commit the changes to the master branch.

You can simply understood as the documents required to submit all changes into the staging area, and then, a one-time submission of all the changes in the temporary area.

4. Modify Management

Git跟踪并管理的是修改，而非文件。

You may ask, what is a modification? For example, you add a line, which is a modified, deleted a row, is a modified, changed some characters, is a modified, deleted some and added some, is a modified, or even create a new file, are also considered a modification.
Git management is modified when you use git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。
git diff HEAD -- xx.txtthe comparison of the difference between the latest local xx.txt file and warehouses.
Git is tracking changes, each modified, if not git add to the staging area, it will not be added to commit, the submission process is so本地工作区->暂存区stage->版本库

4. Modify revocation

• git checkout -- readme.txtLet the file back to the state when the last git commit or git add ( git checkoutin fact, is replaced with the version of the repository workspace version, whether the work area is modified or deleted, can be "a key to restore.")
  --Is very important, no --, it becomes a command "switch to another branch," the
• git reset HEAD xx.txtCancel the changes to the staging area of the workspace.
  git reset command either rollback version, can also modify the temporary area to fall back to the work area. When we use HEAD, represent the latest version

5. Branch Management

• git checkout -b devWe create a dev branch, and then switch to the dev branch, equivalent to git branch devand git checkout devtwo orders
• git branchCommand to view the current branch
• git checkout masterSwitch to the master branch
• git merge dev命令用于合并指定分支到当前分支，dev分支的最新提交是完全一样的。
  注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快
• git merge --no-ff -m "merged bug fix 101" issue-101通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式 --no-ff，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息
• git branch -d dev就可以放心地删除dev分支了

我们注意到切换分支使用git checkout ，而前面讲过的撤销修改则是git checkout – filename，同一个命令，有两种作用，确实有点令人迷惑

• git log --graph --pretty=oneline -abbrev-commit看到分支的合并情况,可以看到分支树结构。
  
  当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
  解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
• git log --graph命令可以看到分支合并图，如下图，内容比较丰富。
  
• 分支策略
  在实际开发中，我们应该按照几个基本原则进行分支管理：
  首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
  那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
  你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
  所以，团队合作的分支看起来就像这样：
  
• git stash当前工作现场“储藏”起来，等以后恢复现场后继续工作，之后，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。
• git stash list查看保存起来的工作现场
• 恢复工作现场：

1. 用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除
2. 用git stash pop，恢复的同时把stash内容也删了
3. git stash apply stash@{0}有多次stash，选择性恢复

• git cherry-pick 4c805e2复制（合并）一个特定的提交内容到当前分支；一般用于bug修复完成后需要把这个改动合并到其他分支。
• git remoteor git remote -v查看远程库的信息。你从远程仓库克隆时，实际上Git自动把本地的 master分支和远程的 master分支对应起来了，并且，远程仓库的默认名称是 origin
• git push origin master把该分支上的所有本地提交推送到远程库
• git pull获取最新提交

6.标签

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的.

tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起

• git tag v1.0默认标签是打在最新提交的commit上的，默认为HEAD
• git tag v0.9 f52c633对某次提交打标签
• git tag查看标签
• git show tagName查看某个标签的信息
• git tag -a v0.1 -m "version 0.1 released" 1094adb还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字
• git tag -d v0.1删除标签
• git push origin <tagname>推送某个标签到远程
• git push origin --tags一次性推送全部尚未推送到远程的本地标签
• If the tag has been pushed to the remote, remote tag you want to remove a little trouble
  to start local Delete: git tag -d v0.9
  then deleted from the remote. Delete command also push, but the format is as follows:git push origin :refs/tags/v0.9

7. Ignore special file

Sometimes, you have to put some files into Git working directory, but can not submit them, such as saving the password database configuration file it, and so on, each time git statuswill show Untracked files ..., there are obsessive-compulsive disorder and my heart certainly uncomfortable shoes.

Fortunately, Git taking into account everyone's feelings, to solve this problem is very simple, to create a special Git working directory in the root zone .gitignorefile, and then to ignore the file name into the fill, Git will automatically ignore these files.

.Gitignore do not need to re-write the file, GitHub has prepared a variety of configuration files for us, just a combination of what you can use. All configuration files can be directly viewed online: https://github.com/github/gitignore

Principles slightly files are:

• Ignore the operating system automatically generated files, such as thumbnails;
• Ignored by the compiler generates intermediate files, executable files, etc., that is, if a file is automatically generated by another file that is automatically generated files into the repository is not necessary, such as Java compiled .class files generated;
• Ignore your own configuration files with sensitive information, such as passwords stored in the configuration file.

8. References

• Official Documents
• Common Commands
• Git Tutorial