git&把文件从&版本管理中移除
作者：舍得333
版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出版、作者信息和本声明，否则将追究法律责任。
刚学git时，一股脑吧所有文件全部加到版本管理中，
现在做Android开发，这样做就有很大的问题了，
gen& 和bin&
文件夹下的文件是编译生成的，最好不要加到版本管理中，最好加入到.gitignore文件中（这两个文件夹要留，只是把文件夹下的文件移除版本管理库）
可是，我已经加入到了版本管理中，怎么办？
一般来说，使用“git rm”命令
// 下面就以删除bin文件夹为例子，删除gen等文件，也是一样的道理，以此类推
1.刚开始 使用的是 git rm -r -n */gengen”)
参数解释：-r& 递归移除目录，(Allow recursive removal when a
leading directory name is given.)
-n：加上这个参数，执行命令时，是不会删除任何文件，而是展示此命令要删除的文件列表预览，所以一般用这个参数先看看要删除哪些文件，防止误删，确认之后，就去掉此参数，真正的删除文件。&
（Don't actually remove any file(s). Instead, just show if they
exist in the index and would otherwise be
&&&&&&&&&&
removed by the command.）
但是上面的命令真正会删除文件，我觉得，我需要的只是从版本管理库中删除，不再跟踪此文件，而硬盘上的这个文件还是要的，所以，上面的命令还要增加参数来实现此目的。
\******************开始***************\
&我们想把文件从 Git
仓库中删除(亦即从暂存区域移除),但仍然希 望保留在当前工作目录中。换句话说,仅是从跟踪清单中删除。比如一些大型日志文件或者 一堆
.a 编译文件,不小心纳入仓库后,要移除跟踪但不删除文件,以便稍后在 .gitignore 文件中补上,用 --cached
\******************结束***************\&
2.按照上面的引用，我修改的命令如下：
&git rm& -r -n
--cached&& */bin
&git rm *~&
(只删除当前目录下以“~”结尾的文件)注意到星号 * 之前的反斜杠 \,因为 Git 有它自己的文件模式扩展匹配方式,所以我们 不用
shell 来帮忙展开(译注:实际上不加反斜杠也可以运行,只不过按照 shell 扩展的
话,仅仅删除指定目录下的文件而不会递归匹配。上面的例子本来就指定了目录,所以效果
等同,但下面的例子就会用递归方式匹配,所以必须加反斜杠。)。此命令删除所有 log/ 目录下扩展名为 .log
的文件。类似的比如:
&git rm \*~ （会递归的删除当前目录 以及 子目录下的以“~”结尾的文件）
会递归删除当前目录及其子目录中所有 ~ 结尾的文件。
所以我最后的命令是git
--cached&&
(注意：此命令会真正删除文件，你可以加上"-n"参数 查看文件列表)
3.删除gen文件夹 只要把上面的“bin”改为“gen”即可
4.把这俩文件夹移除版本管理，但是 又有问题了，就是
在你执行 “git status”查看当前状态，会发现 gen和bin文件夹下的文件会出现，提示没有在版本管理里面
这就很烦人，我们既想把gen和bin移除版本管理库，
但是这样的提示，会耽误我们的“git add”命令，也会干扰我们使用“git status”的结果列表
我们想忽略这俩文件夹，
我参考了下面的连接
/questions/3325736/eclipse-android-and-gitignore
我们可以在与 “.git”文件夹同级目录下
建立“.gitignore”文件，就是这俩文件在同一个目录下“.gitignore”文件里面的内容就是&
我们要忽略的文件，这些文件即使不在版本管理库，也不会提示的
文件内容如下：
# built application files
# files for the dex VM
# Java class files
# generated files
# Local configuration file (sdk path, etc)
local.properties
# Eclipse project files
#.classpath
# Proguard folder generated by Eclipse
# Intellij project files
上面这些文件就被忽略。
原文是删除了“.classpath”和“.project”,我不建议这样做，这两个文件还是留在版本管理库，否则，你把项目导出到别的地方，再导入时就会有问题。
参考如下：
\******************开始***************\&
一般我们总会有些文件无需纳入 Git 的管理,也不希望它们总出现在未跟踪文件列表。
通常都是些自动生成的文件,像是日志或者编译过程中创建的等等。我们可以创建一个名为 .gitignore
的文件,列出要忽略的文件模式,来看一个简单的例子:
$ cat .gitignore *.[oa]
第一行告诉 Git 忽略所有以 .o 或 .a 结尾的文件。一般这类对象文件和存档文件都是
编译过程中出现的,我们用不着跟踪它们的版本。第二行告诉 Git 忽略所有以波浪符(~) 结尾的文件,许多文本编辑软件(比如
Emacs)都用这样的文件名保存副本。此外,你可能 还需要忽略 log,tmp 或者 pid
目录,以及自动生成的文档等等。要养成一开始就设置好 .gitignore 文件的习惯,以免将来误提交这类无用的文件。
文件 .gitignore 的格式规范如下:
& 所有空行或者以注释符号 # 开头的行都会被 Git 忽略。
& 可以使用标准的 glob 模式匹配。
& 匹配模式最后跟反斜杠(/)说明要忽略的是目录。
& 要忽略指定模式以外的文件或目录,可以在模式前加上惊叹号(!)取反。
所谓的 glob 模式是指 shell 所使用的简化了的正则表达式。星号(*)匹配零个或多个任 意字符;[abc]
匹配任何一个列在方括号中的字符(这个例子要么匹配一个 a,要么匹配一 个 b,要么匹配一个
c);问号(?)只匹配一个任意字符;如果在方括号中使用短划线分 隔两个字符,表示所有在这两个字符范围内的都可以匹配(比如 [0-9]
表示匹配所有 0 到 9 的数字)。
我们再看一个 .gitignore 文件的例子:
# 此为注释 & 将被 Git 忽略
*.a # 忽略所有 .a 结尾的文件
!lib.a # 但 lib.a 除外
/TODO # 仅仅忽略项目根目录下的 TODO 文件,不包括 subdir/TODO build/ # 忽略 build/
目录下的所有文件
\******************结束***************\
如果做完上面的设置后，出现编译错误，课按照下面的方法解决
With regards to the error, I would
clean the project and/or try to run the Fix Project
Properties utility (right-click on the Project
-& Android Tools -& Fix Project
Properties).
这里推荐一个学习git 的入门帖子：写的还不错
http://www.nshen.net/sitelog//git-note.html
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。酷勤网 C 程序员的那点事！
当前位置： >
浏览次数：次
我认为每个学过Git的人都应该做过类似这种笔记，因为Git命令太多看着看着就把前边看过的忘了，之前我也看过Git，但是一直没用，现在一看几乎没有印象了，所以这次我要把我看到的命令记下来给我自己备忘。
Git已经是最流行的版本控制系统了，网上相关的免费学习资源很多，我见过的中文书籍就有：
但我是买的一本纸质书叫做《版本控制之道&使用Git》，下边是我记录的几乎是整本书讲过的所有命令：
git config &global user.name &Nshen& //必须
git config &global user.email && //必须
git config &global color.ui &always& //或者&auto&, always不仅Base环境是彩色，Dos里也是彩色的。
git config &global core.editor notepad.exe //设为windows记事本
git config &global alias.ci &commit& //别名缩写
git config &global merge.tool //可以设置合并工具
git config &global &list //查看设置
其实最后这些设置都保存在C:\Documents and Settings\用户名\.gitconfig 文件下（windows）
查看帮助： git help command
纳入版本控制:
git add *.txt //添加所有txt文件
git add README //添加单个文件
git add . //添加所有文件包括子目录，但不包括空目录
add命令是个多功能命令，根据目标文件的状态不同，此命令的效果也不同：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等）注意每次修改后都要重新add,不然就会提交之前add时的版本。
git add -i //进入交互式add
git add -p //直接进入补丁模式，可以暂存修改的一部分。
git commit -m &initial project version&
git commit -m &something& someFile //提交指定文件
git commit -C HEAD -a &amend //复用HEAD留言，增补提交（修改小错误，而不增加提交记录，掩盖自己的小马虎）
-m &提交的说明&
-a 动把所有已经跟踪过的文件暂存,并提交.(工作目录中修改过的文件都提交到版本库，不需一个一个手动add了)
&amend 增补提交
-C 复用指定提交的提交留言
-c 打开编辑器在已有的提交基础上编辑修改
e.g 修改最后一次提交:
git commit -m 'initial commit'
git add forgotten_file
git commit --amend
如果没有修改就相当于更改提交说明,上边3个命令得到一个提交.
忽略提交的文件：
所有人都需要忽略的文件要写在.gitignore文件里，而只有自己的个人偏好需要忽略的文件要写在.git/info/exclude文件中
# 此为注释 & 将被 Git 忽略
# 忽略所有 .a 结尾的文件
# 但 lib.a 除外
#忽略以.o或.a结尾的文件
#忽略以~结尾的文件
# 仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODO
# 忽略 build/ 目录下的所有文件
doc/*.txt # 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
查看文件改动：
git diff // 比较工作目录与缓存区的区别
git diff &cached 或者 git diff &staged //缓存区与版本库里的区别
git diff HEAD //三者的区别
请注意，单单 git diff 不过是显示还没有暂存起来的改动，而不是这次工作和上次提交之间的差异。所以有时候你一下子暂存了所有更新过的文件后，运行 git diff 后却什么也没有，就是这个原因。
git diff 18f822e //18f822e这个版本与当前目录的区别
git diff aaaaa..bbbbb //比较aaaaa与bbbbb之间差别
git diff &stat可以统计数据，比较特别的命令
重命名，移动，删除文件：
git mv file_from file_to //改名或移动
$ git mv README.txt README
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
# Changes to be committed:
(use &git reset HEAD &file&...& to unstage)
README.txt -& README
其实，运行 git mv 就相当于运行了下面三条命令：
$ mv README.txt README
$ git rm README.txt
$ git add README
必须调用 git rm 文件名 //从暂存区移除,并且文件也被删除
如果只是手工删除了文件,运行git status时会出现
# Changed but not updated:
(use &git add/rm &file&...& to update what will be committed)
grit.gemspec
此时必须再运行 git rm 文件名,才会在提交时候不再纳入版本管理.
如果删除之前修改过并且已经add到缓存区了的话,则必须强制删除 -f
另外一种情况是，我们想把文件从Git仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。换句话说，仅是从跟踪清单中删除。比如一些大型日志文件或者一堆.a编译文件，不小心纳入仓库后，要移除跟踪但不删除文件，以便稍后在 .gitignore 文件中补上，用 &cached 选项即可：
查看状态：
查看当前状态:
git status
$ git status
# On branch master
# Changes to be committed:
//只要在这行后边的,说明放入暂存区了
(use &git reset HEAD &file&...& to unstage) //想取消放入缓存 git reset HEAD README
# Changed but not updated:
//跟踪文件内容改变,但还没有放到暂存区,需要git add 命令才会放到暂存区
(use &git add &file&...& to update what will be committed)
(use &git checkout -- &file&...& to discard changes in working directory) //删除修改,恢复到之前版本,有危险 (如果想保留并且回退版本用stashing 和分支来处理)
benchmarks.rb
查看提交历史:
这时&j&向下浏览，&k&向上浏览，&q&退出
git log &pretty=oneline //一行显示
&pretty=&%h %s& //以各种格式输出
git log &p -2 //-p显示每次提交的内容差异 -2表示最近2次更改
git log &since &5 hours&
&since &3 hours&
&since &1 minute&
&before =&&
git log 27j34j3j..03u43u23 //最老版本..最新版本（不包括起点只包括终点）
git log 34j4j4..HEAD
git log fhfs8fh.. //省略HEAD
git log &HEAD^^&..&HEAD^& //windows必须加引号表示回溯上一个提交
git log -1 HEAD~1 //相当于git log -1 HEAD^
问责：查明谁修改了代码
git blame hello.html //你也可以用&-L&参数在命令(blame)中指定开始和结束行:
git blame -L 12,+10 hello.html //12到22行
blame还可以跟踪内容复制，文件复制，略，见版本控制之道 79页
撤销缓存区的修改（没有commit的）
git checkout head 文件名 //撤销暂存区的修改
git checkout head readme.txt todo.txt
git checkout head *.txt
git checkout head . //撤销所有
反转提交：
git revert HEAD //创建一个反向的新提交抵消原来的提交改动
如果需要反转多个，必须从最后的开始反转, 加 -n可以不马上提交，之后一起提交。
git revert -n HEAD
git revert -n 54efhds
git commit -m &revert head and 54efhds&
复位：还没有commit，让工作目录回到上次提交时的状态
git reset &hard HEAD //所有未提交的内容清空，这会让&git diff& 和&git diff &cached&命令的显示法都变为空
git reset &soft HEAD //复位版本库，暂存差异，便于提交中发现错误需要更改时有用（例如私人密码放到里边了）
在当前分支末梢建立分支：
git branch RB_1.0（建立分支不会自动切换过去）
切换分支：
git checkout RB_1.0（切换到RB_1.0分支）
创建并切换分支：
git checkout -b RB_1.0（简化上边2步操作）
删除分支：
git branch -d RB_1.0
基于某次提交、分支或标签创建新分支:
git branch RB_1.0 master
git branch RB_1.0 6fe57de0
git branch Rb_1.01 1.0
查看分支：
git branch //列出本地分支
//*号表示当前所在分支
git branch -r //显示远程分支
git branch -a //列出所有分支
分支重命名：
git branch -m master mymaster
-M 大写M会覆盖同名的分支
合并分支：
直接合并：
git merge 想合并到当前分支的源分支名
git merge &no-commit 分支 //合并但不提交
压合合并：将分支压合成一条commit记录，并合并过来
git merge &squash 某bug分支
git commit -m &修复某bug&
拣选合并：只合并一个提交
git cherry-pick 321d76f
如果需要连续拣选，就需要加 -n参数
然后再git commit ，但不要加-m参数，编辑器就会使用刚拣选的提交留言作为现在的留言。
创建标签：
git tag 1.0 //在当前分支最后一次提交创建标签
git tag 1.0 RB_1.0 //基于RB_1.0分支的最新踢脚创建标签
git tag 1.0 ae468d8kt //为某次提交创建标签
检出标签：
git checkout 1.0 //检出标签与检出分支一样操作，但检出标签后用git branch查看本地分支会发现你现在不再任何分支上
这时你不应该修改，而应该立即基于此标签创建一个分支
git checkout -b from-1.0
1）git rebase RB_1.01 //也许修改过一个bug，希望新版本变基到RB_1.01分支上
2）手动解决冲突 //如果解决不了直接git rebase -skip或-abort来跳过特定提交或完全放弃变基
3）git add xxx.html //冲突解决
4）git rebase &continue
git rebase --onto HEAD^^ HEAD^ HEAD
//&onto参数可以改写历史抹掉中间的参数，将倒数第一个参数变基到倒数第3个参数，为防止出错建议在试验性分支上先试验。
rebase -i 可以排序历史记录，多个提交合并为1个，一个提交分解成多个提交 ，
详见版本控制之道p86 ，需要编辑器支持，windows记事本不行
远程相关：
git clone git:///schacon/grit.git //从现有仓库克隆
git clone git:///schacon/grit.git mygrit //换名,唯一区别就是新建的目录成了mygrit,其他都一样
添加远程仓库:
git remote add pb git:///paulboone/ticgit.git
clone会默认添加origin仓库，如果原本用git init创建的版本库，后来又想提交到远程版本库，就可以用下边的办法
git remote add origin :/xxxxxx
查看远程分支：
git remote -v //查看远程仓库,默认clone后,应该有一个origin仓库,-v显示对应的clone地址
git remote show origin //查看远程仓库信息
远程仓库重命名和删除:
git remote rename pb paul
git remote rm paul
获取数据：
git fetch [remote-name] 拉取远程仓库到本地远程仓库,不自动合并
//$ git fetch origin
$ git fetch pb
remote: Counting objects: 58, done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 44 (delta 24), reused 1 (delta 0)
Unpacking objects: 100% (44/44), done.
From git:///paulboone/ticgit
* [new branch]
-& pb/master
* [new branch]
-& pb/ticgit
现在pb/master可以在本地访问了,你可以合并到自己的某个分支,或者切换到这个分支看看有什么有趣的更新
git pull 抓取数据合并到工作目录中当前分支
推送数据：
git push [remote-name] [branch-name] //默认为 git push origin master
git push origin serverfix //推送分支，其实是下边一句的简化,提取我的 serverfix 并更新到远程仓库的 serverfix
git push origin serverfix:serferfix
git push origin :serverfix //这个语法用于删除,只要把分号前留空
git gc //垃圾回收，每隔一段时间例如一个月运行一次可以减少磁盘占用空间。
git reflog //最后的保障,列出误删的东东
git bisect //二分查找，版本控制之道p124页，略
归档版本库，导出压缩包:
git archive &format=格式 &prefix=目录/ 版本&压缩包.zip
git archive &format=zip head&test.zip
git archive &format=tar &prefix=mysite-1.0/ 1.0 | gzip&mysite-1.0.tar.gz
git archive &format=zip &prefix=mysite-1.0/ 1.0 &mysie-1.0.zip
& 相关主题：
本文来源：你的位置： >
> Git 取消跟踪已版本控制的文件
Git 是一个很好的版本控制工具，当然驾驭起来相比 SVN 要稍微复杂一些。初入 Git，难免有一些问题。比如我们不小心将某个文件加入了版本控制，但是突然又不想继续跟踪控制这个文件了，怎么办呢？
其实方法也是很简单的。使用git update-index 即可。
不想继续追踪某个文件
git update-index --assume-unchanged your_file_path
如果想再次继续跟踪某个文件
git update-index --no-assume-unchanged your_file_path
转载请注明： &
与本文相关的文章在Xcode中使用Git进行源码版本控制
招聘信息：
本文翻译自&（译者）欢迎您加入我们的翻译小组。
在应用程序开发过程中，很重要的一部分工作就是如何进行源码的版本控制。当代码出现问题时，我们就需要将代码恢复到原先正常的版本。如果是多个人共同开发一个项目，那么代码的控制就会非常复杂。幸运的是，开发者不需要自己控制这些，因为有专门的软件来负责，叫做版本控制系统。
版本控制系统，或者说修改控制系统，实际上是一种检测源文件的改变并将其保存留作以后参考使用的机制（软件）。此外，它还能记录其他有用信息，比如是哪个开发者修改了代码，何时修改的，修改了哪一部分，以及其他历史信息。版本控制系统可以比较不同版本代码的不同，有必要时能恢复整个项目到以前的版本，追踪有害代码从而减少产品的错误。
通过版本控制系统，开发者可以在一个项目的不同分支上工作，当项目的各个部分开发完备时，将它们放到一起形成最终的版本，这个过程被称为合并。事实上，这种做法再团队和软件公司中相当常见：每个人负责项目的一部分，最终所有部分被整合到一起形成最终产品。
对于个人开发者来说，版本控制系统并不是必需的，但是我们仍然强烈推荐开发者使用它，因为它可以使代码方便的在有错误的版本和可以工作的版本之间转换。事实上，很多开发者从来不使用类似的工具，他们会在项目添加新的功能时手动保存原先的项目。这其实是一个很不好的习惯，因为版本控制软件可以更好更高效地完成这项任务。
Git是一个常见的版本控制系统，它最开始是由Liunx之父Linus Torvalds开发的，Git使用虚拟目录，又称为repositories，来管理一切事物。Git可以通过命令行调用，也有专门为它设计的桌面应用软件。如果Git对你来说很陌生，我建议你在网上查看一些它的相关信息。关于Git更深层次的内容都不在本文的讨论范围之内。
从Xcode5开始引入了使用git的一些新特性。它将git的各项功能整合到一个菜单中，并提供子菜单来进行软件合并的控制。在接下来的阅读中你会发现，使用git来进行版本控制相当的简单快捷。
我们接下来的任务就是学习如何在Xcode中使用git，以及Xcode是如何整合Git的各项功能。如果你觉得对这些很陌生，我建议你先上网搜索一下相关的内容。在接下来的教程中，我会假定你已经了解了版本控制系统和git是什么，并将注意力集中在Xcode如何管理它上。
GIT Demo概述（GIT Demo Overview）
与其他教程中的demo app不同，这次我们不会去实现一个应用来演示某一项iOS SDK特性，最终我们也不会产生一个示例产品。实际上，我们会新建一个demo工程，写几行代码，然后利用这个工程来演示Xcode提供的版本管理功能。换句话说，我们会集中注意里于IDE上，而不是iOS本身。
我建议你跟着我一起一步一步实现这个实例项目，在相应的地方手动添加代码，不用担心，代码量不是很多。跟着教程的步骤，我们将执行多种重复的版本控制相关的操作，并且我们必须实时看到结果。如果我只是提供了一个具备所有操作的的应用，那么你无法体会到这些改变。
好了，废话不多说了，让我们仔细看看使用Xcode进行版本控制的要点吧。
创建一个Git源（Creating a Git repository）
每次在Xcode中创建新工程的时候，都会提示开发者是否将项目作为一个本地的git源。在创建工程的最后一步Xcode会有一个复选框，如果选择了它，git源就会被添加到工程目录中。通常这个选项会被忽视，或是被认为是Xcode的另外一个没用的功能，尤其是从未用过git的开发者，或是编程新手。
打开Xcode，创建一个新的工程。选择iOS区的&Application&，在应用模板页选择&Single View Application&。
选择下一步，在项目名中输入GitDemo，确保下面的Devices菜单选择iPhone，无需iPad或者universal app。
点击下一步，也就是最后一个步骤，在这里先选择一个要保持工程的目录，然后在窗口底部选上Create git repository on (My Mac ):
默认情况下，这个选项是被选上的，如果你不想使用git，你可以取消它，但是我不建议这么做。本教程中，你需要将它勾选上，然后点击创建按钮。
创建完项目之后，打开Finder，找到项目存储的目录，在目录中，有一个.git的子目录，时Xcode为存储git源相关数据自动创建的。
如果你看不到.git目录，你需要让隐藏的文件可见。具体做法就是打开一个Terminal窗口，输入以下命令：
对于OS X Mavericks 10.9:
defaults&write&com.apple.finder&AppleShowAllFiles&TRUE&&
对于以前的OS X版本，
efaults&write&com.apple.Finder&AppleShowAllFiles&TRUE& &
为了重启Finder应用，输入
killall&Finder&&
这就是本项目在本地git源保存的位置。实际上，如果你选上了相应的选项，这个目录就会被创建。相应地，在你创建新应用时，.git子目录也会一同被创建。
显然使用Xcode创建一个git源毫不费力，然而，如果你在项目创建时未创建git源，之后又想加上这个功能怎么办呢？好吧，其实你可以在任何时候为你的项目创建源，但是不是使用Xcode。尽管这种情况很少发生，我还是会告诉你该怎么做。
如果你愿意的话，你可以直接跳到本教程的下一部分。我建议你接着读下去，因为接下来这些信息还是很有用的。
在进行演示前，你需要首先通过Xcode下载Command Line Tools，因为我们要在Terminal下操作，并且需要一些额外的工具。如果你还没有下载，那就去Xcode>Preferences&菜单，选择Download选项卡，展开Components区，点击Commond Line Tools右边下载按钮。下载完成后，一个对勾符号会取代下载按钮。
现在，为这个例子再创建一个工程，完事后可以删了它。在创建时取消那个创建git源的选项。这次我们不想让Xcode为我们准备一个源。把这个工程命名为NoGitExample，保存到桌面，然后你可以跟我接下来输入的命令一样。
一切准备妥当后，打开Terminal窗口（如果你之前打开了一个，那就先关掉它再重启，从而使我们安装的命令行工具生效）。下面切换到新项目的目录：
cd&/Users/YOUR-USERNAME/Desktop/NoGitExample&&
别忘了在上边命令中设置Mac的用户名，接下来，输入：
git&init&&
&这会初始化一个空的源，如果你在Finder里面查看或是输入ls命令，你会看到.git子目录已经被创建，很好，接下来输入：
git&add&.&&
这样，当前目录所有的内容就被添加到源里面去了，最后，输入以下命令：
git&commit&-m&'Initial&commit'&&
接下来会出现一个本地git源所执行的改变列表，如下图所示：
现在git源就建好了，但是如果你回到Xcode，打开Source Control菜单，你会发现一切仍然是被禁用。
这是因为当我们使用命令行工具创建git源时，Xcode并未被通知，下面点击Xcode>Quit Xcode，然后重新启动它，在NoGitExample项目中，如果你再次打开Source Control菜单，你会发现所有的选项已经被使能了，就像一开始勾选上创建git源一样。
现在这个项目的使命已经结束，你可以在桌面上删除它。
现在你知道如何为你所有的项目添加git源了，即使你在创建时没有添加，你也可以在以后任何时候为它手动添加源。
提交更改（Committing Changes）
提交更改指的是储存一个包含所有更改的新版本。一般来说，当我们做了一些有意义的工作，并且项目处于某一个稳定状态时，就可以提交一次更改。然而具体什么时候提交更改并没有硬性的规定。我的建议是：从上次提交更改之后，如果你怕花费大量时间和精力做的新工作被误删很难恢复，你就需要提交更改了。
默认情况下，Xcode在项目创建之初会提交一次更改，这是为了保存项目初始状态。这项工作会在后台完成，不会打扰你或者要求你进行确认。如果你在项目创建时没有添加git源，但是之后你手动添加了，你可以通过我们先前使用过的命令来进行提交：git commit -m &Initial commit&
实际上，你如果去Source Control>History&菜单，你就会看到初次提交更改的记录，以后每次提交更改，都会在这里有所记录。
接下来让我们小幅修改一下我们的工程，在ViewController.m文件中，添加以下属性声明：
@interface&ViewController&() &&@property&(nonatomic)&int& &&@end&&
接下来，像下面这样修改viewDidLoad方法：
-&(void)didReceiveMemoryWarning &{ &&&&&[super&didReceiveMemoryWarning]; &&&&&&&&&&&int&a&=&5; &&&&&int&b&=&10; &&&&&&self.sum&=&a&+&b; &&&&&&NSLog("The&result&is:&%d",&self.sum); &}&&
看一下Project navigator面板，你会发现在ViewController.m文件旁边，添加了一个M字母，像下面这样：
这意味着那个文件已经被修改，相比上一次提交更改，文件有所改变。一般来说，你每次改变文件，都会出现这个M字母，提醒你有未提交的更改。
下面看看如何提交更改，其实非常简单，只需要打开Source Control>Commit菜单，下面窗口就会出现：
让我们一步步看看它告诉我们了什么。在左边（标1的区域），列出了所有被更改的文件，在这个例子中，只有ViewController.m这个文件被改变，因此列表中只有它被显示。如果你仔细观察，你会发现文件左边有一个选择框，默认情况下是被选中的，如果你取消它，这个文件的更改就不会被提交。
在窗口的中间区域，有两个预览窗口，左边那个是文件当前版本，右边是文件上一次提交更改的版本。因为我们目前只是创建时提交过一次更改，因此右边显示的是文件的初始状态。
左边窗口蓝色区域标出的就是更改的内容，这样的表示让我们可以清楚地看出所有的修改。如果你仔细看，会发现在两个窗口之间还有一个带数字的小标签，这个数字一一表示了各项更改。在数字旁边，默认情况下有一个小对勾，表示本更改会被提交，如果你点击右边的小箭头，会弹出一个选项菜单，你可以选择不提交这个更改或是忽略它。
如果你选择了Don&t Commit这个选项，小对勾就会被一个停止标志取代，这项更改就不会被保存到源中。
如果你选择了Discard Change这个选项，会弹出一个确认窗口，提示你所做的更改会被恢复，并且无法取消这个操作。
如果你点击了OK按钮，所选区域的改变就会消失，就像他们从未出现过一样。
如果你仔细观察上面这个提交窗口，你会看到你所做的所有修改都会被Xcode看做改变，即使是一个空行。实际上空行相当于回车，在屏幕上是不可见的，因此作为改变也是理所当然的。
在本例子中，你不用忽略任何修改，而是允许提交所有更改，因此所有的改变标签旁边必须都是小对勾。
在两个窗口下面是一个空白的区域，中间显示了提交更改的信息。这个地方可以添加一些关于此次更改的简短描述，点击它，加入如下内容：
书写有意义的提交信息非常有用，尤其是当你频繁提交的时候。因此，把它当做一个必要的步骤。
现在这个窗口的基本信息看的差不多了，是时候做我们第一次的提交了。在这个窗口的右下脚，有一个按钮上面写着：Commit 1 file。
这个按钮会显示需要提交的文件总数。点击它之后你的第一次提交就完成了！打开Source control > History，你会发现它会被显示在列表中。
从上图中可以看出，我们编写的信息以及更改的文件数量会被显示出来。Xcode执行初始提交，所有文件都会被提交一下，而这次只有我们修改的那个文件被提交。
另外，关闭历史窗口，看一下Project Navigator，你会发现ViewController.m旁边的M符号已经消失了。
现在，让我们准备下一次提交。这次，我们给工程添加一些新的文件。添加文件最好的方式就是创建个新类，因此，按下Command+N组合键，添加一个Objective-C类。让这个类继承NSObject类，取名叫TestClass，然后添加到工程中。
完成之后，注意一下Project Navigator，你会发现两个新的类文件旁边有个A的字母标识，这意味着这些文件已经被添加到项目中，当然，他们还没有被提交。
打开ViewController.h文件，导入我们的新类：
#import&"TestClass.h"&&
下一步，打开ViewController.m文件，像下面一样声明一个私有属性：
@interface&ViewController&() &&@property&(nonatomic)&int& &&@property&(nonatomic,&strong)&TestClass&*testC &&@end&&
看一下项目导航栏，这次有四个文件有待提交。让我们打开Source Control > Commit菜单，将它们提交。
需要提交的一共有5个文件。除了之前修改的四个之外，还有一个项目配置文件。Xcode会在新类被添加到项目中之后自动修改这个文件。如果你你打开TestClass.h或TestClass.m文件，左边的窗口没有任何显示，如下图所示。
这是因为在这个文件在之前没有被提交的记录，因此没有一个可以比较的版本，在右边只显示了File was added。
在消息区写上这样一个描述：TestClass was added to project.. 之后点击Commit 5 files按钮即可。
这样第二次手动提交就成功了。你可以到Source Control > History 菜单查看提交的记录。
版本之间的比较（Comparing Versions）
当你提交了同一工程的不同版本之后，在他们之间比较，追踪修改信息就会非常方便。当新添加的代码不能运行时，这时与之间版本进行比较就非常重要了，你可以看出新版本相比上个稳定版有了哪些更改。
要比较同一个文件的两个版本，你可以使用View>Version Editor>Show version editor，或是点击工具栏上的Version Editor按钮：
点击之后，编辑器会分为两栏。最初，两栏会显示相同的内容，点击编辑器下面的那个小时钟图标，可以选择之前已经提交的版本进行比较。
点击之后，两个版本的区别会在编辑器中显示出来。通常，左边显示的是当前版本的文件，右边显示的是之前的版本。蓝色高亮的区域显示了被更改的代码，因此比较代码的变化非常容易。继续选择任何此前的版本，并观察两栏的区别。
你可能会注意到，在两个编辑器中间，还有在提交窗口看到的小标签。点击向下的按钮可以跳出让你忽略更改的选项。如果你点击了忽略更改，Xcode会提示你是否同意。如果你同意忽略，这些被忽略的代码将会永远消失，无法再找回来。所以要注意不要无意中忽略任何代码。
除了上面说到的方法，还有一种你回到之前版本的方法。如果你仔细观察两个编辑器下面的工具栏，在中间有个带箭头的时钟图标：
点击它之后，两个面板之间的纵列内容就发生了改变，变成了一系列表示之前更改的时间戳。注意并不是所有的都代表实际提交。代表先前版本的圆角矩形的数量取决于提交的次数。在这个例子中，只有两个这样的图形，代表了两次提交。
在这一列的下面，有两个箭头。左边的那个属于左边的面板，右边的箭头属于右边的面板。将箭头移动到任意之前的版本，你会看到在相应面板中的改变。如果你想比较当前版本和之前任意版本的区别，让一个箭头指向local行，然后移动第二个箭头。时间戳从底部到顶部代表了从新到旧的代码。在base行，你会看到上一次提交的内容。继续向上移动，你会看到最初的提交，如下图所示：
现在你知道如何比较版本之间的区别了。再继续深入之前，把前面学习的练习一下玩玩吧。
究竟是谁的错？（Who&s Got the Blame）
除了比较文件的版本外，Xcode还可以让你追踪文件的提交者，以及是谁改变了哪一部分代码。在一个多人的团队中，这非常有用。要使用这个功能，点击View > Version Editor > Show Blame View菜单。或是讲鼠标放在工具栏的Version editor 按钮上，选择Blame选项。一个与上面类似的窗口将会出现:
正如你看到的，当前文件依据不同的提交被水平线分成几段，每个代码段的作者，以及提交信息和其他信息显示在窗口右边的一个特殊面板中。
如果你还没有做过，那自己动手打开这个blame视图，注意一下Xcode展现代码段作者的方式。在这个视图中，可以方便地找到某一代码在何时被谁提交以及其他你想要的信息。将鼠标放在blame面板上，将会显示修改的一些其他信息。当指针停在提交段上时，一个带图片的小按钮就会出现在它的右边。点击选中该段代码，就会弹出一个附带提交信息窗口。在这个窗口中，你还可以跳转到比较窗口(indication #1)，以及特定提交的修改文件(indication #2)。
除了比较视图和blame试图，其实还有一个日志视图（Log view）。你可以通过View > Version Editor > Show Log View来打开它。或者如果你在这里就不在详细说它了。你可以自己去看看，毕竟这个用起来也没那么复杂。
分支（Branches）
试想一下，你现在的工程有一个即将发布的版本，或是已经发布的版本，你突然想添加一些新的特性，如何防止这些新添加的代码让整个项目陷入瘫痪呢？答案很简单：你需要使用分支。
如何简单的理解分支呢？你可以把你的项目想象成一棵树，稳定版本就是树的主干。任何添加新功能的版本都必须是树干的一部分。分支，就像是树的枝干，它从树干生长出来，向不同的方向生长。在git中，你可以通过创建分支来为你的代码设置一个新的路径来实现新特性，而不用担心在开发中破坏主干。
实际上，在git中默认都会有一个分支，叫做master。Xcode自动执行的第一次提交中就发生在这个分支中。通常，单独的开发者只在master这个分支开发，这其实不是一个好习惯。无论你是单打独斗还是组团合作，我认为在对项目作出重大改变或添加重大功能时，使用分支是十分重要的，它会为你避免很多麻烦。当然，在团队项目中，为你自己负责部分的代码搞一个分支几乎是必须的。
关于分支，你必须记住以下两点：
1.&提交到App Store或客户的最终产品必须是项目中的master分支项目。
2.&任何在第二分支中实现的代码或者功能最终都必须合并到master分支，这样正式发布的应用程序才是完整的。（以后再讲这一点）
当你开始一个新分支时，你实际上是以当前工作状态作为起点，即使你有任何未提交的更改。从这个时候起，所有的改变都会只体现在分支中。
现在让我们回到Xcode，要创建一个分支，点击Source Control > GitDemo-master > New Brance&这个菜单，然后会弹出如下菜单：
为这个分支起一个名字，我就把它起名为AnotherBranch好了。现在你怎么给它起名其实都无所谓。点击OK按钮，等一下新的分支就会被创建，而当前的代码也会复制到新分支中去。
打开Source Control菜单，你就可以轻松地找出活动分支是哪一个：它就在项目名字的旁边。
现在，让我们做一次新的分支的提交。在这之前，让我们添加一些新的代码。打开类文件，在私有属性区添加以下方法声明：
@interface&ViewController&() &&... &&-(void)sayH &&@end&&
&然后实现它：
-(void)sayHello{ &&&&&NSLog("Hello"); &}&&
最后，在viewDidLoad中调用它：
-&(void)didReceiveMemoryWarning &{ &&&&&...&&&& &&&&&&[self&sayHello]; &}&&
现在，点击Source Control > Commit菜单，版本比较窗口将会出现，你会看到只有一个被修改过的文件--ViewController.m文件，新添加的部分会被高亮显示。
输入下一个提交信息：First commit to a new branch，然后点击commit 1 file按钮。现在AnotherBrance分支的改变就会被提交了。
打开Version Editor(menu View > Version Editor > Show Version Editor)，找到右边编辑面板下面的工具栏，你会看到被选中的分支是AnotherBranch，点击它，你会看到这个分支和master分支同时出现，从master分支中选择任意版本，Xcode都会高亮显示两者之间的区别。通过这样，你可以方便地跟踪所有分支间代码的改变。
最后，切换到另一个分支，或是master分支，你可以点击Source Control > GitDemo &AnotherBranch > Switch to Branch&菜单。
从这个窗口你可以选择想要跳转的分支，在这里让我们跳回master分支：
选择它并点击Switch按钮，master分支就会成为当然活动分支。你会发现在AnotherBranch中做出的改变并没有出现在master分支。很好，我们在管理工程推进的同时，却没有修改稳定版本。
合并分支（Merging Branches）
在分支中进行开发是一种好习惯，然而，如果代码改变要体现在发行版中，那么分支就必须被合并到master分支中。这一节我们将会告诉你怎样合并它们。在Xcode里，将两个分支合并成一个非常简单。
让我们做一个小实验来看看合并是怎样工作的。首先，确保master分支是现在的活动分支。如果不是，赶紧改过来：Source Control > GitDemo & AnotherBranch > Switch To Branch& menu，并从展示窗口选择master分支。
下一步，创建一个新的分支：Source Control > GitDemo & master > New Branch& menu，命名为LastBranch
先让Xcode飞一会，然后，到ViewController.m文件中，再创建一个私有方法，首先声明它：
@interface&ViewController&() &&... &&&-(void)sayByeB &&@end&&
然后实现它：
-(void)sayByeBye{ &&&&&NSLog("Bye&-&Bye"); &}&&
最后，在ViewDidLoad方法中调用它：
-&(void)viewDidLoad &{ &&&&&...&&&& &&&&&&[self&sayByeBye]; &}&&
在合并之前，先提交这些更改。使用Source Control > Commit菜单来执行提交。
终于还是来到这一步，关于把两个不同的分支合并成一个，你有两种选择&
1.&从分支合并：与你选择的分支相关的任何改变都会被合并到现在活动分支中。
2.&合并到分支：当前活动分支的任何改变都会被合并到你选择的分支中。
这两种方式你都可以在Source Control > GitDemo 菜单中找到。注意当你的活动分支是master分支时，第二个选项是不可选的。
假设一个开发者在Anotherbranch分支实现一个sayHello方法，另外一个开发者在LastBranch中创建实现了sayByeBye方法，现在你需要将两个人的工作合并到下一个稳定版本中，想一想你需要怎么做？很简单，按以下方法将改变从两个分支中合并进来：
首先，确保当前活跃分支是master分支。
然后，打开Source Control > GitDemo & master > Merge From Branch&菜单，选择AnotherBranch然后点击Merge按钮。
接下来会出现一个比较窗口，在里面你会看到合并之后代码的更改，看一眼，感觉差不多了就再点击Merge按钮。
Xcode会询问你是否保存项目的快照，点击Enable按钮。让Xcode飞一会，然后就好啦。AnotherBranch里面添加的内容已经合并到master分支中。
使用同样的方法来合并LastBranch。你会发现如果你不提交更改，Xcode不会让你再次合并。于是，我们只好先提交一下。在比较窗口你会发现一个红色的区域显示合并之后的更改，而不是之前的蓝色。这意味着分支中的代码将会替换原先活动分支中的代码。
你可以轻松地避免这种现象的发生。在编辑面板的下面有几个小按钮，你可以试试他们都有什么作用，我选了第一个，它的意思是master分支的代码会被放在上面，另一个分支的代码会跟在它后面。
处理接下来所有需要更改的代码，不要有遗漏。完事后就点击Merge按钮。
恭喜你！你已经成功的学会从多个分支合并了代码，类似的情形你也应该会了。
忽略更改（Discarding Changes）
放弃不想要的代码更改功能非常有用，只需轻轻一点，自从上一次提交之后的更改都会被放弃。当你在开发过程中发现出了大乱子，你想从上一个稳定状态重新开始时，这个功能就派上用场啦。注意放弃更改这个功能没有回头路，点完之后你就没有办法再撤销这个操作，所以，要小心使用啊！
之前，当我们在讨论版本比较时，我们学会了如何忽略某一部分更改的方法，下面，我们要学一下如何一下忽略自从上一次提交之后的所有更改。
为了测试这个功能，首先写一些代码打开ViewController.h ，添加一个公共方法声明：
@interface&ViewController&:&UIViewController &&-(void)aVeryCoolM &&@end&&
现在，让我们在ViewController.m中添加一个这个方法的实现，简单点就行：
-(void)aVeryCoolMethod{ &&&&&NSLog("I'm&feeling&that&you'll&discard&me...&Really?"); &}&&
如果你注意到Project Navigator，我们刚刚更改的文件旁边有了一个M标识，很好，我们想看看如果忽略这些更改，这些文件是否会回到更改之前的状态。
这里有一个重要的细节：你可以选择忽略所有文件的更改，也可以选择忽略单个文件的更改，这完全取决于你。如果你想忽略一个文件的更改，首先选定这个文件。在这个例子里，如果你只选择ViewController.m文件然后打开Source Control菜单，你会在ViewController.m中发现Didcard Changes这个选项。类似的，如果你只选择ViewController.h也是一个道理。然而，如果你想忽视这两个文件的更改（这里假定有两个以上的更改），就在Project Navigator中选中它们，然后再打开Source Control菜单。相应的位置就会显示Discard Changes in 2 Files，像下面这样：
然而，这次我们不会使用这个按钮，我们要用Discard All Changes。点击它之后，一个确定提示框就会出现，这是这部分Xcode防止你误删代码的唯一措施。
点击Discard All Changes, 那你刚才写的那个公共方法就永远属于过去了。看到了吧，只需几步就可以让你从当前工作状态恢复到之前的提交，所以我再一次提醒你要在使用Source Control 中小心点，别误点了这个按钮。
通过这篇教程，我尽力详述了在Xcode中进行版本控制的方法。其实在幕后，真正起作用的是git----地球上应用最多的版本控制系统。你可能注意到我在教程中并没有过多的提到GitHub或者任何Xcode的一些功能----其实我是故意这样的。我想把注意力集中在使用Xcode进行git管理的内容上。只有当你懂得了如何进行版本控制之后，才能真正的使用GitHub。我想再重申一下，如果你是一个团队在工作，使用版本控制工具是必须的！如果你是单打独斗，使用版本控制工具也是很有必要的，它可以为你花大量时间和精力所做的工作提供保障，并且在你添加新功能时可简单地进行扩展。这个工具就像有些人说的那样，一旦用了，就再也回不去了！最后，我希望这个教程会对你有用。
如果有啥想说的，就在下面留言吧。
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
点击量10835点击量10166点击量8199点击量5389点击量5043点击量4952点击量4407点击量4218点击量2959
&2015 Chukong Technologies,Inc.
京公网安备89}