Normally you commit per user story. You can commit multiple times per story, but not multiple stories in one commit for trackabliity. You can commit after small small changes, it’s just not very efficient.
As Jop already mentioned. Comitting per requirement is a good practice. If the requirement is large you will probably make small chunks of functionality and commit them in these small chunks.
A good practice is to not keep changes open for a long time on your personal computer because this can result in conflicts with other team members and loss of work (in case of damage to pc or if you lose it).
Additionally when you commit it’s good practice to have a descriptive commit saying what you changed and possibly link it to the requirement for trackability. Do not Commit with “WIP” and expect people to understand what’s happening.
A fun analogy that I came across once was to see version control and committing as Rock climbing.
(1) When you develop your app you start climbing the mountain
(2) When you commit you put an anchor into a rock.
(3) Should the app ever face a serious issue and become unstable than you have the ability to fall to a previous anchor that will secure you and you should only ‘fall’ a few meters.
This might give you some insight of when it’s okay to commit… the larger the changes on your development environment, the harder you can fall if your system becomes unstable when you do not commit regularly
Hope this helps!
To anwer your First Question, – We should commit the functionality/behavior whatever we are developing, Let say if you have to call an API and use that value for XYX….. so for this scenario make this complete change all together and commit. Most of the people are following this practice .
To answer your second Question. – Obv you can commit any small changes also, but………. it will make you work more complex. Since once you commit then again you need to work on that and, if your team member is trying to reuse(let say Partially developed microflow), and after that if you are making any changes ,then complete effort will go in vain. I hope you understood the cons of unnecessary commits.
That’s personal. With smaller commits, it can become chaotic. With bigger commits, the commit itself can be chaotic.
Personally, I prefer small “encapsulated” commits (does not always happen in practice). It’s trackable, but also possible to revert.