Prepstellar

DP-600 · Workspace Development Lifecycle

21 cards

Workspace Version Control

Swipe, scroll or use ← →
  1. Connect the workspace to a repository

    Fabric Git integration connects a workspace to a repository in Azure DevOps or GitHub. The connection synchronizes workspace items and repository content in both directions.

    "Both directions" is the phrase to hold on to. This is not a backup that only travels one way: work can move from the workspace into the repository, and from the repository back into the workspace.

    1 / 21
  2. Connect the workspace to a repository

    Provider Supported
    Azure DevOps Yes
    GitHub Yes

    The workspace keeps working the way it always did. What changes is that its items now have a counterpart in a repository, so the team can finally answer what changed, who changed it, and when — a question no amount of careful naming inside a workspace can answer on its own.

    2 / 21
  3. Quick check

    Which repositories can a Fabric workspace connect to through Git integration?

    1. ARepositories in Azure DevOps or GitHub

      Right. The connection is made to a repository in one of those two providers and synchronizes in both directions.

    2. BIts own local folder

      A local folder is where a project is saved on one machine, not a repository the service connects to.

    3. CThe Development and Test workspaces assigned to a deployment pipeline

      Those are pipeline environments, and promoting between them is a different mechanism entirely.

    3 / 21

  4. One connection, many kinds of item

    Because the integration is configured at workspace level, one connection can place all supported items in that workspace under version control. There is no setup per item and no provider per item.

    Supported content includes Power BI items as well as Fabric notebooks, pipelines, lakehouses, and warehouses. A workspace holding a mix of those gets one history covering all of them.

    4 / 21
  5. One connection, many kinds of item

    That scope is what makes the feature useful to a team rather than to a single author. A report is rarely the whole story: it sits on a semantic model, which sits on a lakehouse, which is loaded by a pipeline that a notebook helped build.

    What the team wants What a workspace-level connection gives
    History across mixed content One repository covering the supported items
    One place to review One branch and folder mapped to the workspace
    Consistency across item types The same commit and update actions for all of them

    Versioning only the report would leave the interesting half of that chain unrecorded.

    5 / 21
  6. Quick check

    A workspace holds reports, notebooks, a lakehouse, and a warehouse, and the team wants one version history. What fits?

    1. AA separate Git provider assigned to each kind of item

      The provider is chosen once for the workspace, and splitting it by item type would fragment the history.

    2. BOne workspace-level Git connection

      Right. The integration is configured at workspace level, so one connection covers the supported items in it.

    3. CA separate deployment stage created for each kind of item

      Stages move content between environments; they record nothing about what changed or who changed it.

    6 / 21

  7. Map the repository, branch, and folder

    To configure the connection, open the workspace in the Fabric portal and select Workspace settings, then Git integration. Choose Azure DevOps or GitHub, and then select the repository, branch, and folder to map to the workspace.

    Three selections, each narrowing the one before it: which repository, which line of development inside it, and which folder within that line.

    7 / 21
  8. Map the repository, branch, and folder

    Complete the initial sync so the workspace and repository begin from an aligned state. The repository, branch, and folder mapping define which source-controlled location corresponds to the workspace. The initial sync establishes alignment; subsequent commits and updates maintain that relationship.

    Skipping that first alignment is how a team ends up unsure which side is authoritative. Once both sides have started from the same point, every difference afterwards has a clear meaning.

    8 / 21
  9. Quick check

    What is selected when the workspace connection is configured, and what finishes the setup?

    1. AA capacity and a stage, finished by a deployment

      Capacities and stages belong to deployment pipelines rather than to a version control connection.

    2. BA server and a database, finished by authentication

      Server and database details identify a data source, not a source-controlled location for a workspace.

    3. CA repository, a branch, and a folder, finished by the initial sync that aligns both sides

      Right. The mapping defines which repository location corresponds to the workspace, and the initial sync makes both start aligned.

    9 / 21

  10. Keep your progress in the app

    That’s 3 of 8 quick checks. In the app they stay answered, and every lesson remembers where you left off.

  11. Read the status indicators first

    After connection, each workspace item displays a Git status indicator. An item that differs from its repository version shows a change icon, while an item that matches the repository shows a synced status. These indicators identify pending differences before a commit or update.

    Reading them first is the habit worth building. The indicators tell you which direction you need before you pick an action, and picking the action first is how somebody pulls when they meant to push.

    10 / 21
  12. Quick check

    An item in a connected workspace shows a change icon. What does that mean?

    1. AIt cannot be placed under version control at all

      Supported items can all be version-controlled; the icon reports a state, not an exclusion.

    2. BIt differs from its repository version

      Right. The indicator flags a pending difference before you commit or update.

    3. CIt exists in the target workspace of a pipeline stage

      Pipeline stage membership is a separate idea and is not what this indicator reports.

    11 / 21

  13. Commit: workspace to repository

    When workspace items have changed, open Source control to review the pending changes. Select the items to include, enter a descriptive commit message, and commit them to the Git repository.

    A commit therefore moves selected workspace changes into version history; it does not pull newer repository changes into the workspace.

    12 / 21
  14. Commit: workspace to repository

    Two words in that sentence carry weight in practice.

    • Selected. You choose which changed items to include, so unfinished work can stay out of the commit.
    • Descriptive. The message is what makes the history readable later; "update" tells a colleague nothing six months from now.

    And the direction is one way. Committing sends work up, and it brings nothing down, however convenient that would be.

    13 / 21
  15. Quick check

    Workspace items have changed and the repository must record them. What do you do?

    1. AOpen Source control, select the items, and commit them with a message

      Right. A commit moves the selected workspace changes into version history.

    2. BChoose Update all

      Update all pulls repository changes into the workspace, which is the opposite direction.

    3. CDeploy the items from the Test stage into Production and let the pipeline record them

      Deploying promotes content between environments and records nothing in the repository.

    14 / 21

  16. Update all: repository to workspace

    When the repository contains newer work from collaborators, use Update all to pull those changes into the workspace and synchronize it with the latest repository state. This direction is the reverse of committing: Update all brings repository content to the workspace.

    When your workspace has no pending edits and a collaborator has newer work, Update all is the direction that aligns the workspace with the repository.

    15 / 21
  17. Update all: repository to workspace

    The state you are in The action
    Workspace items changed, repository behind Commit the selected items
    Repository ahead, workspace unchanged Update all

    The operational distinction is simple: use a commit for selected workspace changes that must enter the repository, and use Update all when newer repository changes must enter the workspace. Check item status first, then choose the direction that matches the state you need to synchronize.

    16 / 21
  18. Quick check

    A collaborator has newer work in the repository and your workspace has no pending edits. What aligns them?

    1. ACommit the unchanged workspace

      There is nothing to send, and committing would not bring the collaborator's work down.

    2. BRun an initial sync with a different provider

      Changing provider restarts the setup instead of fetching work from the connected repository.

    3. CUse Update all to pull the newer repository changes into the workspace

      Right. Update all is the direction that brings repository content into the workspace.

    17 / 21

  19. Branch to isolate, and expect conflicts

    A connected workspace can be switched to another branch. Each branch is an independent line of development, so a feature branch can hold experimental work without changing the main branch before review.

    That is how a team tries something risky without asking everyone else to live with it: the experiment stays on its own line until somebody has looked at it.

    Both sides can also move at once. If the same item changes in both the workspace and repository after the previous sync, Git reports a conflict — a prompt to decide which version wins, not a failure of the connection.

    18 / 21
  20. Quick check

    A team wants experimental work kept away from the main line until it is reviewed. What should it do?

    1. ASwitch the workspace to a feature branch

      Right. Each branch is an independent line of development, so the experiment stays off main until review.

    2. BCommit the experiment straight to the main branch

      That is exactly what the team wanted to avoid: unreviewed work on the shared line.

    3. CRun Update all against main so the experiment is merged in

      Update all pulls repository changes down; it does not isolate work in progress.

    19 / 21

  21. Key takeaways

    • Configure workspace Git integration through Workspace settings, then map a repository, branch, and folder and complete the initial sync.
    • One workspace-level connection can version-control the supported Power BI and Fabric items in that workspace, notebooks, pipelines, lakehouses, and warehouses included.
    • Read the status indicator before acting: a change icon means the item differs from the repository, a synced status means it matches.
    • Commit sends selected workspace changes to the repository; Update all pulls newer repository changes into the workspace.
    • Use branches to isolate experiments, and treat a reported conflict as a decision to make rather than a broken connection.
    20 / 21
  22. Quick check

    Which pairing of action and direction is correct?

    1. ACommit pulls changes down; Update all pushes them up

      The two directions are right but attached to the wrong commands.

    2. BCommit sends selected workspace changes up; Update all brings newer changes down

      Right. One records selected work in version history; the other refreshes the workspace from the repository.

    3. CBoth commands synchronize in the same direction

      If both moved content the same way, there would be no way to receive a collaborator's work.

    21 / 21

  23. 8 quick checks · then the test

    In the app, finishing the quick checks opens this lesson’s 10-question test, and the ones you miss come back exactly when you’re about to forget them.

The whole course, on your phone

Lessons you can read, audio you can listen to on the way to work, and practice that remembers what you got wrong.