需要GIT工作流程建议

发布于 2024-09-06 17:03:53 字数 2562 浏览 4 评论 0原文

过去几周我一直在研究 GIT，试图让我的团队的代码得到控制。不幸的是，我们使用的代码是一种专有语言，具有一些特性，这使我无法找到足够实用的工作流程来实现。不过，我可能并不了解 GIT 的所有功能，所以我向你们寻求建议。我将这篇文章分为三部分：1）我的文件怎么样； 2）到目前为止我们已经想到的工作流程； 3）我对未来的选择。

然后是我的文件；

正如我所说，这是一种专有的脚本语言，在代码本身中，您将找到有关配置（服务器、数据库和其他内容）的标签。我知道，这可能听起来很奇怪，但从技术上讲，这段代码是一个很大的复杂配置文件。好吧，它无法改变，暂时就这样吧。

我还有两个不同的环境：dev 和 prod，我想它的用途是显而易见的。由于代码的思考方式很奇怪，如果您将 dev 中的脚本与 prod 中的相同脚本进行比较，您会看到：

prod:

CodeCode += Code(0)
Code{1} ...
CodeConfig = "ConnectionToProducionDB"
SomeMoreGenericCode.doSomething()
(...)

并且在 dev 中，它看起来像：

CodeCode += Code(0)
Code{1} ...
CodeConfig = "GoToSomeDevDB"
SomeMoreGenericCode.doSomething()
(...)

这就是关于文件的事情。

现在，已经想到了什么；

乍一看，对我来说这似乎是一个经典的让其分支情况，所以我已经完成了。

[create a folder and init it]
[copy my code from production and add/commit it]
$ git checkout -b dev
[change these lines with 'CodeConfig' to the dev settings]
[go happy coding and commiting]

一段时间后，编码和测试完成，是时候合并到生产中了。那就是问题开始的时候。

一个简单的 git merge dev （来自我的 master 分支）将合并大部分代码，但配置也会传输到 master 分支，因为从 GIT 的 POV 来看，这是代码中的更新之一本身。虽然在这段简短的代码中这不会成为问题，但在实际情况下，我可能重新配置了十个或二十个源，并且一次回滚一个并不是一项令人愉快（也不可靠）的任务。

当然，当使用分支时，我确实希望能够合并我的代码，以保留我的提交历史记录和注释。我只需要以更定制的方式完成它......

我尝试了几种不同的方法来解决这个问题，但没有成功。看来 GIT 的合并对我来说太聪明了:(

例如，将 *.xml merge=Unset 放入我的 .gitattributes 文件中。或者将自定义合并驱动程序放入 ~/ 中。 gitconfig 试图导致自动合并失败（但不确定我是否正确）

我认为可能的解决方案；

正如我所说，我可能不知道 GIT 的所有功能，所以我的选择我很欣赏你的创新；）

我认为最简单的方法是禁用任何自动合并并手动完成所有操作（代码不是很大，我必须研究它）反正）。之后，我将创建一个简单的合并驱动程序，它将所有代码更改（不仅仅是冲突）传递给 WinMerge 或 Kdiff3 之类的东西，我可以在其中完成工作。不幸的是我还没有设法以这种方式得到它。

我的上一次尝试导致了冗长且不切实际的工作流程，但我将其写在这里，以便您可以了解我的目标。

init repo proj1
复制 prod 文件
首先添加/提交
$ git checkout -b dev
配置 dev 设置
代码/提交开发周期将
开发文件复制到 tmpDevDir
$ git checkout master
使用 WinMerge 将 tmpDevDir 与 proj1[masterbranch] 进行比较并仅应用所需的更改
commit proj1[masterbranch]
$ git merge dev
在需要的地方合并冲突
$ git diff HEAD HEAD^ 来查看合并结果并恢复合并的配置
$ git commit -am 'final commit for the production code'

好吧...不太好。

有人有更实用的工作流程或其他命令的想法来帮助解决这个问题吗？

非常感谢，

f。

原文

I have been studding GIT for the last couple of weeks in an attempt to get my team's code under control.
Unfortunately the code we work with is a proprietary language with some peculiarities which is keeping me from finding a practical enough workflow to be implemented. Still, I'm probably not aware of all GIT's capabilities so I ask you guys for suggestion. I will divide this post in three: 1) how are my files; 2)the workflow we've figured so far; 3)options I reckon for the future.

My Files then;

