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
againstproj1[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,
f.