推送本地操作
初始化一个本地Git仓库，在需要添加版本控制的文件夹根目录中使用git init命令。
添加文件到本地Git仓库：
git add 文件名 # 添加文件到暂存区
git add . # 添加多个文件到暂存区
git add -all # 添加多个文件到暂存区
git commit # 提交更改，实际上就是把暂存区的所有内容提交到本地仓库当前分支。
查看工作区的状态，使用git status命令。
如果git status告诉你有文件被修改过，用git diff可以查看修改内容。
查看操作历史记录可用git log命令查看，git log命令显示从最近到最远的提交日志。如果觉得输出信息太多，可以加上–pretty=oneline参数。
在Git中，用HEAD表示当前版本，上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100，版本回退命令使用git reset命令，回退之后可以再恢复到回退前的版本，只要上面的命令行窗口还没有被关掉，找到commit id 回退到指定版本，版本id不用全写，前几位就可以了，Git会自动去找。也可以通过命令git reflog用来查看你输入的每一次命令，查找到回退前的版本号。
git reset --hard HEAD^ # 回退到上一版本
git reset --hard 3628164 # 回退到指定版本
git reflog # 查看你输入的每一次命令- 使用命令git checkout – file可以直接丢弃工作区的修改，使用命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区。
git checkout -- 文件名 # 丢弃工作区的修改
git reset HEAD 文件名 # 把暂存区的修改撤销掉，重新放回工作区- 命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
推送到远程仓库
- 由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：
第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：
$ ssh-keygen -t rsa -C "youremail@example.com"你需要把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。
如果一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。
第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面，
然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容，
点“Add Key”，你就应该看到已经添加的Key。
- 登陆GitHub，然后，在右上角找到“Create a new repo”按钮，创建一个新的仓库。
在本地的git仓库下运行命令：
$ git remote add origin github复制下来的仓库地址 # 把本地git仓库与github仓库关联起来- 把本地git仓库的所有内容推送到远程github仓库上：
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
git push -u origin master # 第一次推送到master分支时，加上了-u参数
git push origin master # 把本地master分支的最新修改推送至GitHub- 从远程github仓库克隆到本地，使用命令git clone
git clone github仓库地址 # 从远程github仓库克隆到本地- 创建分支
git checkout -b dev # 创建dev分支，然后切换到dev分支
// 相当于以下两条命令
git branch dev # 创建
git checkout dev # 切换
git branch # 查看当前分支然后，我们就可以在dev分支上正常提交
git add readme.txt
git commit -m "branch 注释"
git checkout master # 在dev分支的工作完成，切换回到master分支- 使用git merge命令用于合并指定分支到当前分支
git merge dev # 把dev分支的工作成果合并到master分支上
git branch -d dev # 合并后可以删除dev分支- 解决冲突
合并分支的时候有时候会存在冲突，git status命令可以告诉我们冲突的文件。
Git用<<<<<<<，=======，>>>>>>>标记出不同分支冲突的内容，修改后再提交。
git add 冲突文件 # 修改后提交
git log --graph --pretty=oneline --abbrev-commit # 用带参数的git log也可以看到分支的合并情况。- 分支管理
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
/* 合并dev分支，请注意--no-ff参数，表示禁用Fast forward,因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。*/
git merge --no-ff -m "merge with no-ff" dev
// 合并后，可用git log看看分支历史
git log --graph --pretty=oneline --abbrev-commit分支策略：在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
- Bug分支
软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是如果当前正在dev上进行的工作还没有提交，并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？
可以用Git提供的stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
git stash # 暂存当前的工作进度信息现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：
git checkout master # 切换到主分支
git checkout -b bug-101 # 创建并切换到bug-101分支
git add 修复bug后的的文件 # 添加到暂存区
git commit -m "fix bug 101" # 提交到本地bug-101分支仓库
git checkout master # 切换到master主分支
git merge --no-ff -m "merged bug fix 101" bug 101 # 把bug-101分支合并到master主分支
git branch -d bug 101 # 删除bug 101分支修复Bug后，接着回到dev分支干活
git checkout dev # 切换到dev分支
git status # 查看工作区
// 工作区是空的，因为刚刚我们已经将工作区暂存起来了
git stash list # 用git stash list命令查看工作现场去哪了
/* 工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除
另一种方式是用git stash pop，恢复的同时把stash内容也删了*/
git stash pop # 恢复工作现场的同时把stash内容也删了
git stash list # 再用git stash list查看，就看不到任何stash内容了你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：
git stash apply stash@{0} # 恢复指定的stash分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用命令git branch -D 分支名称
git branch -D feature-vulcan # 强行删除feature-vulcan分支- 多人协作
当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。
// 查看远程库的信息
git remote
// 显示远程库更详细的信息，如果可以抓取和推送就会显示origin的地址。如果没有推送权限，就看不到push的地址。
git remote -v 推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上
git push origin master # 推送到远程库中的master分支上
git push origin dev # 推送到远程库中的Dev分支上
本地分支往远程推送，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要时刻与远程同步；
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
其他分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！
多人协作的工作模式：
首先，可以用git push origin branch-name推送自己的修改；
如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用git push origin branch-name推送就能成功！
如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch –set-upstream branch-name origin/branch-name。
- 标签管理
发布一个版本时，我们通常先在版本库中打一个标签（tag）。
在Git中打标签非常简单，首先，切换到需要打标签的分支上：
git branch # 查看分支
git checkout master # 切换到master分支
git tag v1.0 # 打一个v1.0新标签
git tag # 查看所有标签
默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？
方法是找到历史提交的commit id，然后打上就可以了：
git log --pretty=oneline --abbrev-commit # 查看历史提交的commit id
git tag v0.9 commitId # 打一个v0.9的标签到commitId版本上
git show v0.9 # 查看v0.9标签信息还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：
// -a指定标签名，-m指定说明文字,3628164是指定commit id版本号
git tag -a v0.1 -m "version 0.1 released" 3628164 还可以通过-s用私钥签名一个标签：
git tag -s v0.2 -m "signed version 0.2 released" fec145a签名采用PGP签名，因此，必须首先安装gpg（GnuPG），如果没有找到gpg，或者没有gpg密钥对，就会报错：
gpg: signing failed: secret key not available
error: gpg failed to sign the data
error: unable to sign the tag如果报错，请参考GnuPG帮助文档配置Key。
用命令git show tagname可以看到PGP签名信息。
用PGP签名的标签是不可伪造的，因为可以验证PGP签名。
操作标签
git tag -d v0.1 # 本地标签直接删除
git push origin v1.0 # 推送v1.0标签到远程仓库
git push origin --tags # 推送全部尚未推送到远程的本地标签
// 如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除
git tag -d v0.9 # 删除本地标签
git push origin :refs/tags/v0.9 # 删除远程仓库标签
- 忽略特殊文件
在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。
不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore
忽略文件的原则是：
忽略操作系统自动生成的文件，比如缩略图等；
忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；
忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。
举个例子：
假设你在Windows下进行Python开发，Windows会自动在有图片的目录下生成隐藏的缩略图文件，如果有自定义目录，目录下就会有Desktop.ini文件，因此你需要忽略Windows自动生成的垃圾文件：
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini然后，继续忽略Python编译产生的.pyc、.pyo、dist等文件或目录：
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build加上你自己定义的文件，最终得到一个完整的.gitignore文件，内容如下：
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build
# My configurations:
db.ini
deploy_key_rsa最后一步就是把.gitignore也提交到Git，就完成了！当然检验.gitignore的标准是git status命令是不是说working directory clean。
使用Windows的童鞋注意了，如果你在资源管理器里新建一个.gitignore文件，它会非常弱智地提示你必须输入文件名，但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。
有些时候，你想添加一个文件到Git，但发现添加不了，原因是这个文件被.gitignore忽略了：
$ git add App.class
The following paths are ignored by one of your .gitignore files:
App.class
Use -f if you really want to add them.如果你确实想添加该文件，可以用-f强制添加到Git：
$ git add -f App.class或者你发现，可能是.gitignore写得有问题，需要找出来到底哪个规则写错了，可以用git check-ignore命令检查：
$ git check-ignore -v App.class
.gitignore:3:*.class App.classGit会告诉我们，.gitignore的第3行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。
参考文献：
2128
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
