I am writing to propose a feature enhancement for the Git client integrated into UiPath Studio, which I believe will significantly improve our development workflows, especially in environments utilizing CI/CD pipelines.
Current Feature: As of now, the Git client in UiPath Studio displays “Unpushed commits” with an upward arrow and a count, which is incredibly useful for understanding the status of local changes relative to the remote repository.
Proposed Feature: I suggest adding a complementary visual indicator for commits that are present in the remote repository but not yet pulled to the local repository. This could be represented by a downward arrow alongside a count of commits that need to be fetched or pulled.
Rationale: With the increasing adoption of CI/CD practices, repositories are often updated via automated commits. Developers need to be aware of new changes on the remote to synchronize their local copies frequently, thus avoiding conflicts and ensuring that all team members are working with the latest code.
The proposed indicator will provide immediate visibility into the status of the remote repository, offering benefits such as:
Reducing Merge Conflicts: By enabling developers to see and pull external commits promptly.
Enhancing Team Collaboration: By preventing work duplication and maintaining code consistency across the team.
Streamlining Workflows: By reducing the need to manually check remote repository status, thus saving time and reducing errors.
Supporting DevOps Principles: Continuous feedback and adjustments are vital in dynamic development environments, and real-time visibility into the remote repository is crucial.
Introducing a visual indicator for commits that need to be pulled in UiPath Studio’s Git client will make the tool more robust and aligned with modern development practices. It would be a valuable addition for all of us relying on UiPath Studio in complex development environments.
I like the idea very much! This happens a lot and worst case: you realize it, because the version deployed is already in OR or you don’t realize it at all.
I had a developer do something similar to this where it would notify us when we opened the project. In general I think the GIT addin could do with a bit of updating, its really annoying that there is no option, for example, to drop the changes when you try to switch a branch and it says there are uncommitted changes as many of the changes are due to new features inserting themselves, making them very hard to remove.
This feature I agree would be nice, there is a GIT command for it, but I think it should make sure to not interfere with you if it cannot make a connection to GIT when you load, instead showing a third icon stating unknown remote status.
Fully agree! In all LowCode applications the most impressive Git implementation I saw was in Mendix. (But they have Java, HTML, CSS and JavaScript files to work with.)
There is also the aspect of Git knowhow: I think current state of RPA tools is to treat Git as a file snapshot tool. Those teams with a more Git-conform workflow will use a Git client in parallel. (I certainly refuse to work on a UiPath Studio VDE without the Git client of my choice.)
After my CI/CD talk in the German Community event I am now preparing “RPA (Process) Testing” for a talk in June, and after that I think I will tackle a “Git for RPA Developers”. Because UiPath Studio implements a certain “workflow” that, when put in context, is geared towards xaml files. The latest when coded workflows gain traction we need/may finally have a proper Git workflow.
This is due to a combination of unclear .gitignore recommendations, and that in RPA we don’t git stash (as one should in such situations).
Thanks for your remarks. Indeed I am also curious how other RPA professionals view the topic “Git”.
I can’t agree here, sometimes its not due to new things that should be ignored, it can also be the Project.json being updated to include more stuff, which obviously cannot be ignored.
The ignore stuff is nuanced, for example I know some people will ignore entirely the .Local folder, but then doing that some important project level settings can be lost, but you of course do may not want to commit the compiled libraries that are made when using GlobalVariables, IntegrationService or coded workflows.
As a result I think its tough to agree on universal gitignore rules, especially with the new features you can trip over by implementing them.
Ah, good point about additions to e.g. project.json!
I started to check out my projects in another Studio, to observe and learn.
And I just pushed to a template repo this week, and quite some thoughts went into the .gitignore – for that specific team. Looking forward to use that template repo in the near future.
I find merge conflicts additionally confusing because
if UiPath Studio’s feature “GIT Init” was used on the same computer to initialize the repo, then UiPath Studio creates the file .git/info/attributes and jets *json and *xaml as binary files – with huge impact on merge behaviour
but in a “serious” setting with GitHub templates noone would init the repo that way (it wold come from a GitHub template which shall not contain the .git folder).
It is against common Git use to modify files there, and certainly one should not check in the .git folder (although it seems current Community / beta version of UiPath Studio tries to suggest that).
Which means there is inevitably a different behaviour of a e.g. quickly locally created BlankProcess and one under “proper” revision control: The second computer where such a repo is cloned to will not have that attribute set.
This becomes more prominent when a “real Git client” is used, like Sourcetree, Tortoise or the official Git CLI tools: Because they implement standard merge behaviour.
The git docs describe pretty well what “binary” means: Git - Git Attributes (git-scm.com) In a nutshell: “binary” is merged as full file, “text” can do more, like line-by-line diffs. Too complex for a forum post to properly cover.
I tend to think that treating UiPath project xaml files as binary is the right choice, but really must do some experiments to properly publish what is going on (maybe for Community Event?? Anybody wants to invite me as a guest speaker?)
If it really turns out that treating *.xaml as binary is best choice and well understood, then it belongs into a .gitattributes file (because that will be part of standard commit workflows).
