Soldato
Not sure what book you've ordered, but there's a pretty good free one available on the website as well: http://git-scm.com/book.
How useful is git?
- Thread starter hargi
- Start date
How wrong can you be in one reply?!
Git is an absolutely fantastic tool irrespective of whether you are working on your own or not. How can you keep accurate track of changes without a version control system? How else can you easily keep a stable version of the project whilst developing a new feature?
Git is also fantastic at enabling you to make many branches so you can have several different bits of work/experiments on the go at the same time.
I always work with Git (and Github) with all my projects. If you invest a little bit of time in learning about it, you be rewarded back 100 fold.
Does git integrate well with VS2010?
I've read around I've heard some horror stories when git is used with VS (basically VS becomes unusable, where git uses too many system resources).
What extensions do people recommend for use with VS2010.
I've read around I've heard some horror stories when git is used with VS (basically VS becomes unusable, where git uses too many system resources).
What extensions do people recommend for use with VS2010.
Soldato
Mostly I've used mercurial, SVN, and prior to that, straight up making copies of project folders. 
Caporegime
Caporegime
No idea, I don't use TFS, just saw MS were spamming that it now supports git. 
Mostly I've used mercurial, SVN, and prior to that, straight up making copies of project folders.
This is what I do.
I 'rar' the folder and give a name to the rar file, which gives a rough idea of what changes were made since the last version.
git sounds like a much more advanced system, though I am worried it will slow Visual Studio down.
Git just sits in a folder called .git under your root project folder. It lies dormant until you ask it to run a command like git status or git add . (wildcard add everything that's not currently tracked). Then it will need to check ever file against it's index by working out a hash of the file so it's only slow if you have massive files or a massive amount of files. There's no performance loss when working in VS. It isn't a service or agent that's always running unless you use some kinda crazy VS plugin.
Manually backing up code in a rar sounds pretty damn crazy really check out the guides on how to use git properly. After all git is pretty much just a versioned file system internally.
Manually backing up code in a rar sounds pretty damn crazy
really check out the guides on how to use git properly. After all git is pretty much just a versioned file system internally.
Last edited:
It typically takes about 1 minute for the full back up and renaming to be completed. The duration is limited to how quickly you can write up the detail of the what work was done since the last change and the time it takes to "rar" the folder.
What plug-ins are people using to connect Visual Studio 2010 with git?
I spent about an hour looking at git yesterday and felt that I wasting time on something which is not essential or important. From what I gathered, it does become valuable when you have multiple people working on the project. But if it's just 1 person, its use seems overkill. What do you guys think?
well I guess speed comes with use and familiarity, to give an example say you made some changes to your code, the speed to commit the changes with a comment on what it was about is about as fast as you can type that in to a cmd prompt. Then you'll have a complete audit trail of the work that you have done and have the ability to jump to any checkin point within seconds.
Another thing it can be good for is experimental changes, simply make a new branch which again is less than a second to compete and work away. Then say you need to bug fix the last live version of your code you can checkout the master branch again.
There's a bunch of different branch strategies you can use depending on what your doing, also you can use tag points to specify important points in time such as the actual code commit which went live.
Just a quick demo of a typical git workflow would be
cd in to the root folder and open project.
do work ...
git add . (adds all untracked chagnes)
git commit -am "commit comment" (commits all tracked chagnes)
do more work ...
repeat it's pretty simple.
To make a feature branch you'd just do
git checkout -b feat-name
and to get back to master is
git checkout master
then merge back down is
git merge feat-name
Most of the other stuff would only really kick in if you worked with other people really. I think it's a very handy tool to be familiar with. You can use it for all sorts of things like say you want to patch the hell out of Oblivion, just put a git repo in there and commit at points where thing work, then you can roll back when it inevitably breaks.
Another thing it can be good for is experimental changes, simply make a new branch which again is less than a second to compete and work away. Then say you need to bug fix the last live version of your code you can checkout the master branch again.
There's a bunch of different branch strategies you can use depending on what your doing, also you can use tag points to specify important points in time such as the actual code commit which went live.
Just a quick demo of a typical git workflow would be
cd in to the root folder and open project.
do work ...
git add . (adds all untracked chagnes)
git commit -am "commit comment" (commits all tracked chagnes)
do more work ...
repeat
it's pretty simple.To make a feature branch you'd just do
git checkout -b feat-name
and to get back to master is
git checkout master
then merge back down is
git merge feat-name
Most of the other stuff would only really kick in if you worked with other people really. I think it's a very handy tool to be familiar with. You can use it for all sorts of things like say you want to patch the hell out of Oblivion, just put a git repo in there and commit at points where thing work, then you can roll back when it inevitably breaks.
Last edited:
Oh you don't actually need any plugins to get git working, just install the latest version of msysgit and use the gitbash cmd style prompt. Just keep it open beside VS and run commands in to it when you need to.
You can have a look at this link as well, it'll allow you to connect to github to pull down any opensource projects as well.
https://help.github.com/articles/generating-ssh-keys
and once you're a bit more familiar with it I'd really recommend reading this, covers all the main working concepts but might be a bit much straight away
http://sitaramc.github.com/gcs/index.html
you can also add git support in to a powershell prompt, it's really nice as you can auto complete support, color coding and stuff like that
https://github.com/dahlbyk/posh-git
and then the last step for me was setting up console2 as a tabbed command line
http://www.hanselman.com/blog/Console2ABetterWindowsCommandPrompt.aspx
Last edited:
If your using visual studio 2010 then use this - http://code.google.com/p/gitextensions/
I personally use svn for my personal projects, but couldn't work without source control now. It's basically a time machine for your code.
I personally use svn for my personal projects, but couldn't work without source control now. It's basically a time machine for your code.
Associate
It ain't crazy due to speed alone but I imagine you're not quite getting it either. You'll probably experience some crazy sized repos if you haven't already that take a great deal of time to copy.
Working with your rar system, you want to work on new functionality, you make a new copy of the code I would assume. This will take time as you move all the code from one location to another. Alternatively you can branch with git which will probably near instantly happen.
Working on more than one change at a time? Either you work on your code base and deny all other changes until you're done, or you use multiple branches and can still merge smaller changes to master when need be.
Everything about the workflow of git is faster. You can push changes faster. You can make changes faster. It just offers so much. Sure you can probably find ways to avoid it and replicate a lot of functionality, but that makes no sense.
Thanks for the details explanation DanF. Much appreciated.
I'm looking at some of the reviews for the svn extension.
For a single user, is SVN as good as git?
I'm leaning towards SVN due to its seamless integration with Visual Studio (which seems to be the case, judging by the reviews).
I'm looking at some of the reviews for the svn extension.
For a single user, is SVN as good as git?
I'm leaning towards SVN due to its seamless integration with Visual Studio (which seems to be the case, judging by the reviews).
Soldato
Pretty much everyone's moving to git/mercurial nowadays and leaving SVN behind. Nothing wrong with SVN unless you want to do branching etc, but you may as well learn a DVCS.
Besides, there's git source control providers for Visual Studio anyway which will be just as integrated as SVN. Here you go - you don't need TFS to use it.
There's nothing stopping you from using TortoiseGit/the command line (no idea why so many people prefer the command line approach to be honest) at the same time as the Visual Studio add-on too.
Wish they'd released this before I opted to go to Mercurial.
Besides, there's git source control providers for Visual Studio anyway which will be just as integrated as SVN. Here you go - you don't need TFS to use it.
There's nothing stopping you from using TortoiseGit/the command line (no idea why so many people prefer the command line approach to be honest) at the same time as the Visual Studio add-on too.
Wish they'd released this before I opted to go to Mercurial
.
Last edited:
SVN requires a central repository, you can run one from your own machine but generally you'd have a server somewhere with webdav access set up. Git is standalone, the full repo is stored under each copy of the project, so it's generally quicker to get up and running. The learning curve with Git is a bit steeper than SVN because the workflow is a bit more complicated.
Here's a simple example of when a VCS is much better than file archives...
You've just finished v1.0 so you release it, archive it off, and start work on v1.1. 3 weeks into developing v1.1, a critical bug is found in v1.0 that requires an immediate fix. You open up your archive, and the fix takes two dozen small changes across 15 different files. Now you also have to replicate those same changes in your separate v1.1 project, which is time consuming and error prone.
With a VCS, you'd have a separate branch for v1.1, and if / when you need to hotfix v1.0, you just check it out, make the changes, commit, and then switch back to the v1.1 branch where you can run an automatic merge of the hotfix into your v1.1 branch in as long as it takes you to type the command.
There are tons of other reasons, like easy access to diffs between commits, so you can see when certain lines changed, etc.
I don't know what it's like in the Windows dev world, but most PHP jobs expect you to be proficient with source control these days.