难用的SourceTree

团队开发,比较常用的管理代码的是git、svn。

svn里面好用的就是小石头和小莲花

难用的SourceTree_第1张图片
难用的SourceTree_第2张图片

svn就不赘述了,今天咱们讲一讲git里面的一个叫sourcetree的初用比较难用的代码管理工具。

关于为什么使用sourcetree,我们同事总结了一下,照搬过来了。在这里谢谢LH,虽然你也不看我的技术博客。

为什么使用git

Git相比SVN,CVS,最大的特点也是优点在于提供分布式的代码管理。这不是说SVN等不具有该功能,但就目前来看,Git更完善,而且也越来越多地被人们所接受。前途和易用是我一向选择的基准。

在使用中,目前体验到最大的相比SVN的好处有;

分支代码只有一份!log在本地!合并代码更加方便!更加安全!目录更加简洁!

简单做下解释;

(1)分支代码只有一份!

使用过svn的童鞋想必都知道,当我们要开发一个新功能或者增加一个新版本或者修改一个复杂bug的时候,通常需要copy整份代码到本地一个目录,然后添加到svn服务器上进行代码管理。

而Git不同,Git可以创建许多branches,每个branch都是独立的,当我们需要修改代码的时候,commit也只是对本地仓库的修改。如果使用SourceTree,我们会发现在工具栏的Git Flow功能,已经很好的为此做了准备。

(2)log在本地!

svn的log都是存储在服务器上的,当我们要查阅修改记录的时候,必须要能够连接上远程服务器,并且具有权限。而Git不同,Git对于本地仓库的修改记录都是在本地上的,方便查阅。

(3)合并代码更加方便!

因为Git支持本地无限Branches,当我们个体在本地创建多个branches用于不同目的的时候(修改,新增,探索),合并一份代码显然要比svn合并一堆工程copy更加简单。

(4)更加安全!

Git的commit命令不同于SVN,commit只是对本地仓库代码的一次更新。当需要提交到master远程仓库,或者其他远程分支仓库的时候,需要使用push功能。虽然增加了一个过程,却可以防止随意修改导致后期合并出现大问题的风险。

(5)目录更加简洁!

在Git本地仓库根目录,只有一个.git文件,它包含了所有的管理信息。而SVN想必大家都知道,每个子目录下都有噁心的.svn。这个当需要修改文件冲突等问题时,就需要考虑了。肯定是一个文件简单。

至于为啥我们要用这个管理代码的工具,,,因为我们项目是混合开发的。


难用的SourceTree_第3张图片

首先附上每次拉取和推送的时候不用每次输入密码的命令行:git config credential.helper osxkeychain sourcetree



在这里打开终端,贴上上述命令行等一会儿执行好了就可以了,第一次拉取的时候还是要输入一次密码,以后就不用每次输入密码了。

遇到的情况:

1、在拉取的过程中遇到如下提示:


难用的SourceTree_第4张图片

这种情况是说没有正在运行的一个git程序,如果有,会被覆盖。没搞懂具体什么意思,操作如下:点击关闭,再次拉取就可以了。至今上述操作没有遇到什么问题。

2、冲突。

冲突解决办法(在此鸣谢LH童鞋,虽然你也不看我的技术博客)

如果两个开发者修改了同一个文件的同一段代码,或者修改了同一个文件路径,提交并push到sourceTree时会提示冲突。需要先修正本地冲突,冲突的标志是“<<<<<<<”,"=======",">>>>>>>"之间的部分,解决的办法:

(1)第一种是逐行删掉冲突,找到protect.pbxproj,右键选择“在finder中查看”,找到protect.pbxproj文件双击打开,cmd+f搜索“<<<<<<<”,找到冲突的部分,删除“<<<<<<<”及其对应的行,删除“=======”及其对应的行,删除“>>>>>>>”及其对应的行,然后重新提交就可以了。

(2)第二种方法,右键---->解决冲突——>使用他人版本解决冲突---->确定-----重新提交

(3)第三种方法,revert冲突的本地文件,然后重新提交

如果文件已经提交到本地仓库,但未push到服务器,出现冲突,可以回滚本次提交。

拉取文件时如果出现文件冲突,解决办法:revert冲突的本地文件,然后重新提交。

(下边是我自己的总结,关于冲突的解决方案)


难用的SourceTree_第5张图片

config文件冲突了,这里需要说明的是,冲突大概有两种情况:

(1)没有代码的文件冲突:一般像config或者工程文件冲突,我们的处理就是放弃自己的本地修改,即revert(重置)自己的config或者工程文件,再次拉取就没有什么问题了。

