Atomiczne commity i zmiany między projektami

An atomic commit represents a single, complete, and independent logical change to your codebase. Think of it as a small, self-contained unit of work.

This means a commit should either succeed entirely or fail entirely, without leaving the repository in an inconsistent state. It simplifies understanding and managing your project's history.

Atomic commits offer several key benefits:

• Easier Code Review: Reviewers can focus on one specific change at a time.
• Simpler Reverts: If a change introduces a bug, reverting it is straightforward.
• Clearer History: Each commit tells a coherent story, making project history easier to navigate.
• Better Debugging: Using tools like git bisect is more effective with atomic changes.

To create atomic commits, focus on committing one logical change at a time. This might mean:

• Fixing a single bug.
• Adding one specific feature.
• Refactoring a specific function.

Avoid mixing unrelated changes, like a bug fix and a new feature, into the same commit.

Imagine you're working on a file that has two unrelated changes: a bug fix and a new feature. Instead of one large commit, you'd make two:

# Stage only the bug fix
git add -p my_file.js
git commit -m "Fix: Display error on form submission"

# Stage only the new feature
git add -p my_file.js
git commit -m "Feat: Add user profile picture upload"

Using git add -p (patch mode) helps you stage specific parts of a file.

In a monorepo, a single logical feature or bug fix often impacts multiple interdependent projects or packages. For example, updating a shared utility library might require changes in several consuming applications.

These are called cross-project changes, and they require careful coordination to maintain stability.

The main challenge with cross-project changes is ensuring that all related modifications are made and released together. If a change in one project breaks another, it can lead to:

• Broken builds
• Runtime errors
• Inconsistent behavior

This is especially true when components are tightly coupled.

When making cross-project changes, aim for a single, comprehensive commit or a series of logically linked atomic commits. This approach ensures:

• All dependent parts are updated simultaneously.
• The entire change can be reviewed as a whole.
• Reverting the entire feature is possible if needed.

This maintains the atomic principle across multiple projects.

For cross-project changes, unit tests for individual components are not enough. You must run integrated tests that cover all affected projects.

This means verifying that the updated shared component works correctly with all its consumers, and that the consumers' functionality remains intact.

For very large or risky cross-project changes, consider using strategies like feature flags or phased rollouts.

• Feature Flags: Allow you to deploy the code but enable the new functionality only for specific users or environments.
• Phased Rollouts: Gradually release the changes to a small percentage of users before a full release.

These techniques help mitigate risk and allow for quick rollbacks if issues arise.

Which of the following is a primary benefit of making atomic commits in a monorepo, especially when dealing with cross-project changes?

In this lesson, we explored atomic commits and their importance for clear history and easy reverts. We also learned about the challenges of cross-project changes in monorepos.

Key takeaways include crafting single, logical commits, coordinating interdependent changes, and using integrated testing for stability. These practices ensure a healthy and manageable monorepo codebase.