戰魂小筑

受盡svn各種折磨的小伙伴都聽說過git. 但是網上一搜索, 本來打算跟svn一樣. 下一個服務器, 裝下就可以開始用了.

沒想到啊, 沒想到. 居然需要Linux天賦點…

好吧, 拜鳥哥門下把Linux上手了吧, 剛開始搭git, 靠. 又需要公鑰和各種輔助軟件.

傷不起啊

很多小伙伴們, 自此繼續沉默的繼續使用svn

我們沒有放棄, 我們找到了簡(shan)易(zhai)搭建法

先看療效:

1. 無需公鑰

2. 只需要幾個最常用的Linux命令就可以搭建

看步驟

1. 準備Linux服務器, 安裝好git(一般都是默認裝好的)

2. 命令行操作

useradd git   #創建一個git賬號

passwd git    #設置git賬號的密碼

su – git    #切換到git賬號

cd ~  #轉到用戶目錄

mkdir 項目名稱.git   #建立項目git文件夾

cd 項目名稱.git

git –-bare –share init   #初始化git庫

3. 馬上拿起你的git客戶端( 烏龜, SourceTree均可)輸入這樣格式的地址git@ip:/path/to/project.git

例如: git@192.168.1.2:/home/git/YourProject.git

git pull時, 需要輸入密碼, 就輸入上面創建好的git賬號的密碼就可以

開始使用吧!

Tips

這種方法搭建的git服務器僅限于小團隊和對貢獻代碼不敏感的項目而生

git本身的公鑰是為了防止別人偽造用戶名進行虛假提交. 但這個方法繞開了這點

想開新的git庫時, 切記使用git賬號去重復以上步驟, 若使用root級別賬號創建的文件夾使用客戶端時會遇到權限不足的提示

滿打滿算, 從好友推薦Golang至發文時, 使用Golang已經有1年多了. 這種時間對于C/C++ Java這些老者來說, 簡直是菜鳥級別的經驗

但作為新生代語言的特點就是實戰. Golang這一年里, 已經為項目提供了穩定的服務器和強大的擴展能力, 與客戶端的Unity3D里的C#一樣, 都是強大, 極致開發效率代表的優秀開發語言.

用途篇

Golang到底拿來做啥? 我需要么?

高效(性能,開發)的服務器語言. 包括Web, 游戲, App

編寫桌面級UI暫不是很適合

我需要把現在的C++, Python, Erlang等服務器改成Golang么?

性能有瓶頸, 開發效率低, 有錢有時間的話, 完全可以

評價篇

聽過太多的人對Golang的評價, 大概分為這么幾類:

C/C++性能黨

此類黨員對任何事物都追求極致的 性能. 還好Golang是直接生成native code, 否則會被批的體無完膚. 但是由于Golang底層為并發和開發效率而做出的一些系統, 類似于GC, 調度器和分配器等, 會在語言層上損失很多性能. 因此C/C++黨還是有理由批Golang性能低下

Erlang并發黨

作為電信級元老, Erlang的模型和架構當之無愧, OTP擴展性超級強. 完美的Actor模型也讓邏輯編寫比OO更加直觀

CSP與Actor區別僅僅只是在channel的歸屬范圍而已, 但這點細微差別卻對兩種語言的開發變的迥然不同

Golang在并發模型上選擇了CSP, 就是考慮把架構的設計留給使用者. 像C#一樣建立一個類庫的世界, 而不是MFC一樣的框架世界. 讓開發更自由

Erlang的Actor也沒錯. 讓開發更直觀, 讓崩潰提前來到, 盡快處理

Rust黨

Rust在發文時已經發布了1.0. 這讓R粉興奮的穿梭于各大技術論壇和討論群

但Rust的理念在我看來有點偏執了, 一定要把各種錯誤在編譯期暴露出來, 所以造出了很多不需要的類型和概念, 連語言都比C語言更符號話

大白話說來, 有點編程經驗的人看到JavaScript完全看得懂, 但看Rust卻像天書

對比同時期的TypeScript, Dart, Swift. Rust就是有點那么獨辟蹊徑

該黨黨員經常性的用各種特性對比Golang, 追求單特性的優秀.

但其實, Golang本身是一門完整哲學. 很多語言特性互相之間有關聯. 有設計不當的地方, 當然更多的是完整體系. 不求和其他語言比

