Guest Blog Post
Example 2: Typical Case – Multiple Developers Making Changes to Different Areas of an App
Ok, let’s get to the example. Here, I will change the SimpleForm view again by adding a Help button at the bottom while Sean (another developer at CNX) adds the controller logic at the same time to handle what happens when that button is pressed.
Here I’ve added the Help button on the bottom toolbar:
This is a screenshot of Sean’s Sencha Architect where he has added a Controller Action to handle when my Help button is pressed:
You can see in this screenshot of Sean’s WebStorm that it’s showing only the Main controller has been changed (Note: Sean’s WebStorm is using a dark theme whereas mine is using a light gray theme. Also, ignore the .architect file in the following screenshots—I should have added it to the .gitignore file so that it was not tracked for changes.):
On my WebStorm, it shows only the Viewport view class has been changed:
Now, let’s see what happens when Sean and I both commit and push into Gitlab. First, Sean will commit and push:
Now, I will commit and push the changes I made to the view:
In this case, since Sean has committed a change to Gitlab that I don’t have on my local copy, WebStorm is giving a push rejection message. However, on this error message, there’s an option to Merge:
Now, I will click the Merge button. As long as Sean and I have not changed any of the same files (we haven’t), I’ll go immediately to the Push window and push the changes:
If we now look at the files on Gitlab, we can see the last person that has changed a controller is Sean and the last person that has changed a view is me:
Obviously, this was a really simple scenario, but as long as multiple developers are working within different classes (i.e. files) all the changes should merge gracefully with no conflicts. At CNX, we try to assign programming tasks specifically to minimize merge conflicts.
In this blog post, I presented an example of how two or more developers can make changes to different areas of the same Sencha Architect app and bring those changes together gracefully. In the third and final installment of this series, I will tackle the most tricky case—multiple developers making a change to the same area of an app and resolving merge conflicts.