使用git和github管理自己的项目---真实开发环境的策略

基础知识和命令先参考：使用git和github管理自己的项目---基础操作学习

13.分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

下面我们实战一下--no-ff方式的git merge：

git checkout -b dev 创建并切换到dev分支
vim readme.txt 修改readme.txt文件
git add readme.txt
git commit -m "add merge" 提交一个新的commit
git checkout master 切回master分支
git merge --no-ff -m "merge with with no-ff" dev 准备合并dev分支，注意--no-ff参数表示禁用Fast forward，因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去
git log --graph --pretty=oneline --abbrev-commit 合并后查看分支历史

合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

14.分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活
那在哪里干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如2.0版本发布时，再把dev分支合并到master上，在master分支发新版本
你和你的小伙伴每个人都在dev分支上干活，每个人都有自己的分支，时不时往dev分支上合并就可以了

所以，团队合作的分支看起来就像这个样子：

Git分支十分强大，在团队开发中应该充分应用。

15.Bug分支

软件开发中，bug就像是家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

当你街道一个修复代号为101的bug的任务的时候，很自然的，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：

git status 查看状态

并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

git stash 用该命令查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心的创建分支来修复bug了。
git checkout master 从dev分支切换回master
git checkout -b issue-101 假定需要在master分支上修复，就从master创建临时分支
假设现在修复好了bug，本例中，就假如在readme.txt文件中做了修改
git add readme.txt
git commit -m "fic bug 101" 修改之后提交
git checkout master 从issue-101切换回master
git merge --no-ff -m "merged bug fix 101" issue-101 合并分支选择不适用Fast forward模式，然后添加必要的描述信息
git branch -d issue-101 删除issue-101这个临时bug修复分支
太棒了，bug搞定了，现在可以回到dev分支干活了
git checkout dev 切换回dev分支
git status 可以看出工作区是干净的，那么刚才的工作现场存在哪里呢？
git stash list 看到工作现场还在，Git吧stash内容存在某个地方了，但是需要恢复一下
方法一git stash apply，但是回复后，stash内容并不删除，你需要使用git stash drop来删除
方法二git stash pop，恢复的同时也把stas内容删除了
git stash list 再用git stash list查看，就看不到任何stash内容了
你可以多次stash，恢复的时候，先用giit stash list 查看，然后恢复指定的stash，使用如下的命令
git stash apply stash@{0}

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除。

当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场。

16.Feature分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。

添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。软件开发中，总有无穷无尽的新的功能要不断添加进来。

现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。于是开始准备工作

git checkout -b feature-vulcan 在dev分支上创建并且换到feature-vulcan分支，用来开发新功能
假如现在经过一定的时间后，工作完成了
git add vulcan.py
git status 查看状态
git commit -m "add feature vulcan" 提交
git checkout dev 切换回dev分支
一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。但是，就在此时，接到上级命令，因经费不足，新功能必须取消！虽然白干了，但是这个分支还是必须就地销毁，不要再合并了:
git branch -d feature-vulcan 销毁失败。Git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用命令git branch -D feature-vulcan。
git branch -D feature-vulcan

17.多人协作

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

推送分支

git remote 查看远程库的信息
git remote -v 显示更为详细的信息
git push origin master 推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上。
git push origin dev 也可以推送到其他的分支，比如dev分支
但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？master分支是主分支，因此要时刻与远程同步；dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

抓取分支

多人协作时，大家都会往master和dev分支上推送各自的修改。

git clone [email protected]:michaelliao/learngit.git 现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆。
git branch 当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支，所以执行这条命令只能看到master分支
git checkout -b dev origin/dev 现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支
git commit -m "add /usr/bin/env" 现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程。
git add hello.py git commit -m "add coding: utf-8" git push origin dev 你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送。推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突。
git pull 解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送。
git branch --set-upstream dev origin/dev git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接。
git pull 再次pull，这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样
git commit -m "merge & fix hello.py" git push origin dev 解决冲突后，再提交，再push

因此，多人协作的工作模式通常是这样的：

首先，可以试图用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。这就是多人协作的工作模式，一旦熟悉了，就非常简单。

18.标签管理

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

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

19.创建标签

