1

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

mike
  • 1,233
  • 1
  • 15
  • 36
lese
  • 539
  • 1
  • 5
  • 24

1 Answers1

3

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"?

alfunx
  • 3,080
  • 1
  • 12
  • 23
  • 1.Thank you for your precious answer, I believe that by saying "are essentially forks" in the last part of first paragraph you meant "are essentially branches" : ) 2.Could you please explain better: add a remote to the other remote? should I add a remote on each repository, each one pointing to the other repo? the remote should be of push type, or fetch type? I think fetch type, but just to be sure – lese Nov 20 '18 at 12:59
  • @lese You're right indeed, what I meant to say is that there is little difference between the terms fork and branch, as far as Git is concerned. You got that right, let's say you're on `old_repo` and want to compare/view commits of `fork_repo`, so you add a remote to `fork_repo`. As long as you only need read access on the `fork_repo`, a fetch type remote would be fine. – alfunx Nov 20 '18 at 14:38