Everything you need to know about Git for Mendix
For the last decade, Mendix has relied on SVN for version control. However, with Git surpassing SVN in functionality, migrating to Git became inevitable. With all the talk about using Git with Mendix, you probably considered migrating or have done so already.
Having relied on SVN for so long, many developers became accustomed to working with SVN. Now that updating is suddenly called pulling, and committing doesn’t mean what it used to mean anymore, many developers are confused about the differences between SVN and Git.
I dove into the inner workings of Git, and in this post, I’ll explain what has changed and what it means for you as a Mendix developer.
What is Git?
To establish a common understanding of Git, let’s delve into some key concepts.
Git is an open-source framework for version control. Don’t confuse it with GitHub which is the most commonly used implementation of the Git version control system currently owned by Microsoft. Mendix uses Git, and you can host it on the Team Server or your own Git provider.
Git is a decentralized version management system while SVN is centralized. This concept is important because it changes many of the concepts associated with version management. In SVN, the repository on the Team Server is always the single source of truth. In Git, each repository is a complete copy of itself.
A repository contains your Mendix project including its history. Creating a local copy of the code on your machine is called cloning. You refer to the repository on the cloud as the remote. When you commit, you save the changes to your local repository. Pushing sends these changes to the remote. If the remote has commits that you don’t have locally, the remote is ahead of you. Before you can push, you have to merge the remote changes into your local repository first. Merging is the process of combining changes from different development lines.
In SVN, you had to update your local copy before you could commit. In Git, this works the other way around: you always commit your work before pulling. Using these newly learned concepts, we can understand why. In SVN, you have to update your local copy to be in sync with the single source of truth before you can send an update to the server. Merging the remote changes is needed before the server is ready to receive an update. In Git, you apply an update to your local copy and then pull incoming changes. These incoming changes are merged into your local repository. This is good: it separates your work from the changes required to merge. In Git, you’ll commit, then pull, merge, then push.
Merging in Git
While you probably know merging from SVN as moving changes from one branch to another, it refers to a bit more than that. Merging is the process of combining changes from one line of development into another. This could also mean merging changes from the remote into your local repository on the same branch.
Git offers different merge strategies such as fast-forwarding, cherry-picking, and rebasing. In Mendix 9, you’ll always use a basic merge, where you pull changes from the remote into your local repository and commit the merged changes. Because this method was confusing to many, Mendix introduced the rebase feature in Mendix 10.5.
Rebasing means your changes are stashed temporarily, your local copy is updated to the remote version, and then the changes are applied again. So while you developed your changes on an older commit, you’re updating your local repository and ‘acting like you’ve really developed the changes on the latest commit instead. This can only be done if there is no merge conflict between your local and the incoming changes.
For a deep dive into changes and conflict resolution, check out the extensive Mendix docs.
Handling conflicts
Git excels in merging text-based files. However, since Mendix projects are packaged in a binary .mpr file, it has difficulty merging two different .mpr files. That’s why Mendix uses a custom merge software on top of Git for .mpr files. This allows you to solve merge conflicts directly from Studio Pro.
Because of the binary .mpr file, any Git command line interactions usually result in a merge conflict. The two binary files (local and remote copy) cannot be merged by Git itself. When you perform Git commands, always open the project in Studio Pro to activate the Mendix merger.
For any conflicts outside of Studio Pro, you’ll need other software. You should be able to use any compatible Git software. If you like command-line interfaces you could install Git-cli. If you prefer a more visual interface, try GitHub Desktop. For more information on GitHub Desktop, check out Kasja Maksymiak’s guide on setting it up. Conflicts in text files also show up automatically when you open them in Visual Studio Code.
What’s next?
Git is hard. Git has endless possibilities, and as Mendix developers we only use the tip of the iceberg. Git requires strict agreements within teams on the way of working. Make sure you agree on merging strategies and committing best practices internally.
In Git, it’s more common to work in branches than it is in SVN. Investigate whether you should use branches more often than you’re used to. As repositories are now a local copy, you won’t have to download the entire repository when creating a new branch anymore.
Branching strategies depend largely on your project requirements. As a starting point, I suggest working on larger feature branches. Have your production branch be the main line and create a generic development branch. Then create feature or version branches from development such as develop-newfeature or develop-v2. Merge the feature branches into the develop branch regularly, then merge into the main line once you’re ready for a production deployment.
Some final advice
Familiarize yourself with Git commands. You don’t need to use them, but it helps to understand what’s happening under the hood to solve any Git issues that may occur.
As you can imagine, moving to Git is a huge undertaking. Mendix is working hard on improving Git. On the roadmap are visually comparing documents across revisions and pull requests. If you have ideas on improving Git in Mendix, make them heard on the idea forum.
What features do you want to see in Git for Mendix?
Read more
From the Publisher -
Inspired by this article to bring your ideas to life with Mendix? Sign up for a free account! You’ll get instant access to the Mendix Academy, where you can start building your skills.
For more articles like this one, visit our Medium page. And you can find a wealth of instructional videos on our community YouTube page.
Speaking of our community, join us in our Slack community channel. We’d love to hear your ideas and insights!
