blocks|key|994999|text|简单的回答是，永远不要合并分支。事实上，你根本不需要合并它们，只需从开发(也称为"master")合并到部署，即可合并修复和通用更改。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|995000|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Quick answer is, don't ever merge the branches. In fact you don't need to merge them at all, just merge from development (aka "master") to deployment to merge fixes and generic changes.

blocks|key|265478|text|2021年2月更新:+Git本身仍然不是一个很好的选择，但GitHub+Action+environment+could+help。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|265479|2009年:我不确定Git是否就是这样使用的。|265480|首先是一个快速的Linus+advice，总是“多姿多彩”和信息量大;)|265481|265482|+Git从根本上跟踪项目状态，而不是文件状态。这意味着你不能尝试“合并一个文件”。这在git中是一个没有意义的操作，事实上，任何允许它的SCM都注定是一小块sh*t+(*)。|blockquote|265483|265484|(*)我并不是因为git不能做到这一点就这么说。它远比这更基础。一旦你开始做每个文件的分支和合并，你基本上就搞砸了自己，你再也不能把这个项目作为一个“整个项目”来工作了--你不再有一个明确定义的历史，实际上就是整个项目的历史。|265485|265486|265487|那里。|265488|也就是说，你可以：|265489|使用单独的GIT子项目来管理这些配置/文档文件(注意：use+of+submodules+has+been+discussed+here)|265490|or记录部分合并(对我们不想合并的文件使用“”策略)，然后--对其进行修改。|unordered-list-item|265491|265492|265493|此线程中的其他解决方案涉及在部署服务器上处理“特定于服务器”的分支|265494|Development++++++++Deployment

#origin/master:
x--x+++++++++++++++$+git+clone

+++++++++++++++++++#+master
+++++++++++++++++++x--x

+++++++++++++++++++$+git+checkout+-b+deployment+origin/master

+++++++++++++++++++x--x
+++++++++++++++++++++++\+
++++++++++++++++++++++++--+#deployment

+++++++++++++++++++$+....+#makes+changes+for+config+files
++++++++++++++++++++++++++#or+other+specific+deployment+files

+++++++++++++++++++x--x
+++++++++++++++++++++++\
++++++++++++++++++++++++--d1--d2+#+no+need+to+push+that+branch+ever.

#new+developments
x--x--x--x

+++++++++++++++++++$+git+pull+--rebase+#pull+origin/master+and+
+++++++++++++++++++++++++++++++++++++++#replay+current+branch+on+top+of+it
+++++++++++++++++++x--x--x--x
+++++++++++++++++++++++++++++\
++++++++++++++++++++++++++++++--d1'--d2'+#SHA1+rewritten+in+deployment+branch
+++++++++++++++++++++++++++++++++++++++++#not+important+since+this+branch+
+++++++++++++++++++++++++++++++++++++++++#is+not+pushed+(published)|code-block|syntax|javascript|265495|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/66248867/6309|1|http://www.gelato.unsw.edu.au/archives/git/0701/37960.html|2|http://markmail.org/message/emzectaqyfdeqmeu^0|T|10|0|0|0|8|C|1|0|0|0|0|0|0|0|0|0|R|15|2|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1K|8|@]|9|@$A|1L|B|1M|1|1N]]|C|$]]|$1|D|3|E|5|6|7|1O|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1P|8|@]|9|@$A|1Q|B|1R|1|1S]]|C|$]]|$1|H|3|-4|5|6|7|1T|8|@]|9|@]|C|$]]|$1|I|3|J|5|K|7|1U|8|@]|9|@]|C|$]]|$1|L|3|-4|5|6|7|1V|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|1W|8|@]|9|@]|C|$]]|$1|O|3|-4|5|6|7|1X|8|@]|9|@]|C|$]]|$1|P|3|-4|5|6|7|1Y|8|@]|9|@]|C|$]]|$1|Q|3|R|5|6|7|1Z|8|@]|9|@]|C|$]]|$1|S|3|T|5|6|7|20|8|@]|9|@]|C|$]]|$1|U|3|V|5|6|7|21|8|@]|9|@$A|22|B|23|1|24]]|C|$]]|$1|W|3|X|5|Y|7|25|8|@]|9|@]|C|$]]|$1|Z|3|-4|5|6|7|26|8|@]|9|@]|C|$]]|$1|10|3|-4|5|6|7|27|8|@]|9|@]|C|$]]|$1|11|3|12|5|6|7|28|8|@]|9|@]|C|$]]|$1|13|3|14|5|15|7|29|8|@]|9|@]|C|$16|17]]|$1|18|3|-4|5|6|7|2A|8|@]|9|@]|C|$]]]|19|$1A|$5|1B|1C|1D|C|$1E|1F]]|1G|$5|1B|1C|1D|C|$1E|1H]]|1I|$5|1B|1C|1D|C|$1E|1J]]]]

