需要GIT工作流程建议 [英] Need GIT workflow suggestion

问题描述

我在过去的几周里一直在研究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（）
（...）
  

这就是关于文件的问题。

现在，已经算出了什么;

乍一看， em>允许分支它情况，所以我做了。

  [创建文件夹并初始化它] 
 [从生产中复制我的代码并添加/提交它] 
 $ git checkout -b dev 
 [将这些行改为'CodeConfig' e开发设置] 
 [开心编码和提交] 
  

过了一段时间，编码和测试已经完成，现在是融入生产的时候了。这是问题出现的时间。

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

当然，在使用分支时，我希望能够合并我的代码以保留我的提交历史记录和评论。我只是需要它以更加自定义的方式来完成......

我尝试了一些不同的方法来解决这个问题，但没有成功。似乎GIT的合并对我来说太聪明了：（例如， *。xml merge = Unset into我的 .gitattributes 文件，或者将一个自定义合并驱动程序放入〜/ .gitconfig中，试图导致自动合并失败（不知道我是否正确） p>

我想过的可能解决方案; 正如我所说，我可能不知道所有GIT的功能，所以我的选择受到我所知道的约束，我很欣赏你的创新;）

虽然最简单的方法是禁用任何自动合并，手动做这一切（代码不是很大，我不得不看看它）。之后，我会创建一个简单的合并驱动程序，将所有代码更改（不仅是冲突）都传递给WinMerge或Kdiff3，从而完成工作。不幸的是，我还没有设法得到它。

我的最后一次尝试导致了一个漫长而不切实际的工作流程，但我会在这里写下来，以便您可以我的目标的一个想法。
$ b

1. 初始化回购 proj1


2. 复制 prod 文件


3. 首先添加/提交
   


5. 配置 dev 设置


6. code / commit dev cycle


7. 将开发文件复制到 tmpDevDir
code> $ git checkout master

8. 使用WinMerge比较 tmpDevDir 和 proj1 [master branch] 并仅应用所需的更改
   
9. commit proj1 [master branch]


10. $ git合并开发


11. 需要时合并冲突
    
12. $ git diff HEAD HEAD ^ 来检查合并结果并还原合并后的配置
    
13. $ git提交-am'最终提交对于产品代码'

还有...不好。

有没有人有更实际的工作流程或其他命令的想法，这将有助于解决这个问题？

非常感谢，

f。

解决方案

它是一个经典的配置文件不是完全的配置文件）。

  *。code filter = setOrCleanValues 
 
 git config --global filter.setOrCleanValues.smudge / path / to /scriptPutValuesInCode.sh 
 git config --global filter.setOrCleanValues.clean /path/to/scriptCleanCodeFromValues.sh 
  

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.

1. init repo proj1
2. copy prod files
3. first add/commit
4. $ git checkout -b dev
5. configure dev settings
6. code/commit dev cycle
7. copy dev files to tmpDevDir
8. $ git checkout master
9. use WinMerge to compare tmpDevDir against proj1[master branch] and apply only desired changes
10. commit proj1[master branch]
11. $ git merge dev
12. merge conflicts where needed
13. $ git diff HEAD HEAD^ to review merge result and revert the merged configs
14. $ 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,

f.

解决方案

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)

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

这篇关于需要GIT工作流程建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！