As I said this is a proprietary script language, in which within the code itself you will find tags regarding configurations (servers, DB's and other stuff). It might sound strange, I know, but technically this code is a big complex configuration file. Well, it can not be changed, for now lets just leave it.

I also have two different environments: dev and prod, and I guess it's uses are evident. Due the odd way the code is thought, if you compare the script in dev to the same one in prod you would see:

prod:

CodeCode += Code(0)
Code{1} ...
CodeConfig = "ConnectionToProducionDB"
SomeMoreGenericCode.doSomething()
(...)

And in dev it would look like:

CodeCode += Code(0)
Code{1} ...
CodeConfig = "GoToSomeDevDB"
SomeMoreGenericCode.doSomething()
(...)

That would be it regarding the files.

Now, what have been figured;

At first glance, it seemed for me a classical lets branch it situation and so I've done.

[create a folder and init it]
[copy my code from production and add/commit it]
$ git checkout -b dev
[change these lines with 'CodeConfig' to the dev settings]
[go happy coding and commiting]

After a while, coding and tests are done and it is time to merge into production. That's when the problem starts.

A simple git merge dev (from my master branch) will merge the codes mostly ok, but the configs will be also transferred to the master branch, as from GIT's POV this is one of the updates in the code itself. While in this short code it wouldn't be a problem, in the real situation I might have re-configured ten or twenty sources and rolling back one at time isn't quite a pleasant (nor a reliable) task.

Of course, when using branches I do want to be able to merge my code in order to keep my commit history and comments. I just need it to be done in a more customized way...

I have tried a couple different things to work this out, but had no success. Seems that GIT's merge is just too smart for me :(

For instance, *.xml merge=Unset into my .gitattributes file. Or a custom merge driver into ~/.gitconfig trying to cause the auto-merge to fail (not sure if I got that right though).

Possible solutions I thought;

As I said, I am probably not aware of all GIT's functions, so my options are bound by those I know. I appreciate your innovation ;)

I though the simplest way would be if I could disable any auto merging and do it all manually (the codes aren't so large, and I'd have to look into it anyway). After that I'd create a simple merge driver that would pass all the code changes (not only the conflicts) to something like WinMerge or Kdiff3 where I'd get the job done. Unfortunately I didn't manage to get it this way yet.

My last attempt resulted in a lengthy and unpractical workflow, but I'll write it here so you can have an idea of my goal.

init repo proj1
copy prod files
first add/commit
$ git checkout -b dev
configure dev settings
code/commit dev cycle
copy dev files to tmpDevDir
$ git checkout master
use WinMerge to compare tmpDevDir against proj1[master branch] and apply only desired changes
commit proj1[master branch]
$ git merge dev
merge conflicts where needed
$ git diff HEAD HEAD^ to review merge result and revert the merged configs
$ git commit -am 'final commit for the production code'

And well... not nice.

Would anyone have ideas for a more practical workflow or other commands which would help this out?

thanks a lot,

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

甜嗑 2024-09-13 17:03:53

这是一个典型的“配置文件”情况（即使您的文件不完全是配置文件）。

通常的解决方案是：

仅将变量名称放入代码中
将特定于每个环境的值提取到各自的文件中
版本能够生成实际代码的脚本（其中变量名称已根据当前环境替换为其值）
set a 过滤器驱动程序（请参阅Git ProBook）自动进行变量替换（意味着不会创建“新文件”：仅修改 上的当前代码git checkout -- 变量被值替换 --，并在 git commit 上“清理” -- 值被变量替换，并且值被修改后放回到单独的配置文件中)

alt text

这样，您不必仅仅因为您在某些文件中有单独的值。
没有复杂的合并、分支之间的复制等等。

只是：

yourCode1.code
yourCode2.code
...
yourCoden.code
devValues.txt
prodValues.txt
scriptPutValuesInCode.sh
scriptCleanCodeFromValues.sh

和过滤器“污迹干净”

*.code  filter=setOrCleanValues

git config --global filter.setOrCleanValues.smudge /path/to/scriptPutValuesInCode.sh
git config --global filter.setOrCleanValues.clean /path/to/scriptCleanCodeFromValues.sh

It a classic "config file" situation (even if your files are not exactly config file).

The usual solution is to:

put only variable names in your code
extract the values specific to each environment in their own files
version a script able to generate the actual code (the one in which variable names have been replaced with their values depending on the current environment)
set a filter driver (see Git ProBook) to automate the variable substitution (meaning no "new files" are created: only the current code is modified on git checkout -- variable replaced by values --, and "cleaned" on git commit -- values replaced by variables, and values put back in a separate config file if they have been modified)

alt text

That way, you don't have necessarily to create separate branches just because you have separate values in some files.
No complex merges, copy between branches and so on.

Just:

yourCode1.code
yourCode2.code
...
yourCoden.code
devValues.txt
prodValues.txt
scriptPutValuesInCode.sh
scriptCleanCodeFromValues.sh

and a filter "smudged clean"

*.code  filter=setOrCleanValues

git config --global filter.setOrCleanValues.smudge /path/to/scriptPutValuesInCode.sh
git config --global filter.setOrCleanValues.clean /path/to/scriptCleanCodeFromValues.sh

回复收藏 0 原文

~没有更多了~