Update Feb. 2021: Git itself is still not a good fit, but <a href="https://stackoverflow.com/a/66248867/6309">GitHub Action environment could help</a>.
2009: I am not sure Git is meant to be used this way.
First a quick <a href="http://www.gelato.unsw.edu.au/archives/git/0701/37960.html" rel="nofollow noreferrer">Linus advice</a>, always &quot;colorful&quot; and informative ;)
<blockquote>
Git very fundamentally tracks project state, not file state. Which means that you very much can NOT try to &quot;merge a file&quot;. It is a senseless operation in git, and in fact, any SCM that allows it pretty much is doomed to be a total piece of sh*t (*).
(*) And I'm not saying that just because git doesn't do it. It's much more fundamental than that. Once you start doing per-file branching and merging, you've basically screwed yourself, and you'll never be able to work on the project as a &quot;whole project&quot; any more - you no longer have a well-defined history that actually is the history of the whole project.
</blockquote>
<hr />
There.
That said, you could:
<ul>
<li>manage those config/doc files a separate git sub-projects (note: the <a href="http://markmail.org/message/emzectaqyfdeqmeu" rel="nofollow noreferrer">use of submodules has been discussed here</a>)</li>
<li>or record partial merge (using &quot;ours&quot; strategy for files we don't want to merge), then --amend it.</li>
</ul>
<hr />
Other solutions in this thread involve working on a &quot;server-specific&quot; branch on your deployment server
<pre><code>Development Deployment

#origin/master:
x--x $ git clone

 # master
 x--x

 $ git checkout -b deployment origin/master

 x--x
 \ 
 -- #deployment

 $ .... #makes changes for config files
 #or other specific deployment files

 x--x
 \
 --d1--d2 # no need to push that branch ever.

#new developments
x--x--x--x

 $ git pull --rebase #pull origin/master and 
 #replay current branch on top of it
 x--x--x--x
 \
 --d1'--d2' #SHA1 rewritten in deployment branch
 #not important since this branch 
 #is not pushed (published)
 
 
</code></pre>

blocks|key|3482181|text|如果你想保持你的历史记录良好，你可以将部署文件保存在你的干净分支之上的一些提交中。然后，当需要部署新版本时，您可以查看部署分支和'git+rebase+master'，将这些提交放在原始分支之上。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3482182|这样，您还可以轻松地更改配置文件，并使用'git+commit+--amend‘更改顶部提交。|3482183|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you want to keep your history nice, you can keep the deployment files in some commits on top of your clean branch. Then, when it's time to deploy a new version, you check out the deployment branch and 'git rebase master', to put those commits on top of the original branch.

That way, you can also make easy changes to the configuration files, and change the top commit with 'git commit --amend'.

blocks|key|4329246|text|我做了一些愚蠢的把戏，比如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4329247|让应用程序向repository|4329248|Have读取文件config|unordered-list-item|offset|length|style|CODE|4329249|
|4329250|Add+config.development和config.production，但不是config。您的部署脚本不仅可以克隆存储库，还可以克隆cp+config.production+config|4329251|4329252|这有什么意义吗？|4329253|它对我来说没问题。|4329254|entityMap^0|0|0|8|6|0|0|4|I|N|H|18|6|20|R|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|X|8|@$G|Y|H|Z|I|J]]|9|@]|A|$]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|11|8|@$G|12|H|13|I|J]|$G|14|H|15|I|J]|$G|16|H|17|I|J]|$G|18|H|19|I|J]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1B|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1C|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|U|$]]