(2)有代码的文件冲突:这种情况就要注意了,十分建议在进行下一步操作之前,备份一份自己的代码,最少是自己动过的类,不然很有可能自己的辛苦劳动在“重置”之后不见了。这种情况我的处理方法是:备份后选择将冲突的类全部重置,然后拉取,此时就不会冲突了,再把自己写的代码拷贝到拉取后的相应的类文件里面,再提交推送就可以了。

(3)小技巧避免冲突

一般我们提交代码的顺序是:拉取-提交-推送。这个没有问题,但是有时候会只是提交了,忘了推送,过了一个小时或者一段时间,才想起来,结果推送的时候冲突了,甚至你即便刚刚提交了,马上点击推送,都可能造成冲突:因为有人可能在你操作:拉取之后,提交之前,又推送了,你的版本不是最新的版本了,可能造成冲突。所以建议大家提交代码的顺序是:拉取-提交-拉取-推送。而且,最好是提交了代码,马上拉取,马上推送,尽量避免不冲突。因为冲突给我们带来不必要的麻烦:本来开开心心的撸代码,最后因为这个难用的sourcetree把心情搞的很糟糕。不值。

甚至有这种方法避免操作,屡试不爽:想提交自己的代码了,先不拉取,先提交,提交好了,再拉取,再推送,即:提交-拉取-推送。这种方法基本上不会冲突,因为保证了你的代码是最新的版本,这种操作下甚至于两个人同时动一个类文件都不会冲突。总之,建议大家使用这种方法。亲测无误。

(4)丢代码的情况。

丢代码的情况我们也遇到过,具体产生的原因我至今没有搞明白,应该是有人的版本落后了,但是没有拉取,等他提交和推送的时候,选取的可能太多,把别人的代码干掉了,这只是我的推测,不知道具体操作是什么。这种行为太令人愤怒了,辛苦撸的代码被别人搞丢了,一些bug又都出现了,真心不能开心的撸代码了。

我们组内遇到这种情况时,第一个人说代码丢了,我没管,第二个说代码丢了,我也没管,第三个人说代码丢了,我还是没管。。。等我发现我的代码也丢了,那些人谁也没说话,哎。不禁叫我想起了下边的名段:

“起初他们迫害共产党员,我没有说话,因为我不是马克思的信徒。”

“后来他们迫害犹太人,我没有说话,因为我是日耳曼人。”

“再后来他们迫害天主教徒,我没有说话,因为我是新教牧师。”

“最后他们迫害到我头上,我环顾四周,却再也没有人能为我说话。”

这首诗《我没有说话》被镌刻在美国马萨诸塞州波士顿的新英格兰犹太人大屠杀纪念碑石碑上。是德国著名神学家兼信义宗牧师马丁·尼莫拉的一首诗(忏悔文)尽管他写的是自己,但这首诗令世人警醒,描述忽视与自己无关的团体所造成的结果。该诗后来常被引用,作为对不关心政治的人之呼吁。

这种情况就是有人操作不当造成的,所以希望提交代码只动自己的类,不要动别人的!如果,在开发过程中,两个人需要动同一个类的话,两个人商量好,谁先谁后,不要出错就好了。

(5)安卓和iOS和混合开发发生冲突

至今我没遇到,但是安卓的遇到了,他和我们iOS的代码冲突了。。。具体真的遇到了会再来这里补上解决方案。总之,sourcetree很难用,每一次拉取提交推送,都要小心谨慎啊。

5、小建议

(1)重新checkout的sourcetree要记得“检出”一下,才有develop。不然在自己的文件夹下边可能只有一个什么README.md的文件,没有工程文件,没有.h,没有.m,什么也没有。


难用的SourceTree_第6张图片


checkout下来找不到自己的工程在哪里,可以点击下图红框内的“在finder中显示”,就会自动找到的。



在checkout的时候会指定一个路径,尽量不要动这个路径,不然会提示一个“这是无效的url”。这一点不知道如何解释。。。

(2)提交的时候要提交develop,不要动master。master是主枝,是最后打tag包时候用的或者对master做操作的时候才用到的。

6、今天又遇到一个bug,如图:

难用的SourceTree_第7张图片

告诉我你是谁?!

可能是app上线了以后,没有怎么打开过sourcetree的原因吧,然后居然忘记我了。。。。

解决办法:


在这里打开终端,输入下边的命令行:

git config --global user.email "[email protected]"

git config --global user.name "Your Name"

敲回车,再去sourcetree提交或者进行别的操作即可。




初次使用soucetree会感觉很难用,等你用了一段时间后把所有的坑都踩过一遍以后,你会发现:soucetree真的很难用!!!还是怀念小石头和小莲花啊!!!

以后遇到什么没有遇到的情况会来这里补上的。

最后,哪里不对的地方可以给我留言,我会及时改进的,谢谢大家。

你可能感兴趣的:(iOS_OC,ios错误)