This is not a factory in the "classical" sense - there'd be an interface (e.g., IGitCommandFactory) and factory method (e.g., Create<TGitCommand>(params object[] args)). But that'd mean an extra layer of abstraction and perf costs (e.g., boxing of valuetypes).
Also, the callsites look kind of awkward too, e.g., GitCommandFactory.CheckoutBranch(....).
The fact that this type and its members are static isn't great either (this may affect testability), but we can revisit this later, if required.

I suggest renaming this to simply GitCommands and have all the implementations in the same file as it facilitates the discoverability of the type when browsing the repo and the maintenance.

I have renamed it to GitCmd because we already have a namespace GitCommands. It did not compile without specifying the parent namespace: Commands.GitCommands.CheckoutBranch(...)

Boo... I kind of missed that.
Please let me think about this, the namespace naming here is shoddy to say the least... GitCommands.Git.Commands. We can definitely improve here making the API much more pleasant to use.

I propose the following:

• Remove "Commands" folder and instead create Commands type that would contain all implementations for git commands.
• Turn GitCommand class into a private nested class of Commands class.
• Remove GitCommandHelpers class and move its implementations to Commands class.

This may sound a little drastic, but I think that would consolidate the API and make it much more cohesive.

I have implemented all the proposals regarding Commands type.