I do some silly tricks like:

<ul>
<li>Have the app read file <code>config</code></li>
<li>Add <code>config.development</code> and <code>config.production</code> but not <code>config</code> to the repository</li>
<li>Have your deploy script not only clone the repository, but also then <code>cp config.production config</code></li>
</ul>

Does that make any sense?

It works okay for me.

blocks|key|3482302|text|目前，我有几个签入的补丁文件，构建服务器将这些补丁应用于相关版本。不过，我现在还在重新考虑|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3482303|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

currently i have a couple of patch files checked in, and the build server applies those patches for the relevant versions. though i'm having second thoughts about it at the moment

blocks|key|4329344|text|我之前提到过补丁文件。我现在已经放弃了这一点，而是维护部署分支。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4329345|也就是说，我使用名为'+master+-deployed‘的新分支分支master，并在该分支上进行更改，我只需要在构建服务器上的测试版本中进行更改(即添加一个警告，表明这不是活动版本，并且在web.config中使用不同的数据库服务器)。|4329346|在构建前沿版本时，构建服务器会签出master-deployed，并在执行通常的构建之前将其重新设置为原始/主版本。如果没有人做任何冲突的更改，那么一切都很好。如果他们有，那么我看不到任何系统在没有人工干预的情况下处理这个问题。|4329347|tip+of+qa也是如此，它有一个分支'qa-deployed‘|4329348|我使用--+it标志来确保如果整个分支被重写，那么补丁不会接受所有的旧提交。|4329349|因此，在构建服务器上，qa构建如下所示|4329350|git+reset+--hard
git+clean+-xfd
git+checkout+-f+qa-deployed
git+rebase+--onto+qa+HEAD%5E+qa-deployed
build-script|code-block|syntax|javascript|4329351|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|W|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|X|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|Y|8|@]|9|@]|A|$O|P]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I mentioned earlier patch files. I've gone off this now, and instead maintain deployment branches.

ie, I branch off master with a new branch named 'master-deployed', and make changes on that branch that I need to be only in the test version on the build server (i.e. adding a warning that this is not the live version, and different db server in web.config).

The build server when building the bleeding edge version then checks out master-deployed, and rebases it onto origin/master before performing the usual build. If no-one has made any conflicting changes then everything is fine. If they have then I can't see any system handling this without manual intervention.

Same goes for tip of qa, which has a branch 'qa-deployed'

I use the --onto flag to make sure if a whole branch is rewritten then the patch doesn't take all the old commits with it.

So on the build server the qa build looks something like

<pre><code>git reset --hard
git clean -xfd
git checkout -f qa-deployed
git rebase --onto qa HEAD^ qa-deployed
build-script
</code></pre>

blocks|key|4329396|text|我遇到了类似的问题，并创建了一个名为config-magic的小项目来帮助管理此问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4329397|Config-magic允许您创建模板conf文件，然后为每个dev/staging/production创建数据配置文件。然后运行"cfg+dev“来生成"dev”配置文件，运行"cfg+staging“来生成登台配置，等等。|4329398|然后我将其与脚本绑定在一起，这样当我部署到staging时，我在本地运行"cfg+staging“，然后在从git更新代码库之后对所有配置文件执行scp。|4329399|“实际的”配置文件被设置为被git忽略。到目前为止，这对我来说工作得很好。|4329400|https://github.com/apinstein/config-magic/tree|offset|length|4329401|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|0|1A|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|W|8|@]|9|@$J|X|K|Y|1|Z]]|A|$]]|$1|L|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|I]]]]

I had a similar problem and created a tiny project called config-magic to help manage this.

Config-magic lets you create template conf files and then profiles of data for each of dev/staging/production. You then run "cfg dev" to produce the "dev" config files, "cfg staging" to produce the staging config, etc.

I then have this wired up with scripts, so that when I deploy to staging, I locally run "cfg staging" then scp over all of the config files after updating the codebase from git.

The "actual" config files are set to be ignored by git. This has worked really well for me so far.