只追求解決問題的速度

自定義黨

云風看過Golang后, 因為該語言本身就是強化版的C, 因此頗受云風喜歡. 但在一堆評價后, 云風還是果斷選擇了C+lua的組合寫出的Skynet

雖然不知道原因, 但我猜的話, 畢竟是對語言本身的可控性還不那么看好

同時, 我們發現Skynet使用的是Actor模型, 也發現大神級的程序員就是有先見.

轉載請注明: 戰魂小筑http://www.shnenglu.com/sunicdavy

感觸篇

設計

踏入Golang, 就不要嘗試設計模式

傳統的OO在這里是非法的, 嘗試模擬只是一種搞笑

把OO在Golang里換成復合+接口

對實現者來說, 把各種結構都復合起來, 對外暴露出一個或多個接口, 接口就好像使用者在實現模型上打出的很多洞

別怕全局函數, 包(Package)可以控制全局函數使用范圍.

沒必要什么都用interface對外封裝, struct也是一種良好的封裝方法

Golang無繼承, 因此無需類派生圖. 沒有派生這種點對點的依賴, 因此不會在大量類關系到來時, 形成繁雜不可變化的樹形結構

容器

用了很長時間map, 才發現Golang把map內建為語言特性時, 已經去掉了外置型map的api特性. 一切的訪問和獲取都是按照語言特性來做的, 原子化

數組可以理解為底層對象, 你平時用的都是切片, 不是數組, 切片就是指針, 指向數組. 切片是輕量的, 即便值拷貝也是低損耗的

內存

Golang在實際運行中, 你會發現內存可能會瘋漲. 但跑上一段時間后, 就保持穩定. 這和Golang的內存分配, 垃圾回收有一定的關系

現代的編程語言的內存管理不會很粗暴的直接從OS那邊分配很多內存. 而是按需的不斷分配成塊的內存.

對于非海量級應用, Golang本身的內存模型完全可以撐得下來. 無需像C++一樣, 每個工程必做內存池和線程池

Channel

Channel和鎖誰輕量? 一句話告訴你: Channel本身用鎖實現的. 因此在迫不得已時, 還是盡量減少使用Channel, 但Channel屬于語言層支持, 適度使用, 可以改善代碼可讀寫

轉載請注明: 戰魂小筑http://www.shnenglu.com/sunicdavy

錯誤

覺得Golang不停的處理err? 那是因為平時在其他語言根本沒處理過錯誤, 要不然就是根部一次性try過所有的異常, 這是一種危險的行為

panic可以被捕獲, 因此編寫服務器時, 可以做到不掛

危險的interface{}

這東西就跟C/C++里的void*一樣的危險, nil被interface{}包裹后不會等于nil相等, 但print出來確實是nil

模板估計可以解決容器內帶interface{}的問題. 但新東西引入, 估計又會讓現在的哲學一些凌亂

轉載請注明: 戰魂小筑http://www.shnenglu.com/sunicdavy

初學Tips

語言學習按照官網的教學走, 跑完基本就會了

下載一個LiteIDE, 配合Golang的Runtime,基本開環境就有了

Golang的類庫設計方式和C#/C++都不同, 如果有Python經驗的會感覺毫無違和感

有一萬個理由造輪子都請住手, 類庫里有你要的東西

寫大工程請搜索: Golang項目目錄結構組織

Golang語言本身本人沒有發現bug, 即便有也早就被大神們捉住了. 唯一的一個感覺貌似bug的, 經常是結構體成員首字母小寫, 但是json又無法序列化出來…

慎用cgo. 官方已經聲明未來對cgo不提供完整兼容性. 任何一門語言在早期都需要對C做出支持, 但后期完善后的不兼容都是常態

轉載請注明: 戰魂小筑http://www.shnenglu.com/sunicdavy

一直對各類編程語言中的字符串底層實現的差異感興趣. 最近在知乎上提了一個問題
總結起來, 在腳本里常用的一種字符串處理方法稱之為 字符串駐留技術(String interning).
此技術主要為了節約內存, 提高訪問, 操作效率. 這里拿lua來說, lua中低于40個字節的字符串駐留在全局hash表中, 大于40個字符的字符串單獨有一個表. 這么處理可以提高cache命中幾率. 但核心的關鍵是, 字符串的入庫都要進行hash化處理, 這個比較耗時. 但入庫后, 字符串之間的變量賦值只限于字符串引用, 還是唯一的一個引用, 字符串比較也是基于整數級別, 效率很高

