At the new workplace where I work, in the past, the main project was split in two branches, because different customers began to have very different requirements. A pretty common scenario I guess.
Now, I'am not a developer but a sysadmin, and not an expert of git, but I was wondering if in these cases usually is the correct approach to use branches, because in my understanding a fork would be more adapt.
What the CTO is asking me to do, is to migrate this branch, into a new git repository. But he also says that he wants to still be able to perform comparisons between commits, therefore (in eclipse + egit) to right-click on workspace > team > show in history > select the commits he wants to compare > click on compare to each other. I believe that these requirements conflict to each other, so my main question is: is it possible to compare commits of different git repositories?
My second question is, if a project with the same core that starts to require different features, should be branched forked or moved to a new repository?
Hope my question is not too broad
There is no concept called fork in Git. Git hosting services, such as Github or Gitlab, provide such a feature. As far as Git is concerned, a fork is essentially just a branch. And also, every clone of a repository - even local repositories - are essentially forks.
To split up your repository into two repositories that have a fork relationship, first just create a clone of the repository. And then delete branches in both repositories that refer to commits of the now-other-repository.
The usual approach to compare forks is to add a remote to the other remote. This is possible in your case too, since you have common commits in both repositories, before the forking-point. More on remotes here: What is "git remote add ..." and "git push origin master"?