Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)!
Last updated: 6-Oct-2025
[Microsoft Fabric] Git
- {def} an open source, distributed version control platform
- enables developers commit their work to a local repository and then sync their copy of the repository with the copy on the server [1]
- to be differentiated from centralized version control
- where clients must synchronize code with a server before creating new versions of code [1
- provides tools for isolating changes and later merging them back together
- {benefit} simultaneous development
- everyone has their own local copy of code and works simultaneously on their own branches
- Git works offline since almost every operation is local
- {benefit} faster release
- branches allow for flexible and simultaneous development
- {benefit} built-in integration
- integrates into most tools and products
- every major IDE has built-in Git support
- this integration simplifies the day-to-day workflow
- {benefit} strong community support
- the volume of community support makes it easy to get help when needed
- {benefit} works with any team
- using Git with a source code management tool increases a team's productivity
- by encouraging collaboration, enforcing policies, automating processes, and improving visibility and traceability of work
- the team can either
- settle on individual tools for version control, work item tracking, and continuous integration and deployment
- choose a solution that supports all of these tasks in one place
- e.g. GitHub, Azure DevOps
- {benefit} pull requests
- used to discuss code changes with the team before merging them into the main branch
- allows to ensure code quality and increase knowledge across team
- platforms like GitHub and Azure DevOps offer a rich pull request experience
- {benefit} branch policies
- protect important branches by preventing direct pushes, requiring reviewers, and ensuring clean build
- used to ensure that pull requests meet requirements before completion
- teams can configure their solution to enforce consistent workflows and process across the team
- {feature} continuous integration
- {feature} continuous deployment
- {feature} automated testing
- {feature} work item tracking
- {feature} metrics
- {feature} reporting
- {operation} commit
- snapshot of all files at a point in time [1]
- every time work is saved, Git creates a commit [1]
- identified by a unique cryptographic hash of the committed content [1]
- everything is hashed
- it's impossible to make changes, lose information, or corrupt files without Git detecting it [1]
- create links to other commits, forming a graph of the development history [2A]
- {operation} revert code to a previous commit [1]
- {operation} inspect how files changed from one commit to the next [1]
- {operation} review information e.g. where and when changes were made [1]
- {operation} branch
- lightweight pointers to work in progress
- each developer saves changes to their own local code repository
- there can be many different changes based on the same commit
- branches manage this separation
- once work created in a branch is finished, it can be merged back into the team's main (or trunk) branch
- main branch
- contains stable, high-quality code from which programmers release
- feature branches
- contain work in progress, which are merged into the main branch upon completion
- allows to isolate development work and minimize conflicts among multiple developers [2]
- release branch
- by separating the release branch from development in progress, it's easier to manage stable code and ship updates more quickly
- if a file hasn't changed from one commit to the next, Git uses the previously stored file [1]
- files are in one of three states
- {state}modified
- when a file is first modified, the changes exist only in the working directory
- they aren't yet part of a commit or the development history
- the developer must stage the changed files to be included in the commit
- the staging area contains all changes to include in the next commit
- {state}committed
- once the developer is happy with the staged files, the files are packaged as a commit with a message describing what changed
- this commit becomes part of the development history
- {state}staged
- staging lets developers pick which file changes to save in a commit to break down large changes into a series of smaller commits
- by reducing the scope of commits, it's easier to review the commit history to
- {best practice} set up a shared Git repository and CI/CD pipelines [2]
- enables effective collaboration and deployment in PBIP [2]
- enables implementing version control in PBIP [2]
- it’s essential for managing project history and collaboration [2]
- allows to track changes throughout the model lifecycle [2]
- allows to enable effective governance and collaboratin
- provides robust version tracking and collaboration features, ensuring traceability
- {best practice} use descriptive commit messages [2]
- allows to ensure clarity and facilitate collaboration in version control [2]
- {best practice} avoid sharing Git credentials [2]
- compromises security and accountability [2]
- can lead to potential breaches [2]
- {best practice} define a naming conventions for files and communicated accordingly [2]
- {best practice} avoid merging changes directly into the master branch [2]
- {risk} this can lead to integration issues [2]
- {best practice} use git merge for integrating changes from one branch to another [2]
- {benefit} ensures seamless collaboration [2]
- {best practice} avoid skipping merges [2]
- failing to merge regularly can lead to complex conflicts and integration challenges [2]
[2] M Anand, Microsoft Fabric Analytics Engineer Associate: Implementing Analytics Solutions Using Microsoft Fabric (DP-600), 2025
CI/CD - Continuous Integration and Continuous Deployment
IDE - Integrated Development Environments