2016-05-11 74 views
1

之間分支合併衝突我有2個服務器:example.com和example.net的Git大師和新科

,我有2個的Git分支:主機(example.com)和β(example.net)

現在,有一個在主分支中的文件名爲config.php其中包含數據庫的詳細信息:

$db_name : 'com_dbname'; 

當我創建beta分支,我需要改變這一行,因此它可以在example.net運行:

$db_name : 'net_dbname'; 

so,config.php現在每個分支都不同。現在兩個分支都已提交併推送到遠程存儲庫。

開發過程仍在主分支上繼續。我需要添加下$db_name一些行:

$db_name : 'com_dbname'; 
$other_var : 'other_value'; 

通常我可以合併到主分支測試在我到位桶帳戶。但由於此文件已更改,因此我無法將主合併到測試版分支中。這就是它說的:

這種合併有衝突,必須解決之後才能提交。 手動合併這些變化到測試運行以下命令:

$ git checkout 94c22fbaa758 
# Note: This will create a detached head! 
$ git merge remotes/origin/master 

,這裏是我的終端上的輸出:

Note: checking out '94c22fbaa758'. 

You are in 'detached HEAD' state. You can look around, make experimental 
changes and commit them, and you can discard any commits you make in this 
state without impacting any branches by performing another checkout. 

If you want to create a new branch to retain commits you create, you may 
do so (now or later) by using -b with the checkout command again. Example: 

    git checkout -b new_branch_name 

HEAD is now at 94c22fb... 

git merge remotes/origin/master 
Already up-to-date. 

我很困惑。它說一切都已經是最新的,但我仍然在我的bitbucket上看到1 commit behind master.,仍然無法將主控合併到測試版分支。

請親切地幫助我。我真的不知道如何解決這個問題,而且我在過去2個月前使用git,之前從未遇到過這種分支合併的情況。非常感謝你。

+0

你寫了「這是它說什麼」,但沒有說出「它」是什麼。 bitbucket上的一些網頁操作? – torek

+0

@torek:是的,它= bitbucket。在分支菜單上。 –

+0

我自己並沒有使用bitbucket(當然,因爲它是嚴格的Mercurial,並且我沒有寫信給它),但是似乎你需要首先運行'git fetch',以便從中央repo通過bitbucket進入你的本地倉庫,你可以在那裏工作。 – torek

回答

1

我通常使用的配置文件的一個解決方案是包含本地文件(如果存在),並且從版本控制中忽略它

因此,假設您正在開發一個php項目,並且您的主分支中使用了默認配置文件。把它列入該項目的代碼可能是這個樣子:

<?php 
include("config.php"); 

現在,爲了與當地的配置更改覆蓋值,你可以當它首先存在的檢查,然後再加載它之後覆蓋值在默認配置文件中建立。

<?php 
include("config.php"); 
if (file_exists("config.local.php")) 
    require_once("config.local.php"); 

或者從版本控制忽略它,如果你肯定只合並來自masterbeta,這是極不可能的特別是考慮beta分支的名字背後的含義,那麼你可以提交config.local.phpbeta分支在合併masterbeta時,它不會發生衝突。但是請注意,如果您從beta合併爲master,則此操作將完全突破並覆蓋默認配置,這就是爲什麼我建議忽略.gitignore中的local配置文件。無可否認,跟上環境的具體差異是不是一個麻煩(是不是你首先選擇版本控制系統的原因?),但是從這個例子你只需要改變db_name,這在我的經驗中並不是那麼重要。另外,您可以將此視爲額外的獎勵,以保護不打算在其他地方使用的證書的安全性,因此當您與團隊共享此代碼時,在版本控制中不跟蹤它們是有意義的。