git branch 查看当前有哪些分支
git checkout master 在Git中打标签非常简单，首先，切换到需要打标签的分支上
git tag tagnamev1.0 打一个新标签
git tag 查看所有标签
默认标签是打在最新提交的commit上的（也就是HEAD）。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？
git log --pretty=oneline --abbrev-commit 方法是找到历史提交的commit id，然后打上就可以了，这时候显示了提交的历史信息，假如有这么一条就是你想打标签的历史commit：6224937 add merge
git tag tagnamev2.0 6224937 就可以给这次提交打标签了
git tag 可以查看标签信息，注意，标签不是按时间顺序列出，而是按字母排序的
git show tagnamev2.0 查看具体的某个标签的信息
git tag -a v0.1 -m "version 0.1 released" 3628164 还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字
git show v0.1 查看具体的某个标签的信息，可以看到说明文字
git tag -s v0.2 -m "signed version 0.2 released" fec145a 还可以通过-s用私钥签名一个标签，签名采用PGP签名，因此，必须首先安装gpg（GnuPG），如果没有找到gpg，或者没有gpg密钥对，就会报错
git show v0.2 用命令git show 可以看到PGP签名信息，用PGP签名的标签是不可伪造的，因为可以验证PGP签名。

20.操作标签

git tag -d v0.1 假如标签打错了，也可以删除，因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
git push origin v1.0 要推送某个标签到远程
git push origin --tags 或者，一次性推送全部尚未推送到远程的本地标签
git tag -d v0.9 如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除
git push origin :refs/tags/v0.9 然后，从远程删除。删除命令也是push，但是格式要注意

21.使用Github

如何参与一个开源项目呢？比如人气极高的bootstrap项目，这是一个非常强大的CSS框架。

你可以访问它的项目主页https://github.com/twbs/boots...，点“Fork”就在自己的账号下克隆了一个bootstrap仓库
git clone [email protected]:yourname/bootstrap.git 然后，从自己的账号下clone
一定要从自己的账号下clone仓库，这样你才能推送修改。如果从bootstrap的作者的仓库地址[email protected]:twbs/bootstrap.git克隆，因为没有权限，你将不能推送修改。

Bootstrap的官方仓库twbs/bootstrap、你在GitHub上克隆的仓库my/bootstrap，以及你自己克隆到本地电脑的仓库，他们的关系就像下图显示的那样：

如果你想修复bootstrap的一个bug，或者新增一个功能，立刻就可以开始干活，干完后，往自己的仓库推送。

如果你希望bootstrap的官方库能接受你的修改，你就可以在GitHub上发起一个pull request。当然，对方是否接受你的pull request就不一定了。

如果你没能力修改bootstrap，但又想要试一把pull request，那就Fork一下廖雪峰的仓库：https://github.com/michaellia...，创建一个your-github-id.txt的文本文件，比如我的：xumenger.txt，写点自己学习Git的心得，然后推送一个pull request给他，他会视心情而定是否接受。

22.自定义Git

之前已经说过在使用之前必须先配置user.name和user.email，否则后面commit的时候可能会有错误，实际上git还有很多可配置的：

git config --global color.ui true 让Git显示颜色，会让命令输出看起来更醒目，自己去试试一些git命令的输出看看是不是有色！

23.忽略特殊文件

有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等，每次git status都会显示Untracked files ...，有强迫症的童鞋心里肯定不爽。

好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。

不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/git...

忽略文件的原则是：

忽略操作系统自动生成的文件，比如缩略图等；
忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如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。.gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！

使用Windows的童鞋注意了，如果你在资源管理器里新建一个.gitignore文件，它会非常弱智地提示你必须输入文件名，但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。

再次建议：有钱的买mac，没钱的用ubuntu--或者其他的linux发行版、被逼无奈的用Windows--但是被逼之余的自主时间一定要远离Windows。

24.配置别名

给Git配置好别名，就可以输入命令时偷个懒。我们鼓励偷懒。

git config --global alias.st status 有没有经常敲错命令？比如git status？status这个单词真心不好记。如果敲git st就表示git status那就简单多了，当然这种偷懒的办法我们是极力赞成的。
git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.br branch
很多人都用co表示checkout，ci表示commit，br表示branch
git ci -m "bala bala bala..." 以后提交就可以简写成这样
git config --global alias.unstage 'reset HEAD' 在撤销修改一节中，我们知道，命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区。既然是一个unstage操作，就可以配置一个unstage别名
git unstage test.py 当你敲入此命令，实际上Git执行的是：git reset HEAD test.py
git config --global alias.last 'log -1' 配置一个git last，让其显示最后一次提交信息
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit" 甚至还有人这样的配置，那么，这时候git lg的效果是这样的

配置文件

配置Git的时候，加上--global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用。

配置文件放哪了？每个仓库的Git配置文件都放在.git/config文件中：

$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
[remote "origin"]
    url = [email protected]:michaelliao/learngit.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[alias]
    last = log -1

别名就在[alias]后面，要删除别名，直接把对应的行删掉即可。

而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中：

$ cat .gitconfig
[alias]
    co = checkout
    ci = commit
    br = branch
    st = status
[user]
    name = Your Name
    email = [email protected]

配置别名也可以直接修改这个文件，如果改错了，可以删掉文件重新通过命令配置。

25.搭建Git服务器

如果需要的话，请自己参考廖雪峰的教程