一些鏈接
蔣金楠（Artech）博客園中C#的例子
http://www.cnblogs.com/artech/archive/2007/03/04/663728.html

C#微軟官方的例子
https://msdn.microsoft.com/en-us/library/system.string.intern(v=vs.110).aspx

本文介紹游戲服務器的性能分析, web服務器性能分析不在本文分析范疇之內

Golang編寫的服務器可以方便的通過內建性能分析, 輸出圖表仔細查找原因, 非常的方便, 如下圖

1. 獲取一個性能分析的封裝庫

   go get github.com/davecheney/profile

   2. 在工程內import這個組件    

3. 在main中添加啟動和停止入口

func main() {
    defer profile.Start(profile.CPUProfile).Stop()
 
    // ... your main code here ...
}

4. 重新編譯工程, 運行

5. 注意觀察啟動后, 命令行里的字段, 類似于

2013/08/08 16:45:58 profile: cpu profiling enabled, /tmp/profile882806532/cpu.pprof

后面的路徑就是pprof性能分析文件的位置, 啟動機器人進行多次服務器測試用例, 停止機器人, Ctrl+C中斷服務器

  6.將cpu.pprof拷貝到你的游戲exe所在位置

  7.下載并安裝Graphviz, 這是將分析數據變成上圖的圖形化工具

  8.調用Graphviz制作文檔

 go tool pprof --pdf gamesvc.exe cpu.pprof > report.pdf

如果dot沒有找到, 可以在執行前添加路徑

set path==%path%;"c:\Program Files (x86)\Graphviz2.38\bin"

golang的time.Format設計的和其他語言都不一樣, 其他語言總是使用一些格式化字符進行標示, 而golang呢, 查了網上一些坑例子 自己查了下golang的源碼, 發現以下代碼

// String returns the time formatted using the format string
//  "2006-01-02 15:04:05.999999999 -0700 MST"
func (t Time) String() string {
    return t.Format("2006-01-02 15:04:05.999999999 -0700 MST")
}

嘗試將2006-01-02 15:04:05寫入到自己的例子中

func nowTime() string {
    return time.Now().Format("2006-01-02 15:04:05")
}

結果返回正確. 詢問了下, 據說這個日期是golang誕生的日子… 咋那么自戀呢…

SVN的工作流是checkout->modify->update->merge->commit, 如果多人修改同一個文件, 需要進行合并. 但對于Excel等復合文件格式, svn無法處理合并. 雖然云風嘗試處理過Excel合并的問題, 但其實對于我們日常開發來說, 并不太期望有些操作進行合并, 而是類似于VSS那種早期的代碼管理工具的鎖定行為. SVN依然有這個功能.

這里使用的是風靡世界的TortoriseSVN. 選中一個SVN管理下的文件, 點擊右鍵, 打開屬性

在New對話框中選中Needs-Lock

提交這個屬性修改.

現在我們的工作流的某些步驟變化了:

getlock->modify->commit

如果有他人在修改, getlock會失敗

getlock的原理與早期的VSS一致, 使用了文件只讀的屬性. 如果嘗試不getlock就修改文件, 那么文件最終無法保存!

準備:

在http://code.google.com/p/protobuf/下載protobuf-2.5版本

預備知識: 已經使用過protobuf, 熟練應用protobuf序列化在各語言間交互信息

目標: 獲取proto內容而無需手動解析proto文件

為proto文件添加更多的meta信息, 并在運行期獲取.

protoc編譯器準備

通過protobuf-2.5的源碼或者從官網下載, 可以獲得protoc的protobuf編譯器, 這個編譯器由C++編寫, 官方支持完整的protobuf特性. 編譯器默認支持C++, python和java 三種語言的代碼生成. 如需生成更多的語言, 可以通過官網的第三方頁面獲取.

protoc插件原理

但我們在日常使用中, 可能需要提取proto信息, 例如: 所有的枚舉,消息等信息, 字段名稱和導出號. 自己編寫詞法解析器來做是費力不討好的. 官方推薦的方法是使用protoc外掛插件來實現.

protoc的插件設計比較獨特, 不使用動態鏈接庫或者java的jar包導入方式, 而是直接使用了命令行來交換數據.查看protobuf源碼我們可以發現這樣一個文件:

