CODEWITHSUNDEEP
gitsvnversion-control
MiamiBeach
MiamiBeach

Reputation: 3497

Explanation of the differences between GIT and SVN

I come from an SVN background, and I have a hard time grasping Git's philosophy. In particular, I'm confused by the following.

  1. Imagine I have made some changes in my working dir. If I switch to another branch, the changes remain, which is very unusual, from an SVN point of view. This means that uncommitted changes are shared between the branches. Moreover, the "stage property" of the files is also shared between the branches: if I call git add * in one branch, then all the files will be added to next commit in all the branches. Looks like my branches differ only by already committed files.

    So, if uncommitted data are shared, then, no matter which branch I am on now, I will commit all the staged files, even if they were added in different branches! As I come from an SVN background, this strikes me as very odd.

    Am I correct, or am I just confused? Why does Git work in this way?

  2. Sometimes, Git tells me something like this:

    Cannot switch to another branch because your changes will be erased. Commit them first.

    In SVN, that's not a problem: branches are independent. Why and when does this happen in Git?

  3. What's up with the way Git handles folders? If I create a new folder, it is not displayed in Git's status report. Does Git simply not care about folders?

Upvotes: 1

Views: 316

Answers (1)

dseminara
dseminara

Reputation: 11935

Welcome to GIT :) There is a Git way and it is different from SVN way

  1. There are three trees: HEAD, Working Copy and Stage (see http://www.infoq.com/presentations/A-Tale-of-Three-Trees), any uncommited change you do on working copy and stage will not be added to any branch unless you commit them. So uncommited changes are not shared between branches, and in fact, uncommited changes doesnt belongs to any branch until you commit them. When you commit your changes, your changes will go to only ONE branch (you can commit same changes to different branches using extra commands too, but it comes later)
  2. That is because you cannot switch to another branch because your changes will be erased, as general rule, you should do checkout (for switching and optionally creating branches), pull, push, merge, rebase only if you have ALL changes commited. Of course you can do this with uncommited changes too, but it is not recommended
  3. Git was not designed to handle empty folders, so,if you need to have an "empty" folder in your repo, you need to create a hidden file inside the folder (by convention, you can name it ".gitkeep")

Summary:

  • On git, there is three basic kind of operations: creating commits (using git add, git commit), handling commits (git merge, git rebase, git checkout), and syncing (git push, git fetch)
  • Handling commits (merge, rebase, etc..) is a lot easier on committed changes, merging uncommited changes is the WRONG WAY in git
  • Always COMMIT FIRST and make sure there is no uncommited changes before doing something else (i mean, handling commits like pull, merge, rebase, etc...), if there is uncommited changes remaining on your WC/stage and you don't want to commit them, use git stash (and if you want retrieve the changes again using git stash pop later)

Upvotes: 1

Related Questions