工欲善其事，必先利其器。

前一陣子，公司的版本控制從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分支下的，就會仍然保持最舊。

方法比較繁瑣，但確實有效。