September 14, 2020 at 12:00 am
Comments posted to this topic are about the item Choosing a VCS
September 14, 2020 at 9:01 am
I think that any one who already knows Git coming to a place that is using SVN will have no problems.
SVN is considerably easier to use. All you need is TortoiseSVN installed and that's it. You never ever have to drop to the command line to do anything. With Git it's the exact opposite, doesn't matter what tool you use you will be on the command line regularly.
Whilst Git is great for distributed teams due to being able to grab the whole repo and commit units of work locally and then push back later, for me it's really hard.
The main problem for me using Git is inertia. I briefly had to work on a project using it, it was a team of 2 and I was doing a very small piece of the project and there was no one else local to me (back in the days when you worked at the office). Coming from SVN, I was like a rabbit it in the headlights. I'd try to commit and push changes and it would complain at me and I'd have no clue what to do and waste time searching for how to workaround some inane error message. Meanwhile once I swapped back to my current project using SVN I never had any issues doing simple commits, merges, branches etc... nor did I have to use the command line.
Don't get me started on some of the terminology - push means sending local code to central repo - fine makes sense. Pull Request - means asking the repo owner if they will accept some changes you've made into the repo - makes no sense; given how push is used pull should mean to get central repo changes into local repo.
The main problem in the industry is that you are expected to learn by osmosis (well X person in company knows Git therefore every one does, WRONG!). And when you have continuous 13 week release cycles where once you get to BETA release in week 9 you start the next version. Then keeping all that going whilst trying to figure out the command line values that will do what you need without destroying the repo isn't something that fills one with joy. No amount of home hours learning is going to prepare you enough for what happens when you try to use it in anger on your project because any learning you do will be of the type "hello world" where nothing ever goes wrong and another dev hasn't changed the same file almost in the same place as you.
September 14, 2020 at 9:43 am
I found Bitbucket, with SourceTree installed on the local pc as the interface, is a much more understandable version of Git and never needs a command line. I like the visual of Source Tree branches and it's easy to see what is and isn't merged.
Having had to learn it in one job I now use it for all my own development at home.
September 14, 2020 at 1:57 pm
Where I work, we use TFS, with TFVC. By sheer inertia I strongly doubt that we'll change.
I've personally been using Git for almost two years and love it. I've tried, unsuccessfully to convince people at work to change. At least we use something.
Git does take some learning to do. One reason I started to learn git was because of the distributed nature of it. I was working on a side gig, writing a website for a client. I was using Git. I had branched from master to write the changes I was introducing. Even though I was the only one working on it, I still managed to get myself very confused when I had a conflict trying to merge the feature branch back to master. It took me over a week to figure it out.
One odd thing I'll add. I've heard, too, that newer developers are used to using git. We have several developers who've come here from India. Recent college graduates, too. I've asked them all what VCS they use in college, assuming they'd answer Git. They all answered that they didn't use any VCS in college. Perhaps this is because they're from India?
Rod
September 14, 2020 at 4:31 pm
I started with CVS then SVN and finally to Git (via GitLab). My opinion though, terminology needs to be standardized. GitHub has "Pull Request" to get the source branch pulled into the destination branch. GitLab on the other hand has "merge request" which to me makes a TON more sense.
Now, I do like SourceTree as the git tool of choice for Windows, linux users are left in the dark. They generally are more familiar with the command line and man pages are super handy for figuring out what you need to do (something Windows should look at getting in my opinion). But even with a GUI tool for git, I still find myself dropping out to the command line to do some things only because I don't fully know or trust SourceTree to do what I want when I am doing something like a rebase. And merge conflicts I find to be hard to work with in SourceTree, whereas from the command prompt, it is much easier. Still a pain in the butt, but not as painful.
Fun thing though - when I went to University (15-ish years ago), we had no VCS and I basically did my own version control with folders. Once I got a feature added to my code and it compiled successfully and ran, drop out to terminal/command prompt (did both linux and Windows development) and make a new folder with the version number, then update the readme to indicate what that new version introduced and then repeat.
In linux now there is a tool called "repo" that works similar to git, but can work cross-repositories. So you can set up a git project that is tiny and just contains information for repo to pull all of the required git projects together onto your system. This is something used commonly with Android ROM/Kernel development. For larger projects that rely on different compiled tools, then repo is a good tool to learn.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
September 14, 2020 at 6:26 pm
I started with Visual Source Safe (a long, long time ago), then TFS and we've moved to Git about 2 years ago. It's taken me a while to wrap my head around Git. As others have mentioned, the terminology can be confusing. We are using GitKraken at work and there hasn't been anything I've needed to do from a command line. Maybe it's because I'm not doing anything complicated but I haven't see anyone at work do anything from the command line since getting GitKraken. I miss the simplicity of VSS but I don't miss all the pitfalls and lack of features. And oh how someone not paying attention could destroy VSS. With more features comes a steeper learning curve but in the end it's better than anything else we used.
September 14, 2020 at 7:00 pm
I found Bitbucket, with SourceTree installed on the local pc as the interface, is a much more understandable version of Git and never needs a command line. I like the visual of Source Tree branches and it's easy to see what is and isn't merged.
Having had to learn it in one job I now use it for all my own development at home.
This is exactly how we have it set up at my current job. And as someone who never used any version control before(over 25 years) it was relatively easy to get used to. As others have mentioned I think some of the terminology is a bit weird. In BitBucket I need to do a 'Pull Request' to have my changes/branch 'merged' back to the source. Seems odd to me to call it a 'Pull Request', more like a 'Merge request'. IMHO
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply