Imagine that your team is building a leave request app. One maker designs the employee form, another builds the manager’s review screen, and a third creates a request history page. How can they organize their work and keep track of changes?
Git and GitHub help teams record versions, review updates, and combine development work. To use them effectively with Power Apps, it is important to distinguish an older Canvas app experiment from the source-control features available today.
Read this before following an older video: Microsoft has removed the experimental Canvas app Git Version Control feature and no longer supports it. The old path through Settings → Upcoming features → Experimental is historical, not a current setup instruction. Microsoft identifies source-control integration as its replacement. Microsoft Learn: retirement of Git Version Control.
This article explains the collaboration problem, translates the old workflow into plain English, and outlines the current route. You do not need previous Git experience to understand the examples.
Why do Canvas app teams need a collaboration plan?
Having permission to edit an app and being able to edit it in a particular session are different things.
In the older experience demonstrated in the video, one maker held editing control while another co-owner saw the app in read-only mode. The second maker had to wait for the first editing session to end and refresh to see saved changes.
For a small team, this created a scheduling problem. Even when people owned different screens, they still depended on the same editing session.
This describes the video’s historical behavior. Do not assume it is a universal statement about every current Canvas app editing experience. Check the collaboration capabilities available for your app and environment.
Source control addresses a related need: a reliable record of what changed and a process for sharing those changes. It does not, by itself, guarantee that every editor becomes a live, simultaneous editing session.
Git and GitHub: what is the difference?
Git is a version control system. It records changes to files so a team can compare versions and understand their history.
GitHub is a service that hosts Git repositories and provides tools for reviewing and collaborating on the files stored there. Git can also be used locally or with other hosting services.
For example, a change record might explain that Meera updated the leave request validation on Monday, while Arun changed the manager’s screen on Tuesday. The useful part is not just having the latest files; it is being able to inspect the work that led to them.
| Term | Beginner-friendly meaning | Example |
|---|---|---|
| Repository | The project’s files together with their version history. | leave-request-app |
| Branch | A line of development within the repository. | feature/manager-review |
| Directory | A folder inside the repository. | apps/leave-request |
| Commit | A recorded checkpoint containing a set of changes. | Add a manager decision message |
| Push | Send local Git commits to a remote repository. | Make a committed update available to the team |
| Pull | Bring incoming repository changes into your working context. | Receive a teammate’s update |
| Pull request | A proposal to review and merge branch changes. | Review the manager screen before merging |
The Power Platform interface can wrap several Git operations into a single action. Read the action’s purpose in the workflow you are using rather than assuming that every button maps to exactly one Git command.
Pull and pull request are different. Pulling updates brings changes into your working context. A pull request asks reviewers to consider merging changes between branches.
Key takeaway“A useful version history explains what changed and why the team changed it.”
A simple example: three makers, one leave request app
Before choosing tools, divide the work into clear responsibilities.
| Maker | Assigned work | Validation |
|---|---|---|
| Meera | Employee request screen | The date range and leave reason are captured correctly. |
| Arun | Manager review screen | The decision and comments are shown correctly. |
| Priya | Request history screen | The history displays the intended requests. |
They can work on separate tasks during the same development period. This is parallel development. Git supports branching and combining work, but the team still needs a Power Apps workflow that supports its editing approach.
Separate screens reduce overlap; they do not remove it completely. Agree on ownership before changing shared items such as:
- Variables: Values used across more than one screen.
- Data sources: Connections and data used throughout the app.
- Components: Reusable controls that can affect several screens.
- Startup formulas: Logic that prepares the app when it opens.
- Navigation rules: Formulas that move users between screens.
For a first exercise, use labels and buttons in a disposable practice app. Add business data and approval logic after you understand how changes are recorded and received.
How the older Canvas app GitHub integration worked
The following is an explanation of the retired workflow shown in the supplied transcript. Do not use it as a new installation guide.
Stage 1: Create the repository
The maker created a GitHub repository to hold the app files. The demonstration used a private repository and described that as a requirement of the older integration.
A private repository restricts who can access it, but access still needs to be configured deliberately. Repository visibility and Power Apps sharing permissions are separate controls.
Stage 2: Enable the experimental app feature
Inside the Canvas app editor, the maker enabled the experimental Git Version Control setting. That exposed a connection page within the app’s settings.
If you cannot find this setting today, repeatedly searching the experimental features list will not restore it: Microsoft documents that the feature has been removed. Microsoft Learn: removed feature guidance.
Stage 3: Identify the repository location
The old connection collected three pieces of information:
- Repository URL: Which GitHub repository should hold the app?
- Branch: Which line of development should the app use?
- Directory: Which folder should contain its files?
In our example, those values could have described a leave-request-app repository, its main branch, and an apps/leave-request folder. These are illustrative names, not required folder names.
Stage 4: Authenticate the connection
The demonstration used a GitHub username and a classic personal access token, or PAT. A token is a credential that allows software to act with the permissions granted to it.
The video also showed reusing credentials in another session. For team work, do not copy one person’s token to every maker. Use approved identities and permissions, keep credentials out of app files and repositories, and avoid a permanent broad-access token as a tutorial default.
The modern setup described below has different authentication requirements. Creating the old token does not recreate the retired feature.
Stage 5: Synchronize the app
After connection, the historical integration stored the app’s source representation in the repository. Makers then used the demonstrated save or synchronization controls to exchange changes.
The video illustrated this by creating a screen and controls in one session and synchronizing another session to receive them. The core lesson is useful: development work needs both an outgoing step to record changes and an incoming step to receive other people’s work.
Understand what a commit should contain
A useful commit represents one understandable piece of work, for example:
- Add the employee request screen.
- Improve a date-validation message.
- Fix navigation to the request history screen.
| Weak message | Clearer message |
|---|---|
| Changes | Add the employee leave request screen |
| Fixed | Prevent submission when the end date precedes the start date |
| Update app | Show manager comments on the request history screen |
Clear messages help teammates decide what to review and help you understand old decisions weeks later.
Save, commit, and publish are separate concepts
- Save preserves your app editing work.
- Commit records a source-control checkpoint.
- Publish makes a saved app version available to its users.
The retired integration combined some actions in its interface. Do not carry the assumption that saving always commits into every current Power Platform workflow.
Key takeaway“Save your work, record a meaningful commit, and test the app after bringing changes together.”
What happens when changes overlap?
Suppose Meera changes the submit button’s validation while Arun changes the same button’s navigation. Both changes may be necessary. Accepting one version without review could remove the other maker’s work.
In the current solution Source control experience, review detected conflicts and choose whether to keep the environment version or accept the incoming version. That choice prepares the resolution; the next pull or commit applies it. Validate the app afterward. Microsoft Learn: conflict resolution.
What should beginners use now?
Start with Power Platform solution source-control integration. Microsoft identifies it as the replacement for the retired Canvas app feature. It works at the solution level, so plan the environment, solution, and repository together.
At the time of this article, Microsoft labels its GitHub connection as preview, with production-use restrictions. Its setup is different from the video’s username-and-token dialog. Microsoft Learn: current GitHub integration.
Current GitHub setup roadmap
This is an orientation checklist; use Microsoft’s linked instructions for the full configuration.
- Prepare a custom unmanaged solution in Dataverse and the required Managed Environments configuration.
- Arrange Dataverse System Administrator access, GitHub organization administration access, and Azure Key Vault permissions.
- Create a GitHub App with repository content read/write access and install it on the selected repository.
- Import its private key into Azure Key Vault in the same Microsoft Entra tenant.
- Create the GitHub connection and configure solution source control through the preview maker experience.
- Enter the repository destination and GitHub App configuration. Grant the configuration’s Dataverse managed identity the required Key Vault Crypto User role.
- Verify the connection and test a commit.
Follow the complete GitHub preview setup guide. An administrator should review this setup before makers begin.
Practice the current change cycle
Once an administrator has configured a suitable development setup:
- Commit a baseline of your small practice solution.
- Change a label in Power Apps Studio and save the app.
- Open solution Source control, refresh, review the change, and commit it.
- Inspect the commit in the connected repository.
- When a valid teammate update is available, select Check for updates, review it, resolve conflicts, and select Pull.
- Reopen and test the affected app experience.
Check for updates detects incoming changes; Pull applies them. Microsoft Learn: source-control operations.
Review Managed Environments licensing with your administrator. Do not assume the requirements of the retired experiment apply to the replacement.
Good habits for a small development team
- Assign work clearly: Agree on screen ownership and discuss changes to shared formulas and components.
- Keep changes focused: Avoid combining unrelated fixes into one commit.
- Review before accepting: Understand incoming changes before applying them.
- Use individual access: Maintain accountability without sharing another maker’s credentials.
- Test the complete journey: After combining changes, check employee entry, manager review, and history navigation together.
- Plan releases separately: A repository commit is not a production deployment.
Key takeaway“Clear ownership, small changes, and regular testing make teamwork easier to manage.”
Common beginner questions
Why can’t I find Git Version Control under Experimental?
The app-level feature in the video was removed. Use Microsoft’s replacement guidance rather than trying to reproduce the old menu.
Does making somebody a co-owner give them GitHub access?
No. App sharing and repository authorization are separate. Configure access for the chosen integration rather than assuming one permission grants the other.
Does GitHub store my business records?
Source control stores application source and configuration representations. Do not treat the repository as a backup of leave requests or other Dataverse records.
Can I edit every generated file directly?
Do not assume that generated files are interchangeable with editable application source. Begin with changes in Studio and inspect the resulting diff. Microsoft documents specific restrictions and supported workflows for canvas source editing. Microsoft Learn: canvas app source files.
What if an existing app still uses the retired integration?
Microsoft directs owners to open the app in Studio, select Settings → Git version control → Disconnect. Its documentation also describes recovery for PASopa-based apps. Preserve the existing work and coordinate the transition before changing the connection. Microsoft Learn: disconnecting the retired integration.
Your first learning goal
Start by understanding one complete change: make a small update, record it, inspect its history, and validate an incoming update. Once that process is familiar, introduce branch reviews and a release process suited to the team.
The lasting lesson from the older demonstration is the value of organized collaboration. The exact buttons have changed, but clear ownership, useful commit history, and careful validation remain essential.
No comments
Post a Comment