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
Ben Halpern -
Abraham Romero -
Vinod Kumar -
Shafayet Hossain -
Top comments (38)
Even just a single person benefits from using a good DVCS system over SVN/similar. SVN etc. are painfully slow, can't deal with branching or even just properly tracking changes, and are in so many other ways obsolete.
However, just picking Git because everyone picks Git is stupid, as is the case with most tools. Mercurial definitely is better for most uses. Then there are special cases (e.g. games etc.) where something like Plastic SCM is better.
The only workable GUI I know for Git is GitKraken, and that's a fairly recent thing. SourceTree supports both, but isn't great on either. TortoiseHG is what I typically use with Mercurial.
The worst thing about Git is that it was written by a kernel programmer, a person who has literally no idea of how human beings function and think, and really didn't care. Most commands in Git are much more confusing than they need to be, whereas Mercurial is trying to work in a predictable and understandable manner.
Just the amount of people who "proudly" present how many aliases they've set up on their machine to make dealing with git more reasonable is a good sign of this. I've never found a need to make a single shell alias to work with Mercurial.
It really terrifies me how many people think using Git from the CLI makes you cool or something, and then because they can't figure out how it works they just do a blind
git add -A && git commit -m '...' && git push -f.. and people seriously just usepush -finstead of trying to understand what is wrong when they've got 5 heads on a branch that should be merged, or they've not pulled other people's changes.With a GUI you tend to see exactly what changes have been made, you can view the per-file side-by-side diffs easily to confirm it's what you think it is, commit what you wanted, and then see the different heads easily.
There's also Git-Tower (git-tower.com). But it's Mac/Win only :-(
"It really terrifies me how many people think using Git from the CLI makes you cool or something[...]"
Perfect point
I don't think it's necessarily "cool" but I genuinely have trouble using GUIs for these sort of things.
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.
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.
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.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.
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!
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 last time I had to use SVN was about 10 years ago, but I remember that I had merge conflicts that I needed to resolve ALL THE DAMN TIME, and with git I encounter them rarely (when two folks touch the same line). Git just knows how to merge things.
And the learning curve isn’t bad; there are dozens of svn-to-git tutorials. In fact I’d be very wary about the productivity of any developer who has a really hard time learning the basics.
My experience is that the learning curve at least to start with isn't any different, because day-to-day git use for a developer is practically the same as day-to-day svn use, just the commands are spelled differently. There are only two major differences. First, you need to remember to
git push. Second, branching and merging is much easier and you won't have to jump through so many hoops for it to work reliably.SVN is really antiquated when it comes to modern development flow. That said, git may not be the answer. It has a lot of features, but they're wrapped up in a garbage command-line interface.
A tool like
bzrsupports the same modern branching and process but offers a much cleaner command-line. There's less chance to mess up. There's of course fewer features, but as others have said, most teams don't really need git's full feature set.I also believe that when people say
gitthey often mean GitHub as well. It's that layer of tools on top that make it powerful.I think cheap feature branches are the killer feature of git compared to centralized SCM systems. And those are useful for any team with at least 2 people. Git is also super fast!
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.