工欲善其事，必先利其器竭鞍。
前一陣子，公司的版本控制從svn遷移到了git,不得不說橄镜，git確實比svn要強大好多偎快，單單是一個分支功能，就有很多值得學(xué)習(xí)的地方洽胶，通過git分支的版本控制晒夹，我們可以很方便的進行不同開發(fā)環(huán)境的切換。
先講一下姊氓，我們?yōu)槭裁匆鲩_發(fā)與正式環(huán)境的分離丐怯。以前使用svn的時候，我們沒有分環(huán)境之說翔横，這會導(dǎo)致一個問題读跷，那就是我們的開發(fā)版無法與線上的版本并存，如果你想要對照功能的話棕孙，就必須要刪掉另一個舔亭，因為二者的BundleID是一樣的。現(xiàn)在我們的APP通過git的版本控制分成了三個分支蟀俊，對應(yīng)著三個環(huán)境，分別是publish(正式環(huán)境)订雾，simulate（仿真環(huán)境肢预，接近正式環(huán)境），和develop(開發(fā)環(huán)境)洼哎，每一個環(huán)境都對應(yīng)著不同的info.plist配置文件烫映，它們各自的BundleID是不同的沼本，因此可以理解為三個軟件，這樣我們在切換分支的時候锭沟，就會進入不同的開發(fā)環(huán)境抽兆，方便很多，打包后也可以在手機上并存族淮。
現(xiàn)在來看辫红，分支切換是沒有什么問題的，然而在分支進行合并的時候祝辣，plist配置文件勢必會發(fā)生被覆蓋的情況贴妻，比如我從publish正式環(huán)境分出來一個功能分支func1進行相關(guān)功能的開發(fā)，開發(fā)完后蝙斜，我需要先合并到develop上進行測試名惩，于是我切換到develop分支，將我的功能分支func1合并過去孕荠，合并完后娩鹉，會發(fā)現(xiàn)我的develop分支的配置文件，變成了publish的配置文件稚伍，于是我需要再手動的將這些變化改過來底循，這很明顯不是我們想要的結(jié)果，在講究時間成本的開發(fā)環(huán)境下槐瑞，這樣做無異于浪費熙涤。
如何在分支合并的時候，忽略掉一些指定的文件不讓它們發(fā)生合并呢困檩。
網(wǎng)上搜了一下祠挫，發(fā)現(xiàn)也有很多前輩遇到類似的問題，比如這篇文章悼沿，大致的做法就是通過gitattribute方法：
- 在你的工程目錄下創(chuàng)建
.gitattribute文件等舔，然后在其中寫入你想要忽略掉的文件，格式如下：
info.plist merge = ours
xxx.h merge = ours
//有多個的話糟趾，依次排列即可
- 執(zhí)行
git config merge.ours.driver true即可慌植。
網(wǎng)上的很多文章到此就為止了，然而這樣并不夠义郑。
由于開發(fā)的時候蝶柿，功能分支一定都是從publish分支出來，并且只存在publish分支（包括功能分支）合并到develop和simuluate分支的情況非驮，因此我們只需要保證publish分支（包括功能分支）向別的分支合并時交汤，別的分支的配置文件不會覆蓋掉就可以了。
現(xiàn)在如果我們在publish分支下創(chuàng)建了gitattribute文件劫笙，并在里面按照上面的方法對info.plist文件進行合并忽略設(shè)置芙扎。然后我們從publish環(huán)境分出develop與simulute分支星岗，并對dev與sim分支的plist文件進行修改，此時我們將publish分出來的功能分支func1往另外兩個分支合并的時候沒有問題戒洼，不會發(fā)生覆蓋俏橘。可是當(dāng)我們改變了publish分支下info.plist文件的任何一處后圈浇，再將publish（包括從其中分出來的功能分支）合并到別的分支的時候寥掐，info.plist文件又會被覆蓋掉。這個方法貌似就失效了汉额。
困惑了很久后曹仗，最終在stackoverflow和同事的幫助下，找到了答案蠕搜，發(fā)現(xiàn)這真是一個隱藏的坑怎茫，原來gitattribute方法生效是有條件的，跟文件的修改順序有關(guān)系妓灌，只有先修改的往后來修改的合并的時候才會生效轨蛤。這里的先后是指文件的最后修改時間，不是創(chuàng)建的時間虫埂，如果最近修改過祥山，那它就是最新的，比如剛才的例子掉伏，我們修改了publish分支的info.plist缝呕，而沒有對另外兩個分支下的info.plist進行修改，那么publish分支下的info.plist就比另外兩個分支新斧散，這時候合并的時候供常，gitattribute就會失去作用，那么該如做呢鸡捐，我們在修改完publish分支后栈暇，需要再次修改另外兩個分支下的plist配置文件，即使沒啥可以改的箍镜，也要改(可以先改錯源祈，再改回去)這樣我們publish分支下的，就會仍然保持最舊色迂。
方法比較繁瑣香缺，但確實有效。