<a href="https://github.com/apinstein/config-magic/tree" rel="nofollow noreferrer">https://github.com/apinstein/config-magic/tree</a>

blocks|key|3482447|text|这对我来说很有效，而且我只做了很小的配置更改就可以部署(配置文件中有3行)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3482448|3482449|从GitHub或您保存存储库的任何位置克隆存储库。运行git+checkout+-b+deployment+origin/master.|ordered-list-item|offset|length|style|CODE|3482450|Make您的更改(如果您like).|3482451|Whenever您的主分支(或进行部署的任何分支)有您想要部署的更改，则推送它们)，只需git+pull+--rebase.|3482452|+|3482453|unordered-list-item|3482454|3482455|这是一个简单的解决方案，它对我来说肯定是有效的，我不知道它是不是像其他人建议的那样是"shi*t“，但它对我们的目的肯定是非常有用的。|3482456|entityMap^0|0|0|R|14|0|0|18|H|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Y|8|@$F|Z|G|10|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|11|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|12|8|@$F|13|G|14|H|I]]|9|@]|A|$]]|$1|N|3|O|5|6|7|15|8|@]|9|@]|A|$]]|$1|P|3|-4|5|Q|7|16|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|18|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|V|$]]

This works for me, and I make only minor configuration changes to deploy (3 lines in config files).

<ol>
<li>Clone your repository from GitHub or wherever you keep it. To where you wish to deploy.</li>
<li>Run <code>git checkout -b deployment origin/master</code>.</li>
<li>Make your changes (push them if you like).</li>
<li>Whenever your master (or whatever branch you made the deployment from) has changes you want to deploy, simply <code>git pull --rebase</code>.</li>
</ol>

It's a simple solution and it certainly works for me, I can't speak to wether or not it this makes it "shi*t" as others suggest, but it is certainly very useful for our purposes.

blocks|key|3482494|text|我正在考虑所有这些针对我的情况的解决方案，但它们似乎都不适用。我在我的实时服务器和开发服务器上都进行编辑。如果您不需要重新发布分支，那么Rebase工作得很好，但我会在部署分支上进行更改，并将这些更改发布回主存储库。只有当您的文件位于单独的子目录中时，子模块方式才有效，而我的配置文件则位于多个位置。合并我们的方法也不能很好地工作，因为我必须先拉出分支，然后再拉大的分支。如果仍然存在合并它们的分支，并且我可以在需要时拉入适当的配置分支，那么它可能会起作用。现在.gitignore可以工作了，我只需要手动上传文件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3482495|在做了更多的研究之后，我找到了我的解决方案:在活动站点上不使用git代码库，而是使用临时站点将最新的更改通过临时/实时配置文件拉到我的分支中。然后通过git存档部署，并将文件解压缩到我的实时站点上。|3482496|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I was thinking about all of these solutions for my situation but none of them seem to apply. I edit both on my live and development servers. 
Rebase works well if you dont need to republish that branch, but I make changes on my deployment branch and publish those back to the main repository. 
The submodule way only works if your files are in a seperate subdir, my config files are in several places. 
The merge ours method wouldnt work so well also since i'd have to pull that branch first and then the big branch. 
Maybe it would work if there was still a merge theirs and I could pull in the proper configuration branch when needed. 
For now a .gitignore works and I just manually upload the files.

After doing more research I've found my solution to not have a git repo on the live site but use a staging site to pull the latest changes into my branch with the staging/live config files. and then deploy by git archive and extracting the files onto my live site.

blocks|key|999977|text|樱桃-pick似乎可以解决这个问题(代价是有点污染日志)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|999978|git签出-b测试进行更改并提交git签出主进程git签出-b部署进行更改并提交git签出主进程|999979|在master和git+cherry-pick测试或git+cherry-pick下执行所有操作，以应用从当前系统切换到测试或部署版本所需的差异。|999980|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

cherry-pick seems to work for this for this (at the expense of polluting the logs a bit).

git checkout -b testing
make changes and commit
git checkout master
git checkout -b deploy
make changes and commit
git checkout master

do everything under master and 
git cherry-pick testing or git cherry-pick deploy to apply the diffs needed to switch from the current system into the testing or deployment version.