protobuf-2.5.0\src\google\protobuf\descriptor.proto

這個文件描述了一個proto文件的格式, 消息組成及枚舉等完整信息. 這是一種自我描述的方法.

在找到這樣一個文件

protobuf-2.5.0\src\google\protobuf\compiler\plugin.proto

這樣一個文件描述: 插件如何與protoc進行交互的協議

protoc編譯器在給定指定proto文件及搜索路徑后, 將各種信息填充為descriptor.proto描述的結構后通過CodeGeneratorRequest消息系列化為二進制流后輸出到命令行. 插件只用捕獲protoc命令行輸出的二進制流, 序列化化回CodeGeneratorRequest即可獲得解析后的proto文件內容

這里需要注意的是: 插件可執行文件很有講究, 必須為protoc-gen-$NAME,  而且輸出文件名參數必須為--${NAME}_out

看一個栗子:

protoc.exe foo.proto --plugin=protoc-gen-go=..\tools\protoc-gen-go.exe --go_out foo.go --proto_path "."

這個栗子里: $NAME=go

protoc將foo.proto文件(搜索路徑為當前路徑)的內容通過命令行輸出給位于..\tools\的插件protoc-gen-go.exe,  輸出文件名字為 foo.go

descriptor.proto信息挖掘

我們注意到在descriptor.proto文件中包含有這樣的一個message: SourceCodeInfo, 這個消息體里有如下字段

optional string leading_comments = 3;
    optional string trailing_comments = 4;

這兩個字段對于我們獲取proto文件的meta信息尤為重要, 所謂的meta信息, 理解理解為C#語言中的attribute

這個attribute功能可以為一個字段, 一個消息擴充一些描述. 比如: 當一個字段通過反射顯示在gui上時, gui需要獲取這個字段的中文描述

那么只需要如下編寫

optional int32 somevalue = 1 //@ desc=”中文描述”

位于字段尾部的描述, 會被填充到SourceCodeInfo的 trailing_comments中, 而位于字段上方的字段, 會被填充到leading_comments中

SourceCodeInfo 并沒有直接掛載在message或者字段的附近, 而是通過其下的path字段來描述與字段的關系, 這是個極為麻煩的設計.

其原理如下:

假設我有如下一個message

message foo

{

     optional int32 v = 1;  // comments

}

要獲取v后的注釋, 對應的path為 4, 0, 2, 0

4 表示descriptor中message_type所在的序號,由于message_type對應的類型DescriptorProto是一個數組, 所以0表示foo是在FileDescriptorProto的message_type數組類型的索引為0;

如此類推: 2, 0 表示 v在DescriptorProto結構體的field成員序號為2的數組元素的索引為0

如果需要更多的參考, 可以獲取https://github.com/golang/protobuf

github.com\golang\protobuf\protoc-gen-go工程內有詳細代碼解析

最近發現, golang寫的游戲服務器, 在非調試狀態下, 一切正常, 但是在掛接gdb調試時, 無法收到網絡消息. 打了很多日志, 發現, 只要有goroutine的地方, 都沒有切換進入.

回想了下, goroutine的調度規則: 1.4之前, 在碰到syscall時, goroutine會被調度并處理. 1.4后, 只要有函數調用時, 均會進行一次調度. 密度比以前增加了, 更加接近真線程的處理.

根據這個原理, 問題應該出現在服務器底層沒有給系統提供調度機會的點上. 我們的服務器通過一個bool型的chan進行阻塞, 讓服務器維持阻塞進行消息處理不退出. 但是最近為了在windows下提供命令行支持, 增加了一些代碼, 如下

   1:  func WaitForExit() {

   2:   

   3:      if len(peerMap) == 0 {

   4:          log.Println("no peer running, exit!")

   5:          return

   6:      }

   7:   

   8:      // 命令行功能只在windows下啟用

   9:      if runtime.GOOS == "windows" {

  10:          reader := bufio.NewReader(os.Stdin)

  11:   

  12:          var running bool = true

  13:   

  14:          go func() {

  15:              select {

  16:              case <-exitChan:

  17:                  running = false

  18:              }

  19:          }()

  20:   

  21:          for running {

  22:              data, _, _ := reader.ReadLine()

  23:              command := string(data)

  24:   

  25:              dispatchConsoleCommand(command)

  26:          }

  27:      } else {

  28:          // Linux環境

  29:          <-exitChan

  30:      }

  31:   

  32:  }

