GitClear makes use of its commit processing engine to build a new and enhanced diff view to present code changes from commits and pull requests, saving 30% of code to review in the process.
The recommended and most reliable way to ensure your commit groups and pull requests are processed correctly is to have the associated commits rebased and developed on a single branch.
GitClear should now handle all the branching strategies and aims to cover all the complex scenarios the git history can output.
Some of the factors that contribute to the successful build of pull requests and commit groups are:
Merge strategy
Branching strategy
Number of commits
Number of concurrent branches the commits live on
Git provider API limitations and quota
If you're having issues with getting your pull request to show up in GitClear, drop us a line at support@gitclear.com. Any details on the factors mentioned above would help us diagnose it faster.
GitClear provides in-depth stats into the lifecycle of your team's pull requests from the moment the first commit was authored to when the PR is merged (and even after that).
To do this separation, GitClear employs the PR Opened and PR Closed/Merged events to divide the work done in different phases of a PR as:
Before the PR is submitted - First version of the author's work for the issue they're working on
Under Review - Any revision and updates done to the first version as response to comments or requirements
Post Merge - Any changes to the code in the PR after the PR was merged (in the span of 2 weeks)
It would be most beneficial to align your team's PR process such that the initial authored work and the under review work is clearly separated in order to get accurate and reliable insights into the quality and distribution of work for both phases.
Thus, we recommend that contributors open a PR once they consider their code ready for review.
Opening the pull request before that would migrate any subsequent work to the Under Review phase which would add false positives to your dataset.
On top of assessing the impact of a commit on the repo, GitClear provides a time estimation for the work authored in that commit. We have a comprehensive guide explaining how GitClear handles commit time estimation and the safeguards put in place to avoid miscalculations.
One important piece of the estimation mechanism is to approximate the committer's working hours.
To help improve that approximation we recommend to have your Developers set the correct timezone in their account settings. Though it's usually not a big deal if you don't set this, since we will estimate your time zone based on the weighted average of what time of day your commits are authored. It is still good to set your time zone on behalf of ensuring that the timestamps you see are in your time zone.
Timezone is usually set on account creation but keeping it updated to their current location ensures the committer work day recognised by GitClear is aligned with the real contributor hours.
This can be easily set by going to Account Settings -> Day and Time, from the Profile Menu dropdown found in the top right corner from any logged in page in GitClear.
GitClear is going to great lengths to ensure the data provided to the users is unbiased and noise free. Any outliers that can't be automatically processed will be flagged by GitClear for users to correctly asses them.
The borderline commits page holds any outlier commits flagged by GitClear that show a considerable discrepancy between the assigned Diff Delta compared to the estimated time for author that commit work.
We recommend that Lead Developers review any such borderline commits on a weekly or biweekly basis to ensure consistency and reliable data for all scenarios. You can find these commits by going to Settings -> Review borderline commits page.
If you notice commits have been rejected unexpectedly or aren't scored adequately, we suggest reviewing your File Type settings and the Ignore Masks settings to make sure they're set according to your expectations.
When reasoning about dev work being dedicated to fixing bugs, there are 2 types of data sources a manager should consider. The first type is the readily available bug work being detected by when explicitly linked to bug issues and tickets. The second type is harder to reach and can live under the radar in team sprints and slowly making a dent to the developers velocity.
GitClear can track and plot both of these data types, providing a holistic view over the direction of the development effort.
To setup tracking for issue referenced bug work, we recommend following our guide on linking code to issues .
To setup tracking for unplanned bug work, we recommend following our guide on detecting bug sources. After setting it up, take some time to review how your team compares against the industry benchmarks.