Best Practices
Ensure Consistent Developer Identity Across Git Platforms
To accurately track developer contributions and avoid duplicate profiles on platforms, it's crucial for all engineers to set up a global Git configuration. This configuration includes your name and email address, which Git uses to identify you across different projects and platforms (e.g., GitHub, GitLab).
Benefits:
Accurate Contributor Tracking: Consistent user information ensures all contributions are attributed to the correct developer profile.
Improved Team Efficiency: Clear identification simplifies collaboration and simplifies tracking progress.
How to Set Up Global Git Configuration:
Open your terminal.
Run the following commands, replacing
First-Name Last-Name
with your actual name andname@example.com
with your valid business email address:Bash
Verify the configuration by running:
Bash
This should display your name and email under the
user
section.
By following these steps, you'll ensure consistent identification across Git platforms and streamline contribution tracking for yourself and your team.
To ensure the accuracy of key software development metrics like waiting time, coding time, and lead time for changes, we encourage all developers to practice regular commits. Our system calculates these metrics based on the first commit associated with a pull request.
Benefits of Regular Commits:
Accurate Metrics: Frequent commits provide more granular data points for calculating metrics, leading to a clearer picture of the development process.
Improved Collaboration: Smaller, more frequent commits allow for easier code review and integration, facilitating smoother workflow and faster iteration.
Early Detection of Issues: Regularly pushing code helps identify potential bugs or conflicts earlier, preventing delays and improving overall code quality.
Shifting Focus:
Instead of a strict "daily commit" mandate, we promote a culture of continuous integration and frequent code updates. This fosters a more collaborative and data-driven development environment.
Additional Tips:
Consider using feature flags to manage code visibility while ensuring frequent commits.
Encourage clear commit messages that concisely explain changes for better code review and future reference.
By practicing regular commits, developers can contribute to accurate metrics, enhance team collaboration, and ultimately deliver higher-quality software.
To gain valuable insights into our development process, we recommend including the associated issue ID in your pull request titles. This practice allows us to accurately calculate waiting time, a key metric that reflects the time elapsed between an issue being created and the first commit associated with the pull request that addresses it.
Benefits of Including Issue IDs:
Accurate Waiting Time: Clear identification of the related issue ensures waiting time calculations are precise, providing a clearer picture of issue resolution efficiency.
Improved Transparency: Including issue IDs facilitates easier tracking of issue progress and fosters collaboration between developers and stakeholders.
Enhanced Reporting: You will be able to track exact timeline of your changes from requirement till production.
Example:
Instead of a generic title like "Bug Fix," use a title that references the relevant issue ID: "DEVD-112: Fix login error message."
By adopting this practice, we can gain valuable insights into our development process and work towards improving efficiency and issue resolution times.
While both rebasing and squashing pull requests have their merits, we recommend using rebasing for contributions to the main branch. This approach offers several advantages for tracking development history within DevDynamics:
Preserved Commit History: Rebasing integrates individual commits from the feature branch onto the updated main branch, maintaining a clear record of the development process. This detailed history is valuable for DevDynamics as it allows for:
Tracing Changes: Easier identification of who made specific changes and when.
Understanding Context: Provides context for code changes, aiding in future debugging or code review.
Collaboration and Review: Rebasing facilitates more granular code review, as reviewers can see the evolution of the code through individual commits.
Finding the Right Balance:
It's important to acknowledge that squashing pull requests can offer benefits in specific situations, such as presenting a clean and concise history for larger features. However, for most contributions, the advantages of preserving history outweigh the benefits of squashing.
Recommendation:
We encourage developers to primarily use rebasing for pull requests. If there are specific scenarios where squashing is deemed more suitable, a clear justification should be provided in the pull request description.
By adopting this approach, we can maintain a clear and informative development history in DevDynamics, facilitating better tracking, collaboration, and future code maintenance.
Last updated