DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Understanding Git
  • The Art of the Bug Fix: Boosting Software Quality Through Effective Git Commits
  • Five Software Development Trends
  • Exploratory Programming: Challenges and Keys to Success

Trending

  • Agile Metrics and KPIs in Action
  • Java Parallel GC Tuning
  • Auditing Spring Boot Using JPA, Hibernate, and Spring Data JPA
  • Parallelism in ConcurrentHashMap
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Keep Your Commits Small

Keep Your Commits Small

Every developer understands that small commits lead to excellent performance. This leads to improved accuracy, and makes it easier to change tracking.

Piotr Oktaba user avatar by
Piotr Oktaba
·
Jun. 10, 15 · Interview
Like (0)
Save
Tweet
Share
4.35K Views

Join the DZone community and get the full member experience.

Join For Free
divide
Picture by Oliver Tacke, on Creative Commons

Every developer knows the good practice of performing small commits (at least every developer who has not spent the last few years within a cave). It considerably facilitates change tracking. Commit messages are more accurate and it is easier to learn the purpose of each revision. It is easier to revert problematic changes and use the bisect mechanism to find specific commits. And if you are pushing your changes as frequently as commit, you will not lose weeks of work by an accidentally entered command or disk crash.

However, the practice is not only about commits. The whole development process can greatly benefit from it. As a result, each small commit should go through it separately. It starts with a small local change commit and push. It is followed by a slight review, possibly by a pull request. Next there is a small integration to the main development branch (or feature branch) and Continuous Integration system execution, usually running all tests against the change. The process of course can slightly differ depending on a specific project and company.

Such an approach has many benefits. It solves a lot of problems encountered during large commits and their integration. Here are the most obvious and visible ones:

  • reviewer can detect early whenever a developer is going in the wrong direction - there are no situations when a developer left alone for a week will implement a solution that is a dirty hack. It reduces wasted development time, and moreover, prevents situations when such implementations are accepted due to the time pressure,
  • reviewer or specific project owner can maintain a clear picture what is under development - thanks to small reviews he is up to date with all current changes. It is easier to foresee potential problems within the project,
  • small pull request/change is much easier to review - large changes are very troublesome to review and drains a significant amount of energy. Often they are not performed diligently and thoroughly enough. As a result, bugs may slip into the product,
  • it is easier to measure the development progress - issue status is more visible in comparison to situation where developers are buried for a week within their tasks,
  • it is easier to maintain good quality and proper code coverage - with small changes it is easier to incrementally improve it. There is no situation where some developer was coding for weeks and then needs to adjust his/her code to the quality rules and write tests (so much against TDD),
  • CI integration is much easier -  small changes have lesser chances to break something and are easier to fix. There is also a lesser chance that such commit will conflict with other developer changes,
  • there are no major conflicts between several developers changes - there will be no situation where three developers implementing three different features would solve the same problem in three different ways resulting in difficult conflict resolution and major refactoring of their features.
sizes
Picture by Edwin Torres, on Creative Commons

Which change is small and which is not? The size shouldn’t be judged on time spent by a developer on it. Most of us were in the situation when a week of effort resulted in 20 lines of code. Not very good but still a fair enough measurement is lines of code. Reviewing about 200 lines shouldn’t take more than an half an hour (of course, as always, this depends on the project and technology) and should not be a very troublesome job. Some developers prefer even smaller changes. The clue is that you should feel that the changes are small, light, and can be easily pushed through the whole development pipeline.

Depending on the project, there will be more or less different advantages from such an approach. However, no matter what project methodology you are using, additional effort would pay off for sure. It will not only facilitate the development process, but also keep your team moving smoothly and motivated.

Commit (data management)

Published at DZone with permission of Piotr Oktaba. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Understanding Git
  • The Art of the Bug Fix: Boosting Software Quality Through Effective Git Commits
  • Five Software Development Trends
  • Exploratory Programming: Challenges and Keys to Success

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: