How should you use GIT when working across branches and/or together on the main line?

Note: This is rather a discussion than a question. – – – –  I was just reading how GIT will be the only version control system in Mendix 10 and I was a bit surprised, since my earlier experiences (Mx 9.12.X) while working on a (native) MVP project in a team of 2 developers was quite horrible.    My biggest issues with GIT in Mendix, unless this has been changed,  was in regard to updating/committing. For example; my colleague just pushed changes and I wanted to update my model. I had no changes, but I did revert an earlier change made. Mendix forced me to first push my changes before allowing me to update. Or another example, where I had changes I wanted to commit, but there was a newer version already committed. I had to push my changes, update my model and then commit my changes. But if you looked at the change history, you saw both my and their changes listed under my changes. In addition, but my mind may be lacking correct memories, but I believe to remember also having a lot of issues while working on feature branches, simultaneously.   In my past 5 years working with Mendix and SVN, everything was smooth. My GIT experience together with Mendix is limited to 2 small projects over 2 months. Yet, I don't like they way GIT works. Maybe things have changed for the better, but I fear a bit for the future.   In preparation of what's to come, I wanted to start a small discussion in regard to working with GIT, how you should push/pull and what you think are the advantages of GIT over SVN. I'm quite curious.   – – – –    P.S. There is no space related to version control.
3 answers

I agree working with git has it’s downsides atm compared to good old svn. It makes more sense when you realise you have three copies:

- teamserver (mainline/branch)

- local copy

- local (working directory)

When you change things, you save in “local (working dir)”. When you commit, you commit to your local copy and optionally (default = yes) to the teamserver. When a colleague has committed stuff to the teamserver, I think you should commit your changes first (to local copy only, so toggle the “commit to remote server” boolean), update, then push.


Several things make no sense though:

- when checking history, I think the local copy history is shown, causing, as you mentioned, the impression that your colleague’s changes are actually yours

- commits to local copy also show up in the teamserver history in the Mendix Cloud portal, but maybe I misunderstand something here

- Studio Pro sometimes wants you to update before committing, while there are no changes on the teamserver

- Studio Pro considers your working directory changed while you’ve undone your changes, which is annoying

- When you update, you still need to commit the received changes to your local copy, which is confusing, especially when you combine that with your own additional changes and commit to the remote server


Also Studio Pro could make more use of git features, like committing a subset of available changes to the teamserver. It does already cause less conflicts, but that may also be a change by Mendix where svn would also benefit, but I have no Mx9 svn projects, only git, so I can’t really compare.


Still, I’d recommend starting new projects with git version control. You’ll have to migrate from svn to git sooner or later. And the way git is implemented may be confusing sometimes, but I haven’t had serious problems or issues.


I agree; working with Git in Mendix is a struggle right now. I hope this will be improved since we HAVE to use Git in Mx10.I agree; working with Git in Mendix is a struggle right now. I hope this will be improved since we HAVE to use Git in Mx10.


Working with Git is a nightmare.  One app, I can’t convert (unknown reasons, had to send to R&D).  another app, I converted and the time it takes to push changes or publish has extended beyond 30 minutes.  hopefully they clean this up and put out a hotfix as it makes it really hard to work with source control properly.