Why corporate choose Git instead of SVN.
The learning curve of GIT is quite longer than SVN. I think it make the team productivity low.
For further actions, you may consider blocking this person and/or reporting abuse
Why corporate choose Git instead of SVN.
The learning curve of GIT is quite longer than SVN. I think it make the team productivity low.
For further actions, you may consider blocking this person and/or reporting abuse
Oldest comments (38)
Sadly. Need to teach new developer how to use Git. Do you have any suggestion for tutorial?
I learned how to use git from this course in udacity, it's pretty good udacity.com/course/how-to-use-git-...
The Atlassian Git Tutorial is the best introduction to git I've found.
What do this mean?
Which is better? As Git is selected by corporate, I need to teach new developer how to use this.
Not exactly a tutorial, but Gihub has some nice Cheatsheets: services.github.com/on-demand/reso...
I use learngitbranching.js.org for the beginners to learn the basic commands. With this game they can do so in a few hours on their own. HF.
From my own experience, and that was 10 years ago, here are some personal thoughts on the subject.
SVN puts hidden subfolder into every subfolder in your project, while Git keeps all the the data it needs in single .git in project root directory. Very annoying when you are trying to upload something with FTP
I also seem to remember SVN always copied all files instead of changes for some reason, so it took a lot more space.
Again I don't know if SVN has changed since, but with Git you could commit on your local all day long, then push changes when you want, and it wouldn't mess things up between you and co-workers, while I believe SVN you had to keep it synced all the time?
While Git workflow can get a bit tricky, you can use common conventions like gitflow, but if your team only needs to share changes between members, you all can just push/pull from master.
As for choosing between Git or Mercurial, if you use a GUI tool like Sourcetree, that can work with both, doesn't matter what engine you use per say, as you won't touch command line.
SVN annoyed me for the exact same reason: folders everywhere... "Git tracks files not folders", isn't that a claim somewhere git-related?
That might be, I'm pretty sure you can move files from one folder to another outside git CLI (I know there's specific git command for it as well), and git figures out that file was moved and keeps history intact.
Yes, I think the quote I mentioned refers to empty folders which aren't tracked without some trickery like a
gitkeepfile or something similar.This hasn't been the case for quite a long time. You now have a single .svn in the root, just like with git.
The .svn contains a "pristine" copy of the file in your workspace. This is an exact copy of the file when checked out. It is just one version of the file.
Git on the other hand stores all versions, from the cloned repo. Unlike SVN, GIT compresses the files. For a repo with a few versions it will be smaller, but once the repo grows it will start to consume more space than SVN does.
SVN is still centralized, committing is always to the server. You won't mess things up between you and your co-workers unless people are working on the same files.
Like I said it was quite long time ago, would be surprised if SVN didn't improve. Good to know.
Whether you or others like it or not, git is the de facto version control right now, as developers/managers we in some ways have a responsibility to make sure we/ our developers have current skillsets.
Having said that, it doesn't mean that git is better. I love git so I am biased, but that doesn't make SVN bad.
Reasons I like git:
Differentiating between local and remote repositories. I haven't used SVN a ton, but correct me if I am wrong, if a change is made, it must be propagated to the remote machine, and thus to all users. With git, changes are made locally, revising and changing local history is simple. So that commits created are easily made atomic. Then once you are happy with your changes, you push them up to the remote.
Git was built with branching strategies at the forefront, branching and merging for SVN is still pretty wonky.
It all comes down to workflow. For me personally, the way that I think of git is that branching is cheap. It's easy to create branches, it's fast, and I don't need to worry about manually using
svn copyor anything like that to have a branch-like structure.If you need to learn about git, I really like git-scm.com/book/en/v2 it's available online, it's free, and it will really tell you quite a bit of how git is working in the background.
Change for the most part is a slow process, no matter how you look at it. Embrace it! It sounds like this was forced on your team. I would say a good attitude will go a long way to making the change more manageable. Best of luck!
Can't say much about the Mecurial part but you're right about that most - not even small - teams don't need that much of the feature set.
git add, commit, pull, push, branch, status, log and reset from time to time.
Also there are some really nice GUI available.
I haven't really put much thought into other version control solutions. But apparently there are a few. What are they and how is one better. And does everything have to be a tree?
Despite potentially being more complex, git tends to be more forgiving: you can typically revert inadvertent changes, try things out in lots of branches, fork again from some point in the past, work together with lots of people on the same thing, commit lots of (partly) duplicate things, and it's generally manageable and won't explode in your face.
The important thing about git is that you don't need to use all its advanced features. And IDE support for it ranges from reasonable to excellent, meaning that for a lot of usage it can keep out of your way / just work.
The benefits of a disconnected/decentralized repository (even in a corporation), easy branching, relatively good conflict resolution out weights any learning curve it may have. Coming from using TFS and SVN in a corporation, there is no way I would go back.
Nice thoughts, but i have to say despite everything: man, i really like git : )