Working with Git outside of Studio Pro - Mendix Forum

Working with Git outside of Studio Pro

0

Great, you have moved your application from SVN to Git, or you have created a new project in Mendix 10, and the only option was to choose Git. While Studio Pro works well with Git out of the box, it does have a slight downside. Opening a branch is perceived as slower for larger repositories (see this Community post), and it still creates a folder per branch that you create.

 

Let me guide you through my Git workflow in the terminal (I know, h4ck3r style). This method allows me to check out and create branches faster while giving me more control when reviewing stories. 

It might sound scary for a low-code developer to work outside of Studio Pro, but once I switched, I never wanted to go back, as it gave me much more control over what I do.

I assume you have a bit of Git knowledge at the start; if not, I can highly recommend the zines of Julia Evans (How Git Works and her Git cheat sheet).

 

Setting up

To help me with this, I use Oh-My-Zsh, a nice plugin for your terminal with color coding and helping to know in which folder and on which branch you are. There are plenty of other plugins available to do this for you, so pick your favorite.

Whenever I work on a new project, I open the terminal and clone the repository with the folder name git-workflow

git clone https://git.api.mendix.com/ca40154b-b604-4549-ad7b-cece334e9f28.git git-workflow

 

My Git workflow

Committing to a feature branch

To check out any existing branch

cd git-workflow 
git checkout development
Switched to branch 'development'

Or if I want to create a new branch from development

git checkout -b feature-1
Switched to a new branch 'feature-1'

I can now work on feature-1 in Studio Pro, and I don't have to touch the terminal for a while. Once you are almost finished, you might wonder what changes you have made in Git.

git status
On branch feature-1
Changes not staged for commit:    
   (use "git add <file>..." to update what will be committed)    

   (use "git restore <file>..." to discard changes in working directory)        
      modified: git-workflow.mpr

A version control system will show you all the files that have been changed. Unfortunately for Mendix, this means that it will only show the .mpr file that has been changed, as this is a binary file, it won't be super useful other than that you know there have been some changes made. Since we are working with Git, we need to add our changes to the staging area.

git add git-workflow.mpr # To add only git-workflow to the staging area
git add . # To add everything 

To commit this feature-1 thing, we run the following command:

git commit -m 'Added a new homepage'
[feature-1 fbbcdac] Added a new homepage

1 file changed, 0 insertions(+), 0 deletions(-)

And we will have to push to our remote repository

git push --set-upstream origin feature-1

So far, standard Git stuff that you will find on the internet when you Google something about Git.

 

Reviewing changes

Now, let's talk about reviewing changes. The review process varies by team, but here's how I used to do it when we worked with SVN.

  1. A story is set to be reviewed on our board
  2. I will merge the story into development and view the uncommitted changes
  3. I write the review comments in the story 
  4. The developer will make changes based on the comments
  5. I merge the newest changes and check them
  6. Repeat until all review comments are solved

Of course, this workflow is still possible, however, there is an easier way to review changes, one in which you don't have to merge into development before you've reviewed and tested the feature.

git checkout development
Switched to branch 'development'
git pull # To make sure you have the latest development
Already up to date.
git checkout feature-1
Switched to branch 'feature-1'
git reset --soft origin/development
On branch feature-1
Your branch is up to date with 'origin/feature-1'.    
   Changes to be committed:    
    (use "git restore --staged <file>..." to unstage)
    modified: git-workflow.mpr

git reset --soft origin/development resets the branch to a stage where the changes are uncommitted, but they are still there in the staging area. It would be almost the same as if I merged the changes onto the development branch. However, it also merges any changes into the branch that were on development but not on the feature-1 branch. 

 

So for this to be working super smoothly, we need feature branches that are always up-to-date with the latest of development. Or you could merge in development yourself if you see more changes than you expected.

git merge origin/development
git add .
git commit -m 'merge in development'

It is all fine to commit to the branch as long as you don't push to the remote repository.

 

When the developer then adds new commits to the branch that will address my review comment, and I can review again, I don't want to review all the changes that they made; I want to see what they did on whatever I pointed out in the review. To do that, I use the following Git commands:

git status # Are there any changes I should reset first?
git reset --hard # This will make sure everything is reset and there are no open changes, but be cautious in using this command
git pull # Make sure that all new changes are there
git reset --soft HEAD~1
On branch feature-1
Your branch is up to date with 'origin/feature-1'.
    Changes to be committed:
    (use "git restore --staged <file>..." to unstage)
     modified: git-workflow.mpr

The git reset --soft HEAD~{x} command resets the branch to a state where the last commit's changes are staged but uncommitted. If the developer wanted to separate their commits or has more than one commit to add the changes, you can also change the number at the end to see more changes. 

 

Opening the branch in Studio Pro will show only the latest changes that were made instead of all the changes of the branch compared to development. This gives me much more confidence in that I can really see all the changes they made instead of getting lost in the total amount of changes they did for the complete developed feature. 

 

Merging changes

To merge anything into another branch, you can use the following

git merge feature-1
Updating fbbcdac..08bb2fb
Fast-forward
    git-workflow.mpr | Bin 12201984 -> 12201984 bytes
    1 file changed, 0 insertions(+), 0 deletions(-)

If there are changes in feature-1 in Studio Pro, you'll need to open it to merge the changes there, as those changes can't be seen and merged by the command line. Merging in Studio Pro is easy and is described pretty well in the documentation. Once you have merged the changes, you can add and commit them. 

 

How to get your branch out of a bad state

It might happen that your branch has diverged from the HEAD state of the branch. 

git pull

You have divergent branches and need to specify how to reconcile them.
You can do so by running one of the following commands sometime before your next pull:
     git config pull.rebase false  # mergegit config pull.rebase true # rebase
     git config pull.ff only # fast-forward only
You can replace "git config" with "git config --global" to set a default preference for all repositories. You can also pass --rebase, --no-rebase, or --ff-only on the command line to override the configured default per invocation.
fatal: Need to specify how to reconcile divergent branches.

You might have added commits while the branch also received commits. In this case, pulling no longer works, and also using it in combination with the git reset --hard command doesn't get your branch out of a diverged state. Then you can throw away your project and reclone it from the server, but that would leave you with an empty database again, as you are also deleting your deployment folder. Now you could copy that and paste it in the new cloned repo, but you could also opt for the following:

git reset --hard origin/feature-1
HEAD is now at 08bb2fb added title to page

This command will make sure that you reset your branch to the original state of the branch from the server. !!! Be cautious !!! This command will overwrite the changes you have made, so you must be sure that you don't have changes in the branch you are trying to reset.

 

Closing words

There are some caveats that you should know about. 

However these don't weigh up to in my view better handling of reviews, having one folder per app on your computer and fast switching to try stuff out without having to create a branch on the server.

This allows me to have greater control over the review process and test new features without needing to check out an entirely new folder.

Posted
0 comments