基础命令
-
git init把目录变成Git可以管理的仓库。 -
git add把文件添加到仓库。 -
git commit把文件提交到仓库 -
git commit -m "这里是文件提交说明"添加提交说明，方便查阅。 -
git status查看追踪的目录文件哪些做了修改。 -
git stage查看仓库当前状态。 -
git diff查看上次修改内容。 -
git log查看历史修改记录。
git log --pretty=online只看提交说明
时光穿梭
-
git reset --hard HEAD^回到上一个版本。 -
git reset --hard 321ef1回到版本为 321ef1到状态，版本号没必要写全，前几位就可以，Git会自动去找。 -
git reflog查看历史穿梭版本。 -
git checkout -- file丢弃工作区的修改。(git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。)
HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。
工作区和暂存区
工作区（Working Directory）
顾名思义就是当前工作的目录。
版本库（Repository）
工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
git add命令将文件添加到暂存区。
git commit命令将所有暂存区内容提交到当前分支。
Workflow
因为我们创建Git版本库时，Git自动为我们创建了唯一一个
master分支，所以，现在，git commit就是往master分支上提交更改。
其实就是将需要提交的文件修改通通放到暂存区，然后一次性提交暂存区的所有修改。
远程仓库
1.创建SSH Key
$ ssh-keygen -t rsa -C "youremail@example.com"
2.关联远程仓库
$ git remote add origin git@github.com:blacker/learngit.git
blacker为关联的github账户名，learngit为仓库名
3.推送到远程库
git push -u origin master
git push命令是把本地当前分支masrer推送到远程库。
如果远程库是空的，第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以使用简化命令。
git push origin master
错误处理
To github.com:hellowqw/leargit
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'git@github.com:hellowqw/leargit'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
出现错误的主要原因是github中的README.md文件不在本地代码目录中
解决
可以通过如下命令进行代码合并【注：pull=fetch+merge]
git pull --rebase origin master
执行上面代码后可以看到本地代码库中多了README.md文件
分支
创建仓库时默认只有一个分支，即主分支master。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的。
最初，master分支是一条线，Git用master指向最新的提交，在用HEAD指向master，就能确定当前分支，以及当前分支的提交点：
每次提交，
master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。当创建新的分支，例如
dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：
git checkout -b dev
-b参数表示创建并切换分支，相当于以下两条命令：
git branch dev
git checkout dev
用git branch命令查看当前分支：
git branch
* dev
master
Git创建一个分支很快，因为除了增加一个
dev指针，改变HEAD的指向，工作区的文件都没有任何变化！
不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
假如在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并。
切换master分支：
git checkout master
此时状态：
现在，把
dev分支的工作成果合并到master分支上：
git merge dev
Updating d17efd8..fec145a
Fast-forward #快进模式也就是直接把master指向dev的当前提交，所以合并速度非常快。
readme.txt | 1 +
1 file changed, 1 insertion(+)
git merge命令用于合并指定分支到当前分支。
所以Git合并分支也很快！就改改指针，工作区内容也不变！
合并完分支后，甚至可以删除dev分支。
git branch -d dev
删除dev分支就是把dev指针给删掉，删掉后，就剩下了一条master分支。
git branch
* master
因为创建、合并和删除分支非常快，所以Git鼓励我们使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。
小结
查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>
创建+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>
分支管理策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
令，上面有提到合并分支时又一个Fast forward模式，需要注意到是这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
git merge --no-ff -m "merge with no-ff" dev
网友评论