我暫時屏蔽了新加的這套功能, 維持<-exitChan, 問題馬上解決

結合前面的猜測, 我估計在reader.ReadLine()函數內, 沒有給底層提供調度的機會, 導致其他goroutine無法運行, 造成服務器卡死

技術討論群:  309800774 歡迎golang愛好者加入, 純技術研討

編碼習慣及設計基礎

程序員修煉之道

http://product.dangdang.com/9053091.html

這本書講解的一些設計原理很實用, 對設計感興趣的同學可以一看

推薦指數: 5星

圖形渲染, 客戶端

3D繪圖程序設計

http://product.dangdang.com/20567144.html

推薦指數: 3星

Unity3D游戲開發

http://product.dangdang.com/22783514.html

雨松MOMO的早期Unity3D教學, 和他的網站一樣耐看

推薦指數: 4星

3D數學基礎:圖形與游戲開發

http://product.dangdang.com/9008571.html

這種書不適于通讀, 但必須備一本作為工具書
推薦指數: 3星

大型多人在線游戲開發

http://product.dangdang.com/9232417.html

這本書很坑, 根本就是torqure引擎的廣告. 對沒有游戲基礎的, 看了沒用, 對有經驗的是雞肋

推薦指數: -1星

精通Unreal引擎技術---關卡設計藝術

http://product.dangdang.com/20002907.html

坑, 虛幻一類的書籍, 基本都是美術看的, 程序若想了解虛幻的牛B技術, 切記不可買書

直接加群下源碼是最好的實踐

推薦指數: -2星

服務器

網絡游戲核心技術與實戰

http://product.dangdang.com/23450869.html

相當經典的服務器概念講解書籍, 服務器很多知識點很碎, 雖然這書是日本人寫的

但是依然適合國內服務器開發者一讀

推薦指數: 5星

Linux多線程服務器端編程(使用muduoC++網絡庫)

http://product.dangdang.com/23162953.html

當年編寫C++ boost.asio服務器時, 參考過陳碩大俠的muduo網絡庫, 設計的甚好

雖然他從事的是金融行業, 但是實戰經驗同樣值得游戲行業參考

這本書就是講解muduo網絡庫及其服務器設計理念

推薦指數: 4星

Unix環境高級編程

http://product.dangdang.com/9171119.html

Linux環境開發必看書籍

推薦指數: 5星

腳本篇

編譯原理

http://product.dangdang.com/20427584.html

龍書! 解析, 編程語言接觸必看的書籍, 可惜我不是計算機專業, 人家這都是專業教材

推薦指數: 3星

自制腳本語言

http://product.dangdang.com/23493730.html

日本人寫的基于java的腳本自動解析機, 全書沒有帶光盤, 硬是一點點把代碼轉成C#運行起來

理念很不錯, 可惜調試很痛苦, 還是不如yacc這些代碼生成的腳本代碼方便

但使用自動機完成BNF范式解析確實很漂亮, 同樣也可參考vczh輪子哥的發明

推薦指數: 3星

游戲腳本高級編程

http://product.dangdang.com/9220425.html

我把這本書叫做腳本黑書, 很基礎, 很簡單, 全程沒有一點編譯原理的講解, 全代碼實戰

龍書已經落灰, 但依然對編寫自己的腳本感興趣的同學, 可以一看

推薦指數: 5星

Lua程序設計

http://product.dangdang.com/20223814.html

這本是最經典的lua官方書籍, 沒有之一, 學lua必看

推薦指數: 5星

通用游戲編程及設計

游戲編程精粹系列

http://product.dangdang.com/20050227.html

到7以后就沒出了

早期這些書還是不錯的, 但由于游戲技術發展太快了, 所以有些概念現在看來已經落伍了

只是啟迪性游戲介紹, 很少有實例代碼, 啟發思路較好

推薦指數: 3星

游戲人工智能編程

http://product.dangdang.com/22872362.html

AI方面介紹比較專業的書籍, 讀過不后悔系列

推薦指數: 4星

游戲編程全接觸

