Microsoft Fabric Git Integration: New Ways to Compare, Commit, and Branch
Git integration in Microsoft Fabric has come a long way. What started as a way to connect Fabric workspaces with source control has gradually evolved into a more complete development workflow with better synchronization, branching, comparison, and now more granular control over what gets committed. The September 2026 Fabric updates introduce several preview capabilities that make Git-based development more practical, especially for teams with multiple developers, long-running changes, and shared Fabric workspaces. In this article, I’ll walk through the Git workflow from the beginning and highlight additions that caught my attention: enhanced compare and conflict resolution, file-level commits, selective branching, branch workspaces, bulk import/export APIs, and the new Branch workspace admin profile. If you have already worked with Git integration in Power BI and Fabric, the basic workflow will look familiar. For a Power BI report, first save the project as a Power BI Project (.pbip). Once the project is ready, you can connect your Fabric workspace to Git. Connecting a Fabric Workspace to GitHub In Microsoft Fabric, create or open the workspace you want to connect. Go to: Workspace settings → Git integration Select GitHub as the Git provider and choose Add account. Fabric will ask for information such as: GitHub account/name Personal access token Repository URL Branch Creating the GitHub access token For GitHub, the access token can be created from: GitHub → Settings → Developer settings → Personal access tokens → Fine-grained tokens When creating the token, select the appropriate repository and configure the required repository permissions. For the Git integration scenario, the Contents permission needs to allow the required read/write operations. Copy the generated token for Git integration in Fabric. Working with a Feature Branch After connecting Git, create a feature branch instead of changing the main branch directly. For example: git checkout -b feature/dashboard This creates and switches to a new branch called feature/dashboard You can then connect and synchronize this branch with the Fabric workspace. After the initial setup, the familiar Git workflow continues. For example: git push origin feature/dashboard After pushing the project, you can view its structure under the relevant branch on GitHub. At the same time, the connected Fabric workspace contains the corresponding Fabric items, such as the report and semantic model. For example, suppose I remove the Partner slicer from the report. The Fabric workspace changes; the Git branch updates its version. This is where the enhanced compare experience becomes particularly useful. Instead of syncing and assuming alignment, check the differences between your workspace and the Git branch. Enhanced Compare and Conflict Resolution The September update features an enhanced comparison experience. Before committing changes, updating the workspace, or resolving conflicts, you can inspect what has actually changed between the workspace and the connected Git branch. The comparison experience provides clearer context around changes, allowing you to understand the differences before taking action. File-Level Commit — Preview This is one of the additions I find particularly interesting. With file-level commit, you can select specific files within a supported Fabric item and commit only those changes. The remaining changes stay in the workspace until you are ready to commit them. Selective Branching and Branch Workspaces Workspace-level branching is another key topic for September updates. When using Fabric, developers need a suitable workspace to build and test changes. Branch workspaces provide isolated environments linked to specific Git branches, making them ideal for teams working on independent features. Branch Workspace Admin Profile — Preview One notable addition is the new Branch workspace admin profile. This feature addresses an important governance challenge. Developers can create branch workspaces using the configured profile without needing the same elevated permissions. The benefits include: Developers can create branch workspaces without broad workspace-creation permissions. Capacity assignment can remain centrally governed. Branch workspaces can follow a consistent configuration. Development environments remain more isolated. Administrators retain control over the underlying setup. This creates an interesting balance between developer flexibility and platform governance. What About Changes Made Directly in Git? The workflow also works in the other direction. Suppose you make a change directly in the project files through VS Code. For example, you modify the title or another supported definition in the project. You can then synchronize the change through Git. A typical Git workflow could look like: git pull --rebase origin feature/dashboard followed by: git push origin feature/dashboard Changes pushed to GitHub trigger detection in the Fabric workspace. You can then review the changes and choose to update the workspace. Bulk Import/Export APIs Another addition worth watching is the availability of bulk import/export APIs. Bulk APIs can streamline these processes, particularly when integrated with Git-based development, CI/CD, and deployment automation, aligning Fabric with modern software engineering practices. The important shift is that Git integration is becoming more than a simple connect → commit → sync experience. We now have more control over: What changed → What to commit → What to update → Where to develop → How development is governed The September 2026 Fabric updates show an interesting evolution in Git integration for Microsoft Fabric. It combines multiple capabilities to create a more controlled development workflow.Lakehouse vs. Warehouse in Microsoft Fabric: Which One Should You Actually Use?
If you're new to Microsoft Fabric, you've probably hit this wall already: you go to create an item, and Fabric hands you two very similar-sounding options - Lakehouse and Warehouse. Both store tabular data in Delta format in OneLake and provide SQL access, but they offer different development and transactional experiences. Both let you query with SQL.Fabric presents both as analytical data-store options, and their capabilities overlap enough that the choice is not always obvious. So which one do you pick? Short answer: it depends on who's writing the queries and what shape your data is in. Long answer: keep reading — and try the quick self-check below before you scroll to the recommendation. 60-Second Self-Check Answer these three questions honestly before you create your next Fabric item: 1. Who will write the transformation logic? - A) Python/Spark notebooks, data engineers comfortable with PySpark - B) SQL analysts and BI developers who live in T-SQL 2. What does your source data look like? - A) Mixed — JSON, Parquet, CSV, streaming events, semi-structured - B) Mostly clean, structured, relational-shaped data 3. What's the end consumption pattern? - A) A mix of ML, notebooks, ad-hoc exploration, and reporting - B) Primarily Power BI reports and governed semantic models Mostly A's → Lean Lakehouse. Mostly B's → Lean Warehouse. Mixed bag? → You're not alone — see the "Can I use both?" section below. Lakehouse: The Flexible One A Lakehouse stores data as files (Delta Parquet) in OneLake, and gives you two ways to work with it: - Notebooks (PySpark, Spark SQL) for engineers who want full control - A SQL analytics endpoint that auto-generates so SQL folks can still query the same tables Pick Lakehouse when: - Your data arrives messy, semi-structured, or in large volumes that benefit from Spark's distributed processing - Your team already thinks in notebooks and data science workflows - You want schema flexibility - Delta tables support schema enforcement and controlled schema evolution, offering flexibility while preserving data reliability. - You're building a medallion architecture (bronze → silver → gold) and need engineering muscle at the bronze/silver layers Watch out for: - The SQL endpoint is read-only - The SQL analytics endpoint is read-only for Lakehouse table data, so it does not support INSERT, UPDATE, or DELETE against those Delta tables. Modify or load the data through Spark or another supported ingestion and transformation experience. You can still create supported SQL objects such as views, functions, and stored procedures in the endpoint. - Fabric provides automatic Delta table optimizations, but advanced workloads may still benefit from deliberate file sizing, data layout, partitioning, or optimization strategies. (OPTIMIZE, V-Order, partitioning) python #Typical Lakehouse bronze-to-silver pattern in a notebook df = spark.read.format("json").load("Files/raw/events/") df_clean = df.dropDuplicates().withColumn("load_date", current_date()) df_clean.write.format("delta").mode("overwrite").saveAsTable("silver_events") Python from pyspark.sql.functions import current_date() df = spark.read.format("json").load("Files/raw/events/") df_clean = df.dropDuplicates().withColumn("load_date", current_date()) df_clean.write.format("delta").mode("overwrite") saveAsTable("silver_events") Warehouse: The Familiar One Fabric Warehouse provides a rich T-SQL-first data warehousing experience. — think of it as a cloud data warehouse that happens to store data in OneLake under the hood. Pick Warehouse when: - Your team's primary skill is T-SQL, not Spark/Python - You need full DML (`INSERT`, `UPDATE`, `DELETE`, `MERGE`) with transactional guarantees - You're modeling a governed, relational structure — star schemas, stored procedures, views - You want a more traditional data-warehouse development experience (cross-database queries, You want a familiar relational warehouse development experience with T-SQL, views, stored procedures, and support for compatible SQL tools.) Watch out for: - Less flexible with wildly semi-structured or streaming-first data — you'll typically land that in a Lakehouse first, then move it in Warehouse is designed primarily for T-SQL rather than Spark-native development. If Spark is central to your transformation logic, Lakehouse is usually the more natural starting point. sql -- Typical Warehouse transformation pattern MERGE INTO dbo.DimCustomer AS target USING staging.CustomerUpdates AS source ON target.CustomerID = source.CustomerID WHEN MATCHED THEN UPDATE SET target.Email = source.Email WHEN NOT MATCHED THEN INSERT (CustomerID, Email) VALUES (source.CustomerID, source.Email); Can I Use Both? Yes - and honestly, A supported and commonly discussed architecture is to use a Lakehouse for engineering-oriented layers and a Warehouse for a curated relational serving layer. do exactly this: - Lakehouse for bronze/silver ingestion and heavy transformation (Spark does the messy work) - Warehouse for the polished gold layer that analysts and Power BI consume with familiar T-SQL Both use OneLake, and Fabric supports patterns such as shortcuts and cross-database queries that can reduce or avoid unnecessary data duplication. If you physically load curated data into separate Warehouse tables, however, that creates another stored representation. Try It Yourself Before your next project kickoff, run this checklist with your team: [ ] Who owns the transformation code - engineers or SQL analysts? [ ] Does the source data need Spark-level flexibility, or is it already relational? [ ] Do you need multi-table transactions and T-SQL DML, or can table changes be implemented through Spark and Delta operations? [ ] Could a hybrid (Lakehouse → Warehouse) actually be the real answer? No data to test with yet? A quick way to practice both patterns above is to grab a free sample dataset (or a ready-made dashboard layout to reverse-engineer) from a site like Docynx. Over to you I'd love to hear how your team decided: Did you go Lakehouse, Warehouse, or both? What tipped the decision — team skill set, data shape, or something else entirely? Drop your setup in the comments — especially if you've got a "we picked wrong and had to migrate" story, those are always the most useful ones.Dataflow Gen2 vs Copy Job vs Pipeline: Choosing by Workload, Not by Habit
Every Fabric team has a default tool. People who came from Azure Data Factory build a pipeline for everything. Power BI people open Dataflow Gen2 for everything. Newer teams might put every table into a Copy Job because the wizard is quick. Each tool does its own job very well. Problems start when it gets used for another tool's job: pipelines full of hand-built watermark logic, dataflows used only to copy tables, and Copy Jobs expected to handle transformations they were never built for. This post gives you a simple way to pick the right tool based on what the workload needs. One sentence each Copy Job moves data from A to B, including incremental loads, with as little setup as possible. Dataflow Gen2 shapes data. It cleans, merges, reshapes and applies business rules using Power Query. Pipeline coordinates work. It runs steps in order, handles dependencies and failures, and ties everything together. If you remember only one thing, remember this: Copy Job moves, Dataflow shapes, Pipeline orchestrates. Start with three questions about the workload Ask these before you open any editor. Am I moving data or changing it? If the data arrives at the destination looking mostly like the source, with only column mapping or type changes, you are moving data. If you are joining, deduplicating, deriving columns or applying business logic, you are transforming it. How does the source change? A one-time or full reload is a different problem from an ongoing incremental sync. Incremental loads based on change data capture (CDC) are different again. How many steps depend on each other? A single load on a schedule is one thing. "Load these, then validate, then transform, then run a stored procedure, then alert someone if it fails" is a workflow. Your answers usually point clearly to one tool. Copy Job: when the job is data movement Copy Job is the newest of the three and the one most often overlooked by teams stuck in old habits. Microsoft's decision guide lists its main scenarios as incremental copy and replication (both watermark-based and native CDC), data lake and storage migration, medallion ingestion, and out-of-the-box multi-table copy. Microsoft Learn The incremental support is the main reason to use it. In a pipeline, the Copy activity handles incremental copy through pipeline expressions and control tables, and only with watermarks. That means you build and maintain the control table, the lookup, the parameterized query and the watermark update yourself. Copy Job does this for you. Microsoft Learn Choose Copy Job when: You need to ingest many tables from a database into a lakehouse or warehouse. You want an initial full load followed by incremental updates, and you don't want to build watermark logic. The source supports CDC and you want inserts and updates merged into the destination automatically. The destination is outside Fabric. Copy Job supports 40+ destination connectors. Microsoft Learn Microsoft's own example fits this well: an analyst who needs multi-table selection across regional SQL Server instances, a bulk initial load, and then CDC-based incremental merges picks Copy Job because it supports both watermark-based and native CDC incremental copying through a wizard, and automatically detects CDC-enabled tables. Microsoft Learn Don't choose Copy Job when: You need real transformation. Its transformation support is rated low, and that is intentional. Microsoft Learn The load is one step in a larger workflow with conditions, retries and downstream dependencies. That belongs in a pipeline. Dataflow Gen2: when the job is shaping data Dataflow Gen2 is Power Query running at Fabric scale. It is the right tool when the value lies in the transformation logic. It offers 170+ built-in connectors, 300+ transformation functions in a visual interface, and data profiling tools for checking data quality. Microsoft Learn A common complaint is that dataflows are slow for large volumes. That used to be a fair criticism, but Fabric has added several performance features aimed at specific workloads: Fast Copy is for direct, high-throughput copies from a supported source with no transformations. It uses the same backend as the pipeline Copy activity. microsoftmicrosoft Modern Evaluator helps when you are shaping data from connectors that don't fold, or only partly fold. microsoft Partitioned Compute is for large, partitioned or multi-file datasets that can be processed in parallel. microsoft Staging lets you land raw data first and transform it afterwards (ELT), so ingestion and transformation don't compete in one pass. microsoft Choose Dataflow Gen2 when: Business logic is the main work: cleansing, standardizing codes, merging sources, calculated columns. The people who own the logic know Power Query and would struggle to maintain Spark or SQL. You are combining files, APIs, SharePoint lists and databases into one clean dataset. You want visual data profiling while you build. Don't choose Dataflow Gen2 when: You are only copying tables. Fast Copy makes this workable, but Copy Job is simpler, gives you incremental loads without extra work, and has less to maintain. Your destination isn't supported. Dataflow Gen2 lists around 7+ destination connectors, compared with 40+ for the copy tools. Microsoft Learn The transformations are very complex or code-heavy. At that point a notebook is usually the better choice. Pipeline: when the job is coordination A pipeline is not mainly a data movement tool. It is the orchestrator. Microsoft describes it as low-code orchestration that groups several activities together to complete a task. The Copy activity inside it is powerful, and it remains a strong option for very large migrations. The guide describes it as the best low-code choice for moving petabytes of data into lakehouses and warehouses, either ad hoc or on a schedule. Microsoft LearnMicrosoft Learn The real reason to use a pipeline is the control flow: dependencies, branching, retries, failure handling, parameters, and calling other items. Choose a pipeline when: Several steps must run in a set order, where step B only runs if step A succeeds. You need logic such as If/Else, ForEach over a metadata list, or waiting on an external event. You are combining different item types, such as a Copy Job, a dataflow, a notebook, a stored procedure and a web call. You need error handling and notifications around the whole process. You are doing a large, custom migration where you want detailed control over the Copy activity. Microsoft's scenario for pipelines describes a workflow that runs stored procedures, calls web APIs, moves files and executes other pipelines. That is orchestration, not simple ingestion. Microsoft Learn Don't choose a pipeline when: It would contain a single activity that just runs one dataflow on a schedule. Dataflows can be scheduled on their own. You would be rebuilding incremental loading by hand when Copy Job already supports your source. Side-by-side Copy Job Dataflow Gen2 Pipeline Main job Move and replicate Transform and shape Orchestrate Incremental loads Built in (watermark and CDC) Possible, but not its strength Manual (watermark and control tables) Transformation Low High None itself (calls other items) Destinations 40+ ~7+ Depends on activities Authoring Wizard Power Query Visual canvas and expressions Best owner Data integrator, analyst Analyst, data engineer Data engineer Warning sign you picked wrong Adding transformation workarounds Dataflow has no transformation steps Pipeline has one activity Common mistakes that come from habit The "everything is a pipeline" team. Every source table gets a Lookup, a ForEach, a parameterized Copy activity and a stored procedure to update the watermark. It works, but you now maintain a small custom framework that Copy Job gives you ready-made. Keep the pipeline and let it call the simpler pieces. The "everything is a dataflow" team. Dataflows with forty queries that just select a table and load it. Move the raw ingestion to Copy Job and keep dataflows for the layer where logic actually happens. The "Copy Job does it all" team. Trying to handle business rules with column mappings, then adding SQL views downstream to fix what should have been transformed properly. Once logic appears, add a Dataflow Gen2 or a notebook. The single-activity pipeline. A pipeline whose only purpose is to run one item on a schedule adds a layer to monitor without adding control. Use the item's own schedule until you really need dependencies. The pattern that usually wins: use all three, each for its own job For a typical medallion architecture, the tools fit together naturally: Bronze with Copy Job. Ingest source tables with built-in incremental or CDC loads. No custom watermark logic. Silver and Gold with Dataflow Gen2 (or notebooks for heavy, code-first logic). Apply cleansing, conformance and business rules where they are visible and easy to maintain. Pipeline around everything. Run ingestion, then transformation only if ingestion succeeded, then refresh or post-processing steps, and send an alert if anything fails. Each tool does what it is best at, and each is simpler because it isn't doing another tool's job. A 30-second decision checklist No transformation, and data must stay in sync over time? → Copy Job One-off or very large custom migration needing fine control? → Copy activity in a pipeline Transformation logic is the main work, and owners know Power Query? → Dataflow Gen2 Complex, code-first transformation at scale? → Notebook Multiple steps, dependencies, branching or error handling? → Pipeline, calling the tools above Closing thought The right question isn't "which tool do we use?" It is "what does this workload need?" Movement, shaping and coordination are three different problems, and Fabric gives you a dedicated tool for each. Teams that choose by workload build less custom plumbing, find problems faster, and hand solutions over more easily, because each piece does one clear job. Next time you start a new load, answer the three questions first, then pick the tool.The Future of Business Intelligence: AI and Copilot in Power BI
🚀 The Future of BI: AI & Copilot in Power BI Power BI is evolving from dashboards to intelligent analytics. With AI and Copilot, users can uncover patterns, predict trends, and ask questions in natural language—getting instant insights, visuals, and explanations. Powered by Azure Machine Learning and Azure Cognitive Services, Power BI makes advanced analytics accessible to everyone—no data science required. 💡 It’s not just reporting anymore—it’s AI-driven decision-making.From Power BI to Microsoft Fabric What Data Professionals Should Know
Microsoft Fabric is changing how we think about analytics, data engineering, and BI. If you already work with Power BI, SQL, or Azure tools, this blog will help you understand what Fabric really is, how its components fit together, and where to start without getting overwhelmed.🧠 CALCULATE() vs. CALCULATETABLE() in Power BI: Which One Is Better (And Why It Matters)
👀 Have you ever written a DAX measure with CALCULATE() and thought — “this should work!” — only to see it break unexpectedly? Or maybe you tried CALCULATETABLE() and magically, everything worked. Both functions seem to answer the same question: “How do I modify the filter context?” But they work very differently — and using the wrong one can lead to confusing totals, blank visuals, and filters behaving oddly. Today, let’s demystify CALCULATE() and CALCULATETABLE(), when to use each, and why CALCULATETABLE() is often the safer bet in complex calculations.Power BI Performance Engineering: Model Optimization Tactics You’re Probably Not Using
When Power BI reports run slowly, the issue often lies not in the visuals, but in the data model itself. Focusing solely on DAX formulas isn’t enough to solve performance problems. In this post, I’ll share three powerful yet often overlooked techniques to optimize your data model and boost report performance.Power BI Enters a New Era: 3 Game-Changing Features from the May 2025 Update
Power BI continues to reshape the world of data analytics with its monthly updates. The May 2025 release brings groundbreaking improvements in user experience, modeling, and visualization. In this post, we’ll explore three powerful features that haven’t yet been deeply covered in the community blog—but are sure to make a big impact.
