的Git大师和新科

之间分支合并冲突我有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，之前从未遇到过这种分支合并的情况。非常感谢你。

来源

2016-05-11 Saint Robson

你写了“这是它说什么”，但没有说出“它”是什么。 bitbucket上的一些网页操作？ – torek

@torek：是的，它= bitbucket。在分支菜单上。 –

我自己并没有使用bitbucket（当然，因为它是严格的Mercurial，并且我没有写信给它），但是似乎你需要首先运行'git fetch'，以便从中央repo通过bitbucket进入你的本地仓库，你可以在那里工作。 – torek

我通常使用的配置文件的一个解决方案是包含本地文件（如果存在），并且从版本控制中忽略它。

因此，假设您正在开发一个php项目，并且您的主分支中使用了默认配置文件。把它列入该项目的代码可能是这个样子：

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

现在，为了与当地的配置更改覆盖值，你可以当它首先存在的检查，然后再加载它之后覆盖值在默认配置文件中建立。

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

或者从版本控制忽略它，如果你肯定只合并来自master到beta，这是极不可能的特别是考虑beta分支的名字背后的含义，那么你可以提交config.local.php到beta分支在合并master到beta时，它不会发生冲突。但是请注意，如果您从beta合并为master，则此操作将完全突破并覆盖默认配置，这就是为什么我建议忽略.gitignore中的local配置文件。无可否认，跟上环境的具体差异是不是一个麻烦（是不是你首先选择版本控制系统的原因？），但是从这个例子你只需要改变db_name，这在我的经验中并不是那么重要。另外，您可以将此视为额外的奖励，以保护不打算在其他地方使用的证书的安全性，因此当您与团队共享此代码时，在版本控制中不跟踪它们是有意义的。

来源

2016-05-11 18:04:13

的Git大师和新科

回答

相关问题