blocks|key|265968|text|这很简单，也很干净。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|265969|您将创建一个部署分支，如下所示：|265970|>+git+checkout+deployment-1234|code-block|syntax|javascript|265971|现在，您可以进行特定于部署的更改。一旦完成，就提交它：|265972|>+git+commit+-as|265973|返回到您的主分支。|265974|>+git+checkout+master|265975|立即合并部署分支。这将使用那些特定于部署的更改来修改您的主分支，但不要担心，我们将恢复它。|265976|>+git+merge+--no-ff+deployment-1234|265977|要恢复更改，只需在合并之前签出文件，并使用amend提交。|265978|>+git+checkout+HEAD%5E+.
>+git+commit+--amend|265979|就这样。现在，git认为文件在第一次提交deployment-1234时发生了变化，这是主服务器已经考虑过的，并且被发现是不合适的。因此，即使您尝试将整个deployment-1234分支合并到master，它也永远不会将这些更改添加到master分支中。(试试看！)|265980|我还在需要更好控制的项目中使用了另一种方法。上面的缺点是，您可能会在将来从deployment-1234合并到master的过程中产生冲突。如果这些合并是手动的，这是可以的。但如果您需要自动合并，最好是我能防止这种系统冲突。因此，我创建了一个可以应用和撤消特定于部署的更改的脚本。然后，更改本身不需要在存储库中，而是出现在存储库中的是该脚本。|265981|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|16|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|17|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|18|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|19|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|1A|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|1B|8|@]|9|@]|A|$]]|$1|S|3|T|5|F|7|1C|8|@]|9|@]|A|$G|H]]|$1|U|3|V|5|6|7|1D|8|@]|9|@]|A|$]]|$1|W|3|X|5|F|7|1E|8|@]|9|@]|A|$G|H]]|$1|Y|3|Z|5|6|7|1F|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1G|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|13|$]]

That's easy and clean.

You'd create a deployment branch like:

<pre><code>&gt; git checkout deployment-1234
</code></pre>

Now you can make the deployment specific changes. Once that is done, commit it:

<pre><code>&gt; git commit -as
</code></pre>

Go back to your master branch.

<pre><code>&gt; git checkout master
</code></pre>

Immediately, merge the deployment branch. This will modify your master branch with those deployment-specific changes, but don't worry, we will revert it.

<pre><code>&gt; git merge --no-ff deployment-1234
</code></pre>

To revert the changes, just checkout the files before the merge and commit it with amend.

<pre><code>&gt; git checkout HEAD^ .
&gt; git commit --amend
</code></pre>

That's it. Now git treats that the file changes in the first commit of deployment-1234 as already considered by the master and found to be unsuitable. So it will never add those changes to the master branch even if you try to merge the whole deployment-1234 branch to master. (Try it!)

I also use another method in a project that requires better control. The bad thing of the above is that you might create a conflict during a future merge from deployment-1234 to master. That is okay if those merges are manual. But if you need automatic merges, it is better if I can prevent this systematic conflict. So instead, I created a script that can apply and undo the deployment-specific changes. Then the changes themselves do not need to be in the repository, instead what appears in the repo would be that script.

I'm using git for a PHP project, I think it's really handy. There is one thing that would be great if I get it to work.

I have created a branch, meant for deployment. It has some differences, like different configuration files and documentation.

I can't just ignore them, because then they will stay in both branches, while I would like to keep them different in both branches. 

The problem is that when I merge the branches, those files that are meant to be different are merged too. 

Is there any convenient way to accomplish such a thing? How is this normally done?

How to realise a deployment branch in Git

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在为一个PHP项目使用git，我认为它真的很方便。如果我能让它工作，有一件事会很棒。我已经创建了一个分支，用于部署。它有一些不同之处，比如不同的配置文件和文档。我不能忽略它们，因为这样它们就会留在两个分支中，而我想让它们在两个分支中保持不同。问题是，当我合并分支时，那些本应不同的文件也会被合并。有没有什么方便的方法...

问如何在Git中实现部署分支
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在Git中实现部署分支EN