http://product.dangdang.com/9092514.html#ddclick?act=click&pos=9092514_0_0_q&cat=&key=%D3%CE%CF%B7%B1%E0%B3%CC%C8%AB%BD%D3%B4%A5&qinfo=1_1_60&pinfo=&minfo=&ninfo=&custid=&permid=20141224141405640200098950074468429&ref=http%3A%2F%2Fwww.dangdang.com%2F&rcount=&type=&t=1419645619000&ver=A

技術方面比較細致的知識點, 讀過不后悔

推薦指數: 4星

面向對象的游戲開發

http://product.dangdang.com/9006047.html#ddclick?act=click&pos=9006047_0_0_q&cat=&key=%C3%E6%CF%F2%B6%D4%CF%F3%B5%C4%D3%CE%CF%B7%BF%AA%B7%A2&qinfo=2_1_60&pinfo=&minfo=&ninfo=&custid=&permid=20141224141405640200098950074468429&ref=http%3A%2F%2Fsearch.dangdang.com%2F%3Fkey%3D%25D3%25CE%25CF%25B7%25B1%25E0%25B3%25CC%25C8%25AB%25BD%25D3%25B4%25A5&rcount=&type=&t=1419645704000&ver=A

講解怎樣用面向對象的方法設計游戲, 架構設計向

推薦指數: 4星

3D游戲開發大全(高級篇)

http://product.dangdang.com/20072416.html#ddclick?act=click&pos=20072416_0_2_q&cat=&key=3D%D3%CE%CF%B7%BF%AA%B7%A2%B4%F3%C8%AB&qinfo=30_1_60&pinfo=&minfo=&ninfo=&custid=&permid=20141224141405640200098950074468429&ref=http%3A%2F%2Fproduct.dangdang.com%2F9006047.html&rcount=&type=&t=1419645726000&ver=A

推薦指數: 2星

全方位3D游戲設計--游戲引擎與游戲開發實例剖析

http://product.dangdang.com/9350357.html#catalog

當時買這本書是為了看MAX插件的

基本的引擎介紹和流程，較為簡單

推薦指數: 3星

游戲核心算法編程內幕

比較全面的游戲技術介紹

推薦指數: 2星

游戲架構與設計

http://product.dangdang.com/9032136.html#ddclick?act=click&pos=9032136_0_0_q&cat=&key=%D3%CE%CF%B7%BC%DC%B9%B9%D3%EB%C9%E8%BC%C6&qinfo=26_1_60&pinfo=&minfo=&ninfo=&custid=&permid=20141224141405640200098950074468429&ref=http%3A%2F%2Fsearch.dangdang.com%2F%3Fkey%3D%25D3%25CE%25CF%25B7%25D2%25FD%25C7%25E6%25D3%25EB%25D3%25CE%25CF%25B7%25BF%25AA%25B7%25A2%25CA%25B5%25C0%25FD%25C6%25CA%25CE%25F6&rcount=&type=&t=1419988281000&ver=A

國外游戲整體把控, 流程, 產品等

推薦指數: 2星

游戲開發技術發展的很快, PC還沒看完, 移動游戲技術已經走完了PC的歷程. 如果你有好的書籍, 可以在此推薦, 或者加入群討論: 309800774

Unity3D默認的asset格式都是二進制的, 比如說.anim .mat .prefab .unity 還有一些是文本格式, 比如.meta. 因此在菜單Edit->Project Settings->Editor里的Asset serialization模式是混合.

為了讓代碼管理工具能識別Unity3D的asset格式, 做出一些少量的合并及識別修改. 我們需要對Unity3D進行一些配置以適應代碼管理工具.以下是步驟:

Edit->Project Settings->Editor里按如下配置

在做出修改前, 請將之前的修改提交代碼管理

將選項設為紅框內的方式, 使用顯式Meta Files, 以避免在資源管理器里被被忽略的meta文件以及Asset文件使用文本格式

設定好后, 所有的資源將重新序列化, 將修改提交代碼管理工具

代碼管理工具不是玩能的, 也一定能很好的合并這些復雜文本格式. 因此我們在多人協作開發中需要遵守一些原則

1. 先獲取別人的更新, 運行無誤后再提交( 最基本的 )

2. 對有合并的asset格式, 盡量查看其修改過程, 詢問他人的修改與自己的修改差異(或者是git的3方合并)

3. 對合并錯誤的asset格式, 應及時修正, 手動合并, 切勿延誤并提交, 影響他人

參考鏈接: http://stackoverflow.com/questions/21573405/how-to-prepare-a-unity-project-for-git