“Erin”为你分享6篇“《版本控制之道--使用Git》笔记”，经本站小编整理后发布，但愿对你的工作、学习、生活带来方便。
篇1：《版本控制之道--使用Git》笔记
我认为每个学过Git的人都应该做过类似这种笔记，因为Git命令太多看着看着就把前边看过的忘了，之前我也看过Git，但是一直没用，现在一看几乎没有印象了，所以这次我要把我看到的命令记下来给我自己备忘，
Git已经是最流行的版本控制系统了，网上相关的免费学习资源很多，我见过的中文书籍就有：
Git Community Book 中文版
Pro Git 中文版
Git Magic 中文版
但我是买的一本纸质书叫做《版本控制之道—使用Git》，下边是我记录的几乎是整本书讲过的所有命令：
设置
git config —global user.name “Nshen” //必须
git config —global user.email “nshen121@gmail.com” //必须
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 init
纳入版本控制:
git add *.txt //添加所有txt文件
git addREADME//添加单个文件
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 -CHEAD-a —amend //复用HEAD留言，增补提交（修改小错误，而不增加提交记录，掩盖自己的小马虎）
参数:
-m “提交的说明”
-a 动把所有已经跟踪过的文件暂存,并提交.(工作目录中修改过的文件都提交到版本库，不需一个一个手动add了)
—amend 增补提交
-C 复用指定提交的提交留言
-c 打开编辑器在已有的提交基础上编辑修改
e.g 修改最后一次提交:
git commit -m 'initial commit'git add forgotten_filegit commit --amend
如果没有修改就相当于更改提交说明,上边3个命令得到一个提交.
忽略提交的文件：
所有人都需要忽略的文件要写在.gitignore文件里，而只有自己的个人偏好需要忽略的文件要写在.git/info/exclude文件中
语法：
#此为注释 – 将被 Git 忽略*.a # 忽略所有 .a 结尾的文件!lib.a # 但 lib.a 除外*.[oa] #忽略以.o或.a结尾的文件*~#忽略以~结尾的文件/TODO # 仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODObuild/ # 忽略 build/ 目录下的所有文件doc/*.txt # 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
查看文件改动：
git diff // 比较工作目录与缓存区的区别
git diff —cached 或者 git diff —staged //缓存区与版本库里的区别
git diffHEAD//三者的区别
请注意，单单 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
其实，运行 git mv 就相当于运行了下面三条命令：
$ mvREADME.txtREADME
$ git rmREADME.txt
$ git addREADME
必须调用 git rm 文件名 //从暂存区移除,并且文件也被删除
如果只是手工删除了文件,运行git status时会出现
#Changed but not updated:#(use“git add/rm
此时必须再运行 git rm 文件名,才会在提交时候不再纳入版本管理.
如果删除之前修改过并且已经add到缓存区了的话,则必须强制删除 -f
另外一种情况是，我们想把文件从Git仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。换句话说，仅是从跟踪清单中删除。比如一些大型日志文件或者一堆.a编译文件，不小心纳入仓库后，要移除跟踪但不删除文件，以便稍后在 .gitignore 文件中补上，用 —cached 选项即可：
查看状态：
查看当前状态:
git status
$git status#On branch master#Changes to be committed: //只要在这行后边的,说明放入暂存区了#(use“git reset HEAD
查看提交历史:
git log
这时“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 =“-10.01”
git log 27j34j3j..03u43u23 //最老版本..最新版本（不包括起点只包括终点）
git log 34j4j4..HEAD
git log fhfs8fh.. //省略HEAD
git log “HEAD^^”..“HEAD^” //windows必须加引号表示回溯上一个提交
git log -1HEAD~1 //相当于git log -1HEAD^
问责：查明谁修改了代码
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 revertHEAD//创建一个反向的新提交抵消原来的提交改动
如果需要反转多个，必须从最后的开始反转, 加 -n可以不马上提交，之后一起提交，
git revert -nHEAD
git revert -n 54efhds
git commit -m “revert head and 54efhds”
复位：还没有commit，让工作目录回到上次提交时的状态
git reset —hardHEAD//所有未提交的内容清空，这会让“git diff” 和“git diff —cached”命令的显示法都变为空
git reset —softHEAD//复位版本库，暂存差异，便于提交中发现错误需要更改时有用（例如私人密码放到里边了）
分支：
在当前分支末梢建立分支：
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 //列出本地分支iss53* master //*号表示当前所在分支testing
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参数，编辑器就会使用刚拣选的提交留言作为现在的留言。
标签Tag:
查看标签:
git tag
创建标签：
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://github.com/schacon/grit.git //从现有仓库克隆
git clone git://github.com/schacon/grit.git mygrit //换名,唯一区别就是新建的目录成了mygrit,其他都一样
添加远程仓库:
git remote add pb git://github.com/paulboone/ticgit.git
clone会默认添加origin仓库，如果原本用git init创建的版本库，后来又想提交到远程版本库，就可以用下边的办法
git remote add origin git@example.com:/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 pbremote: 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://github.com/paulboone/ticgit* [new branch]master -> pb/master* [new branch]ticgit -> 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
篇2：关于Git版本控制
关于版本控制
什么是版本控制？我真的需要吗？版本控制是一种记录若干文件内容变化，以便将来查阅特定版本修订情况的系统，在本书所展示的例子中，我们仅对保存着软件源代码的文本文件作版本控制管理，而实际上，你可以对任何类型的文件进行版本控制。如果你是位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本。采用版本控制系统（VCS）是个明智的选择。有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态。你可以比较文件的变化细节，查出是谁最后修改了什么地方从而造成某些怪异问题，又是谁在何时报告了某个功能缺陷，等等。使用版本控制系统通常还意味着，就算你胡来搞砸了整个项目，把文件改的改，删的删，你也可以轻松恢复到原先的样子。而由此额外增加的工作量却微乎其微。
本地版本控制系统
许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单，不过坏处却不少：有时候会混淆所在的工作目录，弄错了文件丢了数据就没了后退的路。为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异（见图 1-1）。
图 1-1. 本地版本控制系统
其 中最流行的一种叫做 rcs，现今许多计算机系统上都还看得到它的踪影。甚至在流行的 Mac OS X 系统上安装了开发者工具包之后，也可以使用 rcs 命令。它的工作原理基本上就是保存并管理文件补丁（patch）。文件补丁是一种特定格式的文本文件，记录着对应文件修订前后的内容变化。所以，根据每次 修订后的补丁，rcs 可以通过不断打补丁，计算出各个版本的文件内容。
集中化的版本控制系统
接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？于是，集中化的版本控制系统（ Centralized Version Control Systems，简称 CVCS ）应运而生，
这类系统，诸如CVS，Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法（见图 1-2）。
图 1-2. 集中化的版本控制系统
这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。现在，每个人都可以一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库轻松容易得多。事分两面，有好有坏。这么做最显而易见的缺点是中央服务器的单点故障。若 是宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。如果中央服务器的磁盘发生故障，并且没做过备份或者备份得不够及时的话，还会有丢 失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录，被客户端提取出来的某些快照数据除外，但这样的话依然是个问题，你不能保证所有的数据都 已经有人提取出来。本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新信息的风险。
分布式版本控制系统
于是分布式版本控制系统（ Distributed Version Control System，简称 DVCS ）面世了。在这类系统中，诸如Git，Mercurial，Bazaar 还有 Darcs 等，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份（见图 1-3）。
图 1-3. 分布式版本控制系统
更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程，比方说层次模型式的工作流，这在以前的集中式系统中是无法实现的。
自：github.danmarner.com/section/ch1-1/，谢谢！
篇3：使用GitHub和Git进行版本控制（一）
今年就大三了，平时多多少少会跟几个同好一起做些小项目，其实从实用角度讲，进行版本控制并没有很多显而易见的好处，但是提早练习一下配置管理，对今后的工作总是有些益处的，至少减少了以后的学习压力。
什么是Git和GitHub
Git—The stupid content tracker, 傻瓜内容 ，是一个由Linux内核开发者Linus为了更好地管理Linux内核开发而创立的分布式版本控制软件。
GitHub— 学生做版本控制最讨厌的就是找服务器，配置太麻烦了。GitHub这个网站为每个用户提供服务器托管其Git代码库，免费空间为300M。
为什么不选CVS或SVN
Git提交/克隆/pull/push的速度更快
Git的绝大多数操作都可以在本地完成，不需要频繁连接服务器。教育网的痛苦你们不懂哇。
分布式，Linus，开源，每个关键词都能High到我…
注册GitHub账号
GitHub网址在这里
点击上方导航条的Signup and Pricing即可进入注册界面， 选择注册免费账户
Git的安装
这里只讲在Windows下的安装、配置，Linux或者Mac下的操作大同小异，
话说用Linux的这部分 应该不用看吧。
最新版的Windows版Git的下载地址在这里。
使用默认配置安装Git。这个不用多说，一路Next就可以，如果对各种选项不熟悉，建议使用默认配置，没问题的。
GitHub选择的默认通信方式是SSH，所以要先在Git里面生成SHH Key，打开Git Bash在其中输入如下命令：
之后会让你选择是否对存放SSH Key的文件夹进行加密，一般都不需要的。一路回车，就OK了。
在C:UsersAdministrator.ssh文件夹下找到id_rsa.pub文件，用记事本打开，复制其中的全部内容。这个文件默认保存在你当前用户的文件夹下的，大家那也该是大同小异的。
登陆你的GitHub账户，依次点击Account Settings>SSH Public Keys>Add another public key，把id_rsa.pub中的内容拷贝进去 。
至此，基本的设置已经完成了。
测试你的Git
经过上述配置，你的Gti应该可以通过SSH连接GitHub服务器了，让我们来测试下，输入如下命令：
会给你这样的提示：
输入yes，会显示：
到这里，说明你的SSH运转良好
GitHub的具体使用方法，会在下一篇《使用GitHub和Git进行版本控制（二）》中讲到，敬请期待。
篇4：理解 XCode 中的 Git 版本控制
每次在 Xcode 中创建新项目，都会让开发者选择是否要添加一个本地 git repository。新建一个 project 涉及分为3步的引导过程，其中在第3步也就是最后一步中，Xcode 提供了一个勾选框和相应的说明，如果勾选了，一个 git repository 就会添加到保存 project 的目录中。这个选项很容易被忽略，或者被当做一个 Xcode 的没用特性，这种事经常发生，尤其是对于从来没用过版本控制和 git 的开发者，或者新手程序员。
具体细节如下，启动Xcode并创建一个新项目。首先，选择“单视图应用程序(Single View Application)”作为应用程序的模板，同时在iOS选项部分，选择“应用程序(Application)”项。
点击“下一步(Next)”按钮到第二步，设定“产品名(Product Name)”字段为“GitDemo”，同时确保在“设备(Devices)”下拉菜单中选择“iPhone”。在这里不需要iPad或者普通应用。
再次点击下一步按钮，进入最后一步。在此，首先选择保存项目的目录。然后选中窗口的底部的单选框，并选中在“My Mac”上创建git仓库。
默认情况下，这个勾选框总是被选中的，然后每个 project 都会创建一个 git repo。如果你的项目不想用 git 和版本控制，只需取消选中，但我不建议这样做。总之，本教程中我们希望启用git，因此确保你选中了勾选框。最后，点击 Create 按钮。
等待 project 创建完成吧，然后打开一个 finder 窗口，来到我们保存 project 的目录下。在这里，找到.git子目录，这是 Xcode 自动创建的目录，用来存储 git repository 相关的数据。
如果你看不到.git目录，你必须把电脑上的隐藏文件改为可见。首先，打开Terminal(终端)窗口，然后输入以下命令：
对于 OS X Mavericks 10.9:
defaults write com.apple.finder AppleShowAllFiles TRUE
对于此前的 OS X 版本:
defaults write com.apple.Finder AppleShowAllFiles TRUE
然后，只需重启 Finder 应用，所以再输入一条命令：
killall Finder
因此，如你所见，这个 app 的本地 git repository 实际就保存在这里。相应地，你创建的任何新应用都会随之带来一个 .git 子目录，只要你保持相应的选项是勾选的。
显然，用 Xcode 来为 project 添加 git repository 是不费吹灰之力的。然而，如果你在创建 project 时没有添加 git repository，或者想要稍后再添加，怎么办呢？好消息是，你随时都可以为 project 添加 repository，但是不用 Xcode了。尽管这样的情况很少见，我还是来讲解一下。
注意，如果你不想看的话，可以尽管跳过本教程的下一节。但我建议还是读下去，因为紧接着再下一节的内容会非常重要。
在开始讲之前，你首先需要在 Xcode 里下载Command Line Tools，因为我们接下来要用 Terminal ，需要一些工具。如果你已经下载了这个包，就进行下一步。如果没有，要安装 command line tools，点击Xcode里的Xcode > Preferences…菜单，然后选择Downloads一项。在窗口的上部，Components一栏下，点击Command Line Tools右侧画着向下箭头的按钮。一旦下载结束，下载按钮会变成对勾符号。
然后，为了这个例子再创建一个 Xcode project，我们一切完成之后再把它删除。这一次确保要取消勾选Create git repository 选项。在这个例子里，我们不需要 Xcode 来为我们准备 repository 了。把这个项目命名为NoGitExample，并且保存在桌面上，这样就能直接使用我接下来的提供的指令了。
一切就绪，打开一个 Terminal 窗口（如果之前已经有打开的窗口，确定要先关闭再重启，这样才能应用安装 command line tools 时做出的改变）。首先，来到保存新 project 的目录下：
cd /Users/YOUR-USERNAME/Desktop/NoGitExample
别忘了把上面的指令改为你自己 Mac 的用户名。接下来：
git init
这会初始化一个空的 repository。然后如果你打开 Finder 或者在 terminal 输入ls指令，你会看到.git子目录已经创建出来了。太棒了。继续往下：
git add .
用这个指令，当前目录（点号[.]）的所有内容都会添加到 repository 中。最后，提交全部（也就是持久保存所做的更改）：
git commit -m 'Initial commit'
Terminal 窗口中会出现提交到本地 git repository 的文件列表。下图就是我的terminal的样子：
git repository 已经准备好了，但是如果你回到 Xcode，打开Source Control菜单，你会发现一切都还是不可用的。
这是因为 Xcode 不会自动被通知到，我们已经手动添加了 git repository。因此，点击菜单Xcode > Quit Xcode来关闭 Xcode ，然后再重启。现在，在NoGitExample项目中，如果你再打开Source Control菜单，你会看到这些的选项都可用了，跟我们创建 project 时就添加了 git repository 的效果相同。
到了这一步，就可以关闭这个 NoGitExample 项目，也可以把它从桌面上删除了。
现在你已经能够知道怎么为一个 project 添加 git repository了。并且即使你在创建 project 时有意或无意没有添加 git repository，也可以随时手动添加。
篇5：理解 XCode 中的 Git 版本控制
在你提交了多个版本之后，对比各个版本、跟踪代码的变化是非常容易的，
当新添的代码不能如预期工作时，版本对比显得尤为重要，因为你需要找到从上个稳定版本以来的所有变化。
要比较两个不同版本的文件，或者点击菜单里的View > Version Editor > Show Version Editor，或者点击工具栏上的Version Editor按钮，如下图所示：
一旦上面这一步完成，编辑器就会分裂成两部分。最开始，左、右栏都显示当前版本的文件。要把任意一栏切换为某个之前提交的版本，来到这一栏底部的工具栏，点击最后一个按钮，上面有时钟标志：
一瞬间，选择的版本对应的差异就显示在屏幕上了。一般来说，左栏用来显示当前版本的文件，而右栏用来访问旧的版本。之前提到过的蓝色区域表示了更改的代码，能轻松跟踪代码的增加。因此，再往下进行，选择任意一个之前的提交，观察两栏显示出的差异。
你应该注意到，在两个编辑器的方框之间，有我们在提交窗口中第一次看到的圆形标签。点击它们中任意一个向下箭头，将显示放弃改变的选项。如果你点击 它，Xcode会要求你确认，如果你同意了，已经选择的代码将永远的被放弃，没有任何的机会恢复。因此，要小心，不要放弃任何一片代码，甚至是在偶然的情 况下。
除了上面介绍的方法，你还有一个方法你可以恢复到以前的版本。如果你仔细观察两个方框下的工具条，在它的中间有一个带时钟和箭头的按钮。
如果你点击了它，两个方框之间列将改变并且标签将被以前提交的一系列时间戳替换。请注意不是他们所有都代表了真实的提交，这取决与提交的总量，圆角矩形的真实数字匹配以前版本的实际数量。例如，在我们的应用程序中在底部仅仅有两个形状匹配了真实的提交。
在这一栏底部，有两个箭头。左边的箭头属于左栏，指向右边；右边的属于右栏，指向左边。把这两个箭头拖到任何一个历史版本，你可以立即看到这个版本出现在对应的一栏中。如果你想对比当前版本和任何一个历史版本，只需让一个箭头指向local一行，然后拖动另外一个箭头。时间戳的顺序，从顶到底是从最新到最旧。这意味着写着base的一行，代表上一次提交的版本；而再往上看，就是那些更老的版本。下图总结了我刚才所描述的：
现在你知道如何对比版本，并跟踪代码在各个版本的变化了。现在随便玩一玩这个特性吧，之后我们再往下讲。
篇6：理解 XCode 中的 Git 版本控制
说到所谓的“提交更改到 repository”，我们实际的意思是：存储我们项目的一个新版本。新版本包含目前已作出的所有更改，比如代码修改或者新添加的文件。一般来说，一次 提交应该发生在一定量的工作已经完成，并且项目处于稳定状态之时。关于提交的频率应该是多久一次，并没有一定之规，但我建议：如果你认为从上一次提交到现 在之间，你所做的工作如果意外丢失，会造成巨大的时间精力浪费，那就一定要提交一下了。
Xcode 默认会在新项目创建时做一次初始提交，目的是保存一个项目初始状态的版本。这次提交是在幕后完成的，不会打扰你，也不会要求你确认。如果你在创建项目时没有添加 git repository，是如前所述在之后手动添加的，初始提交是通过这个指令完成的：git commit -m ‘Initial commit’我们之前用过这个指令。
实际上，你可以看到初始提交的相关信息，只需点击菜单Source Control > History…。在这里记录了你对项目的每一次提交。
我们现在来尝试一些操作吧，首先要对项目做点改动。来到ViewController.m文件，在 private class 部分添加以下的 property 声明：
1
2
3
4
5
@interfaceViewController()
@property(nonatomic)intsum;
@end
接下来，修改viewDidLoad方法如下：
1
2
3
4
5
6
7
8
9
10
11
12
-(void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
inta=5;
intb=10;
self.sum=a+b;
NSLog(“The result is: %d”, self.sum);
}
如果你看一眼Project Navigator（即左边栏），你会注意到在ViewController.m文件后面，多了一个字母M，如下图所示：
这意味着这个文件已经被修改了，并且相比上次提交的版本确实有改动。一般来说，每次你改动一个文件之后，字母M就表示已有改动，还未提交。
让我们来看看怎么提交代码。这是很简单的，仅需要打开Source Control >Commit菜单，如下窗口所示：
一步一步的让我们看看它告诉了我们什么。在左边方框（在图片中标识为#1的部分），这儿列出了所有已修改的文件。在我们的例子中，仅仅ViewController.m文件被修改，因此仅仅显示了一个文件。如果你仔细观察，你将看到文件的左侧有一个缺省选中的复选框。假如你不选中它，已经修改的文件将不会被提交。但是现在这不是我们想要的东西，因此让它被选中。
在窗口的中间位置（标识为#2的部分），有两个预览框。左侧是文件的当前版本（没有提交的），右侧是文件的最近提交的版本。截图描绘了ViewController.m文件的原始状态。
左栏的蓝色区域（图中标识为#3的部分），在右栏变成一条线，这显示了文件中的实际改动。这样的表示法让所有的改动一目了然，并且能对应到改动的具体位置 （行号）。也许你注意到了，窗口的中央，在两个预览栏之间，有一些小的圆角标签，上面写着数字（图中标识为#4）。这些标签一个一个地数出了全部的改动， 上面的数字就是计数的序号。在数字左边，有一个对勾符号。如果出现了这个对勾，说明对应的改动可以正常提交到 repository。尽管如此，你还是可以选择跳过，暂时不提交文件的某一个或几个改动，甚至抛弃所做的更改，只需点击数字右边的小下三角。含有两个选项的小菜单将会浮现：
如果你选择Don’t Commit选项，对勾符号会换成禁止符号，对应的改动就不会提交到 repository 了。
如果你选择菜单中的Discard Change选项，会出现一个确认窗口，提醒你选中的改动将会被回滚，并且回滚是无法被撤销的。
如果你点击 OK 按钮，响应区域中的改动会消失无踪，仿佛从没来到世上。
如果你有留心观察上面的提交窗口截图，你会发现所有的修改都会被 Xcode 认为是改动，即使一个空行也不例外。事实上，空行是屏幕上不显示的换行符，所以它被收集为一项改动是合情合理的。
总之，对于这个样例，确保你没有丢弃任何改动，允许一切都提交。因此你应该看到所有的圆角 label 上都有对勾。
在这两栏之下是一片空白区域，中间写着“Enter commit message here”。这个区域用来附加一些简短信息，描述这个版本所做的更改。点击它，填上下图所示的内容：
填写（有意义的）提交信息至关重要，尤其是在提交次数很多的情况下。所以，要把它当做不可或缺的一步。
既然我们已经浏览了一遍这个窗口的主要内容，下面我们来做第一次提交吧。在窗口的右下角，有一个按钮写着：Commit 1 file.
在这个按钮里，总是会写着提交的文件总数。点击它，然后恭喜！你的第一次提交已经诞生，将会永久载入历史，不仅是你个人的历史，也是 git 的历史。这是什么意思呢？只要打开菜单上的Source Control > History…，就可以看到它列在这里。
如你所见，我们之前写的提交信息以及改动的文件总数都出现在这里了。在 Xcode 做出的初始提交中，提交了所有文件；但是我们只改动了其中一个。
除此之外，如果你关闭 history 窗口，再看看 Project Navigator 左边栏，ViewController.m文件旁边的M字母也消失啦！
现在，我们准备再做一次提交吧。这一次，我们来为项目添加一些新文件，最好的方式莫过于创建一个新类。那么，按下键盘上的 Command + N 键，然后添加一个Objective-C class。把它设为NSObject的子类，命名为TestClass。最后，添加到项目中。
一旦上面这些都完成了，注意左边栏 Project Navigator 中的两个类文件旁边都出现了一个字母A；意思是这两个文件是后添加到项目中的，因此自然它们还没有被提交过。
打开ViewController.h文件，然后 import 我们的类:
1
#import “TestClass.h”
接下来，打开ViewController.m文件，如下声明一个 private 属性：
1
2
3
4
5
6
7
@interfaceViewController()
@property(nonatomic)intsum;
@property(nonatomic, strong)TestClass*testClass;
@end
再看左边栏 Project Navigator，注意到现在有4个没有提交的文件了。两个类文件是我们刚添加的，还有另外两个本来就有的文件。我们需要将这些改动也提交，因此打开Source Control > Commit…菜单。
这一次，选中了5个有待提交的文件。第5个文件（显示在第1行）是项目的配置文件，是在添加新类时由 Xcode 自动修改的。如果你点击TestClass.h或TestClass.m文件，左（译者注：原文可能笔误，此处应该为“右”）栏会变为一片空白，如下图所示：
这是因为这两个文件之前没有提交过，因此没有之前的版本可以对比。所以，右栏里只写着“File was added” 就是再正常不过的了。
来到提交信息区域，填写提交信息:TestClass class was added to the project。完成之后，点击Commit 5 files按钮，让 Xcode 提交更改到 git repository。
第二次手动提交已经顺利完成了。可以打开提交历史来验证，在菜单Source Control > History…中:
★ Directadmin面板中安装Nginx插件笔记linux操作系统
【《版本控制之道--使用Git》笔记（通用6篇）】相关文章：
命令的范文2023-04-01
决定和命令范文2022-10-15
hibernate配置文件映射文件2023-08-01
软件工程总结2022-05-07
软件工程教学总结2023-11-22
高级Java开发工程师的职责职能2023-05-23
平台架构师的职责表述2023-06-20
如何系统游有效学习java基础2022-09-09
linux关闭mysql strict mode的方法介绍linux操作系统2023-05-04
高级运维工程师的职责2022-08-30