It seems that it is suggested we can commit often to keep track of intermediate changes of code we wrote… such as on hginit.com, when using Mercurial or Git.
However, let’s say if we work on a project, and we commit files often. Now for one reason or another, the manager wants part of the feature to go out, so we need to do a push, but I heard that on Mercurial or Git, there is no way to push individual files or a folder… either everything committed gets pushed or nothing get pushed. So we either have to revert all those files we don’t want to push, or we just never should commit until before we push — right after commit, we push?
The best way to manage this (whether you are using Mercurial, Git
or any other revision control system) is to make sure your work
is done on branches which correspond to these “parts of
features”. If there is even a small chance that some portion of
work will need to be released independently from other work, it
should have its own branch from the start.
This gives you the flexibility to push just the “part of the
feature”, and is much better suited in the case where the “part
of feature” and some other “part of the feature” both contain
changes to the same file.
The nice thing about using Mercurial or Git here is that managing
these branches is trivial, so the cost to creating and using
them (even if they turn out not to be necessary) is minimal.
Now, you can’t always foresee everything. If you do end up stuck
in the situation you describe, though, it’s easy to get out
of. Say you had 100 changesets locally (not yet on the server) and you wanted to just
push the current contents of 1 file. Create a clone of the
repository you’re working on back to the server revision, copy
the file over, commit, push, and integrate back. In Mercurial
this would look something like the following: