Xian Nox wrote:what's the point of not pushing the local development/testing branches?
Because that's a developer local work. There he can try new stuff and such things. This is not needed in the central repository. If some other dev B wants to check this dev A work, he can simply pull that branch from him/her. No need to confuse things in the central repository level, let alone branch naming conflicts and such.
Xian Nox wrote: what do you do in git to mark them to not be pushed?
Branches that have no remote configuration cannot be pushed anywhere
Xian Nox wrote:I've also found them incredibly useful for synchronizing code between Linux and Windows on a dualboot because of no proper ext4 drivers.
I use NTFS for that, because sometimes I might be offline.
Xian Nox wrote:when is the proper time to commit code? I mostly do it when I find the changes made are significant enough (for which I have no actual definition), or when I need to test on the other OS.
I think you mean pushing to the remote server, am I right? That's up to the developer or the accorded protocol. Same goes for local commits (in Git these local commit will simply be pushed to the remote repository -and meged if fast-forward is enabled, though I don't recommend activating fast-forward pushes if you don't know what you're doing like me
- ).
Xian Nox wrote:Does commit size even matter?
I never heard anything about that, so I guess it does not. Might be a problem if you're trying to push too much/too large commits over a slow/unstable network.
Oh and btw Git also has
cherry-picking, where you can pick individual commits to be applied to your current code as new commits. Oh and stashing. This feature only deserves using Git.
EDIT: oh, and rebase or merge branches... And
you can learn Git without even having to install it