1

I am migrating my project from SVN to GIT, I am having hard time in understanding the difference between the terms in both the version control systems.

In Subversion, each developer used to have their own branch and we used to make changes and merge it with the Trunk and then merge Trunk to our branches to get the updated code.

In Git it seems to be little different. Is fork and clone something that I should look for? for letting each developer work independently. In that case how will I get the changes made by other developer who pushed the changes in master(remote) and how will the other developer get the changes made by me that I pushed in master(remote).

Sorry for perplexing language, I am too confused between GIT and SVN, finding it hard to explain.

Thank You

Luke W
  • 8,276
  • 5
  • 44
  • 36
Neetigya
  • 121
  • 2
  • 10
  • 3
    The concept of branching is roughly the same in both Subversion and Git. The major difference between the two is that Subversion is a file based version control tool, while Git is _project_ based. When you commit in Git, you take a snapshot of every single file. You should review a good tutorial on Git and then come back here with a more focused question. – Tim Biegeleisen May 23 '17 at 15:12
  • I just wrote two things on "coming to Git from SVN" recently (one a few days ago, one this morning): see https://stackoverflow.com/a/44142829/1256452 and https://stackoverflow.com/a/44081446/1256452 – torek May 23 '17 at 21:40

1 Answers1

0

I understand it's perplexing coming from svn. The concept of a 'branch' doesn't even exist in subversion (a a branch is just a plain directory that developers agree to see as a branch, but not a separate concept from svn POV). If people use git rationally, they (each one of them) will have at least a repo of the project on their own computers. Assuming that they all cloned from a "central" repo that has the branch "master" (not mandatory, but let's assume), then people will probably end up with a local "master" branch (that started from origin/master... this is a new concept from subversion: origin is a remote for a local repository. A remote is just another repo... a local repo can relate to many different remotes, and each one is synced/tracked on your local repo when you fetch/pull).

Here's another major difference from subversion: let's assume developers start working on their master. At this point, they are diverging. But how so if they are all working on "master"? A fair question. Sure, on "master"... but it's their master (like, each repo has a master branch) and they are working (committing) independently.

After a while, they will want to "merge" what they did into a common branch, right? There are maaaaaaany workflows to get this done:

  • using a central repo wheere everybody commits onto a single branch, a-la-svn, say
  • using a central repository where people will commit using a separate branch each
  • Developers publishing stuff on their own repos (with git daemon, say) so other developers can pull from them without a central repo

That part is veeeery flexible.... well, I think all parts are veeeery flexible with git. https://www.atlassian.com/git/tutorials/comparing-workflows

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • Lovely, especially this one "Here's another major difference from subversion: let's assume developers start working on their master. At this point, they are diverging. But how so if they are all working on "master"? A fair question. Sure, on "master"... but it's their master (like, each repo has a master branch) and they are working (committing) independently". it answers many questions and I took few tutorials as Tim mentioned in comments, I am starting to feel comfortable with git. Thank You – Neetigya May 23 '17 at 17:20