How to track two version of a project in one GIT repository?

I have two versions of one project in one local git repository. I have to commit this repository into 2 remote repositories, one for each version;

LOCAL GIT(V1/V2) -> REMOTE GIT(V1), REMOTE GIT(V2)

I have some files开发者_StackOverflow in the LOCAL GIT repository which should only go to REMOTE GIT(V1) and other should only go to REMOTE GIT(V2). Now I commit full local repository to both remotes. Can I only commit some files to REMOTE1?

I need to have both version of the project in one repository, but would like to have an options to divide history a bit. I do not think that any branching can help as then I would have to make the same changes to both branches mostly. Most of the code, 90% of the code is the same for VER 1 and VER 2. New code is usually the same for both versions.

Branching is exactly what you need. Branching is easy and very quick with Git, so you don't lose anything but a few more keystrokes.

You can use 3 branches. Create a "common" branch where you'll work on stuff common to both "forks" and merge into them after commits. For specific stuff, work in one of the branches.

Git uses hard links on the filesystem so branches are cheap both in terms of speed and used space.

Finally, you can always select which branch to push/pull.

Create three Git repositories: core, app_1, app_2. Within each of the app repositories, create a Git submodule referencing the core repository.

Treat the core repository as a pure library and the app repositories as pure library consumers, structuring the three projects such that you can keep everything common to the two "versions" in the core repository and everything that would diverge between the two versions in the app repositories. Structure the app repositories such that the core project can be placed wholesale, with no modifications, into a subdirectory within the app repositories. You may require a minimal common initialization script shared between all app repositories, but that is a small price to pay.

The scenario of structuring the code this way is very common. Although using Git in this way to support this code architecture scenario is far less common, it is seen as a viable possibility.

Sounds like you need to be using submodules git-submodule. You would store the common code in the main repository, but then store the separate versions in submodules. You can't split history with git. Each commit is cryptographically based on content and parents.