There are many git workflows that modify history, delete commits, resolve conflicts, and more. While this article outlines the most common workflows and impacts we see in Flow, we cannot anticipate every combination of actions and outcomes.
When using this information to understand what metrics you should expect, first understand what is normal for your teams and your organization. Then use that data to set targets to drive improvements. Every organization’s practices are different and impact how metrics appear in Flow.
Note: Any changes that modify commits and commit history will change your commit metrics as those changes happen.
Branches
Flow is branch-agnostic. All commits available in the remote server for a repository will be imported to Flow, regardless of the branch they’re on. Flow does not display which branch commits are on.
Deleted branches
Flow does not prune deleted branches from our copy of your code repository. All commits ingested by Flow remain in Flow, even if the branch they exist on is deleted. Flow does not ingest previously deleted branches.
- If a branch is not merged into another branch and is deleted before all commits are processed, only the previously processed commits appear in Flow. Any commits made between the last process and the time the branch is deleted will not appear in Flow. Previously processed commits are not removed from Flow.
- If a branch is not merged into another branch, but is deleted after all commits have been processed by Flow, all commits will continue to appear in Flow.
- If a branch is merged into a main branch and then deleted, all commits will continue to appear in Flow. Depending on timing, Flow may have processed both the commits from the branch as well as the commits once they’re merged into the main branch. However, these commits will only appear once each in Flow, since Flow deduplicates commit data in reports.
Note: If you delete and re-add an integration, or your data is re-ingested for any reason, no commits from previously deleted branches will be ingested. This will change your metrics and commit history in Flow if any commits from deleted branches are currently present in the data.
Deleted commits
There are multiple workflows in git that can delete or remove commits from the history.
Deleted commits from live branches are removed from Flow when the deletion is processed. If a commit is deleted from a branch but is still present on another branch, it will remain in Flow.
If a commit is deleted, then the branch is deleted, Flow will only remove the commit if it processes the commit deletion before the branch deletion happens.
Cloning repositories
If you clone a repository to your local machine and work on the code there before pushing changes back to the remote repository, Flow cannot show metrics from those local commits until they are pushed to the remote repository because Flow cannot see code on your local machine.
Additionally, Flow only processes the commits you push to the remote repository, not anything you deleted, edited, or otherwise modified locally.
When Flow ingests your commits from the remote repository, it uses the local commit author date and time to calculate commit metrics like Commits per day or Coding days.
As an example, if you commit locally on Tuesday and Wednesday, then push your work to the remote repository on Friday:
- Flow will not show any of your commits until after it processes your data Friday
- Once your data is processed, Flow shows commits on Tuesday and Wednesday, giving you two Coding days for the week
- No commits are displayed for Friday, even though you pushed the commits on Friday
Reverting commits
Reverting a commit adds a new commit to the history to reverse the changes made by a previous commit in the repository.
This new commit counts toward all coding metrics like Coding days, Commits per day, etc.
Depending whether the original commit author reverted the commit, and depending on the time between the original commit and the reverted commit, this new commit could count as Rework, Helping others, or Legacy refactor. If it counts as Rework, the new commit will impact Efficiency.
Amending commits
If you amend the most recent commit on a branch, you modify the most recent commit with updated information, including author, date/time, commit message, and files. Flow updates the commit to the latest information, so if you regularly amend commits, the metrics associated with those commits will change every time the commits are amended. Amended commits get new SHAs, so the old SHA will disappear from Flow and the new one will replace it. This process is similar to the one for deleted commits in general.
Forked repositories
Forking creates a new repository which shares the code from the repository you forked. In some cases, forked repositories are not intended to be merged back into the original repository. In other cases, you might fork a repository that you can't directly modify, and then create a PR to request changes.
Because forking creates new repositories, they must be imported in Flow for commit data from them to appear. If you have auto-import enabled and the forked repository is part of the same integration, any forked repositories should be automatically imported. If auto-import is disabled, you must specifically import any forked repos you want included in your Flow data.
Note: Make sure the Show forks toggle on the Available tab of the Repos page is toggled on to see forked repos you can import.
If the forked repository belongs to an integration not yet set up in Flow, you must set up the integration to begin importing data. If a developer forks a repository into their account instead of the organization used to set up the integration, their organization must be added as an integration to see metrics from the code in that repository. If a forked repository is merged back to the original repository via PR, the data from the forked repository will be included in the original integration in Flow the next time the repository is processed.
Shared commits from the history of the forked repos and the original repo are deduplicated by Flow so each commit appears only once.
Squash and merge
Because there are multiple ways to squash commits as part of your process, the way the data appears in Flow can vary based on your practices and the timing of your commits.
Note: The most important thing is to understand how your organization practices squashing. Use these practices as context to establish baselines of which metrics will be most useful for you.
If you squash locally before you push to the remote server, Flow can only ingest the commits that exist after squashing.
If you push pre-squashed commits to the remote server and then squash, Flow may or may not display your pre-squashed commits:
- If Flow ingests commits from a branch before they are squashed, then the commits are squashed but the branch is not deleted, Flow will initially display the pre-squashed commits, then remove them as deleted commits once the squashed commit is ingested
- If Flow ingests commits from a branch, then they are squashed and the branch is deleted without merging to another branch, Flow continues to display the pre-squashed commits but does not include metrics associated with the squashed commit.
- If Flow ingests commits from a branch before they are squashed, then the commits are squashed and the branch is merged into a different branch before being deleted, at which point Flow ingests data again, then Flow displays both the pre-squashed commits from the deleted branch as well as the squashed commit that was merged into the other branch.
- If Flow ingests commits from a branch before they are squashed, then the commits are squashed, the branch is merged, and Flow ingests data before the branch is deleted, Flow will initially display the pre-squashed commits, then remove them as deleted commits once the squashed commit is ingested.
- If Flow does not ingest commits from your branch before they are squashed and merged, then deleted, Flow will only display the squashed commit and will never ingest the pre-squashed commits.
The timing of when you squash and merge commits affects how Flow displays your data. In general, it’s best practice to squash commits in a short timeframe and not squash and merge commits spanning multiple days. This process is designed for smaller commits and more frequent merges which are typically same-day.
Metrics affected by squashing
In addition to the commit metrics affected by other git workflows, there are a few additional metric impacts to understand:
- Depending on your workflow, PR metrics associated with iteration, such as PR iteration time, will be dramatically changed, since follow-on commits may be squashed and removed.
- Similarly, you may see an increase in Reaction time and Responsiveness.
- Because both the pre-squashed commits and the squashed commits can be included in metrics, you could see a higher HALOC than expected.
- Coding days and commits per day can be lower.
- New work will be higher and Rework will be lower, since code reworked between the first commit and last commit that are part of the squash will not be counted as rework in the squashed commit.
If you’re part of a mature organization, we wouldn’t expect you to measure these specific metrics, but, regardless, the most important thing is to understand your organization’s baseline and interpret your data using that framework.
Rebased commits
When you rebase commits on a branch, the previous commits are removed from the branch and new rebased commits are added to the branch.
If you rebase commits on a branch after they’re imported by Flow, then delete the branch without merging to another branch before the new commits are processed, Flow will only display the original commits, not the rebased commits.
If you rebase commits on a branch, merge the branch into another branch, then delete the branch with the rebased commits, Flow will only display the rebased commits. The original commits will be deduplicated and deleted.