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 copy or 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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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!