Actually it's a GIT question, although GIT is relatively new in Mendix, it's universally applicable.
I'd try to avert local commits as much as possible, but I'm glad my work is fully saved in its own commit whenever I'm 'later' than a push from a colleague.
Why should you use (multiple) local commits:
Committing locally in Git serves several important purposes:
Version Control: It allows you to save snapshots of your project at various stages. Each commit represents a point in the project's history, making it easy to track changes and revert to previous versions if needed.
Backup: Local commits act as a backup of your work. If something goes wrong, you can always go back to a previous commit.
Collaboration: When working in a team, committing locally helps you manage your changes before sharing them with others. You can make sure everything works correctly before pushing your commits to a remote repository.
Branching: Local commits are essential when working with branches. You can experiment with new features or fixes in a separate branch without affecting the main codebase.
Documentation: Each commit message can serve as documentation, explaining what changes were made and why. This is helpful for both you and others who might work on the project in the future.
Why you shouldn't use local commits too much:
Lack of Backup: Local commits are not stored in the cloud. If your local machine fails or gets lost, you could lose all your work. Pushing commits to a remote repository ensures your work is backed up and accessible from anywhere.
Collaboration Issues: If you're working in a team, keeping commits only locally can hinder collaboration. Other team members won't see your changes until you push them to a shared repository, which can lead to conflicts and miscommunication.
Limited Access: Local commits are only accessible from your machine. If you need to work from a different device or location, you won't have access to your latest changes unless they're pushed to a remote repository.
Continuous Integration: Many development workflows use continuous integration (CI) systems that automatically build and test code when changes are pushed to a remote repository. Keeping commits local means you miss out on these automated checks and feedback.
Good question, when you're committing locally you're not pushing your changes to the central repository yet, meaning you can 'commit' to a certain amount of work whilst it's not done yet. This gives you control over when you want your changes to go into the codebase.
Committing locally means you have a local saved version of your work; if for some reason you have to reset your changes, you won't lose your in progress work.
If you're working with feature branches, or the only one working on a certain branch it won't really make a difference.