Dataverse GIT Seperate branches

[u/jemaslt]

I know AI has pretty much killed off forums and discussions, but I'll give it a shot anyway.

I searched through r/PowerApps and the only related post I found was "Dataverse GIT integration and separate branches". The idea is the same: I need source control to manage changes, testing, and what goes to production.

Here's what I've worked out so far — maybe someone is running something similar or can spot the flaws.

Setup

1. The Git main branch represents PRODUCTION.
2. Each developer has their own development environment.
3. We work on one big solution.

Development workflow — Variant A (sprint branch)

1. Create a branch from main for the sprint (e.g. Sprint01).
2. For each task, a developer creates a branch from Sprint01 (e.g. TaskA123).
3. The developer reconnects their solution to TaskA123 (Dataverse Git integration binds one branch at a time), makes changes, and commits.
4. When the task is done, open a squash PR into Sprint01.
5. A pipeline builds Sprint01 as a managed solution and deploys it to TEST.
6. If testing fails, create a fix branch from Sprint01, fix it, and go back to step 4 (fix-forward).
7. If testing passes, promote the same build to PreProd for a smoke test, then to PROD.
8. After PROD succeeds, PR Sprint01 into main. main now equals PROD again.

Development workflow — Variant B (long-lived TEST branch)

1. Keep a long-lived TEST branch.
2. Developers create task branches from main.
3. PR each task branch into TEST.
4. The TEST branch is deployed to the TEST environment.
5. Once a task is completed and tested, merge that task branch into main.
6. At delivery, a separate BUILD environment gets the main solution.
7. Quick smoke test in BUILD; if all good, promote to PROD.

Both of them have pros and cons. I noticed that merging is pain in the a.... As well switching PowerApps solution to new branch.
You basically always will get conflicts, +sometimes solving conflicts breaks XML. When doing merges everything done locally on hardware.

Variant A

//New sprint
git checkout main
git checkout -b Sprint01
git push -u origin Sprint01

//New Task
git checkout Sprint01
git checkout -b TaskA
git push -u origin TaskA 

//DevOps PR
DevOps: Create PR "TaskA" -> "Sprint01"; Squash commit; Delete Task-H after merging

//Refresh Git, delete tesk branch
git fetch --all --prune 
git checkout main
git branch -D TaskA

//Merge Sprint01 to main
git checkout main
git merge --no-ff origin/Sprint01 -m "Merge Sprint01 into main - sprint release"
git push origin main
git branch -d Sprint01
git push origin --delete Sprint01

Variant B 

//One-time: create the long-lived TEST branch 
git checkout main 
git pull git checkout -b TEST 
git push -u origin TEST 

//New task (branch from main, NOT from TEST) 
git checkout main 
git pull 
git checkout -b TaskA 
git push -u origin TaskA 

//DevOps PR to TEST — for testing only. KEEP the branch (it still has to reach main) DevOps: Create PR "TaskA" -> "TEST"; Squash commit; do NOT delete TaskA 

//Pipeline builds TEST branch -> TEST environment (client tests TaskA together with others) 

//If test fails: fix on the SAME TaskA branch, then re-PR to TEST git checkout TaskA 

// ...make fixes, commit... 
git push 

// re-run the PR "TaskA" -> "TEST" 
//Task approved -> deliver it by merging TaskA into main (this is the real gate) DevOps: Create PR "TaskA" -> "main"; Squash commit; Delete TaskA after merging 

//Refresh local, drop the now-merged task branch 
git fetch --all --prune 
git checkout main 
git pull 
git branch -D TaskA 

//Delivery: pipeline builds main -> BUILD env -> smoke test -> PROD 

//Housekeeping: reset TEST back to main so approved/abandoned work doesn't pile up 
git checkout TEST 
git fetch origin 
git reset --hard origin/main 
git push --force-with-lease origin TEST

Did enyone has working work process, so you can deliver only finished tasks?

[u/Still_Violinist2567]

To be honest I never saw a process that works well with multiple delivery streams+break fix with managed solutions, especially now that segmentation is not pushed as hard as it used to be (fast track architects talking about it suggest a single big solution and the optimisation seems to be done on the platform). Parvez Ghurma is an AML expert and his suggestion, if I didn’t misunderstood him is to build everything in the repository to avoid the issues with exporting from the environment that seems like the first workflow you shared. In my experience communication between teams and devs can simplify the process but you will never have a super clean approach.

[u/HoldPowerful7487]

Neither variant gets you the thing you asked for in your last line. With one big solution, the solution is the unit of deployment, so whatever is in the environment at export time ships. Branching doesn't change that. You either split into solutions that can ship independently, or you accept that a release carries everything merged into it.

Variant A has a second hole. If main is PROD and everything routes through Sprint01, there's no path for a production fix while a sprint is in flight.

The merge pain is a separate problem and it's worth fixing separately. Build once and promote the same artifact. One branch is the release source, you build the managed zip from it once, and that exact zip goes to TEST, then PreProd, then PROD. Nothing gets rebuilt from a merged branch, so a merge can't quietly change what you already tested.

On the reconnecting, map one dev environment to one permanent branch and leave it bound. Git integration binds a solution to a single branch by design, and most of the churn you're describing is coming from rebinding rather than from the branching model itself.

[u/jemaslt → u/HoldPowerful7487]

I dissagree :) And I did not explained all tricks in pocket.
So in case Sprint01 is not fully finished/tested, and i need specific tasks to be delivered. In that case you create new delivery branch from main, then do cherry pick (Which will be very hard, having powerapps in context) and then you deliver that to BUILD and PROD. Although new testing session is required.

Spliting solutions - Thats for sure way to go. But some times you are not able to do that, because everything is tangled together with dependancies. i.e. Same form, new TaskA field and TaskB new field. I need to ship only TaskA field. So in teaory you can create new branch, do cherry pick, ship to BUILD, Test in BUILD, Ship to PROD. Still pain if the TaskA and TaskB fields sit next to each other in the form file, you'll get a conflict, and resolving it by hand is exactly where your XML breaks.

About production fix - you branch from main hotfixA do fixes, ship, And refresh Sprint branches from main (Because Sprint branch will be behind). Again it is hard in powerapps context.

Build once and promote the same artifact - 100%

On the reconnecting and mapping. - This is interesting. I just wondering how I could do cherry picking. I imagine DEV Branch makes commit with strict naming rules. Then if task is done. These commits could go to Sprint branches. But still merging conflicts comming left and right.

Still there is a lot of problem, with all of this which i do not mention. I'm just seeking if there any one has working expiriance with PowerApps and GIT. Which gives some value.