How useful is git?

hargi

hargi

hargi

Associate
Joined
19 Jul 2006
Posts
1,847
I ll be honest I dont really use version control and either only have one copy of my code or several dotted about computers and memory sticks but with no real way of knowing whats going on in each.

Have seen git in a few magazines now and have just ordered a book on it.
However I have a few beginner questions.
how useful is it for developing websites?

say if i commit 1 file that works
I then commit it again with something faulty in it but dont realise
I then commit it again with a extra feature that works but still has the faulty code in it to.
Is there a way to merge the 1st commit and the last but with out the faulty code or have I got what git is totally wrong?
 
version control is really useful if your developing with other developers where you can branch out and write code without affecting each other until you do a merge. (its even better with distributed version control when developers are at remote locations with poor data connections)

In your case, if your working on your own you dont really need version control unless you'd like to see your past commits.

To answer your question, no you dont normally merge versions of the same file from the same branch but you would be able to look at the history of the file and reimplement the fix for the file and commit that.
 
Git is fantastic. When used properly it's insanely powerful and can massively simplify the distribution, sharing and management of projects.

You can work on features whist maintaining a working version of the project really easy. Sharing code and collaboration becomes much easier. Push code to servers can be a doddle and much much much faster than ftp upload. Thats just the tip of the iceberg.

Git is genius basically.
 
Use github and you'll have access to your repo from anywhere with an internet connection.

I couldn't work without version control. It's right next to "I need a computer to work." in terms of importance to me. Git is my choice of software to do that task, however I can live with Subversion just as easily. Git has a few features that make it more appealing than Subversion, but I won't bother to list the details at the moment because it sounds like you may not be too familiar with version control as a principle yet, never mind being able to appreciate the differences between the tools available for the job. :)

In short.. yes, start using it.
 
Git or any version control is great (git is by far the best though ;)) for any project even if it's just something you are working on yourself. I can't tell you the amount of times I've committed some code and come back to it a couple of months later and not been sure why it was that I did that. I'll just have a look at my commit message though and then all will become clear! Version control will do a lot of things, but think of it for now as a diary of what you have done. It will save you a lot of trouble down the line.

I use github at work, but if you want a free private repository (github only has free publically viewable accounts) then use bitbucket (https://bitbucket.org). Github is the better website and more commonly used, but if you're just using it as a git hosting service, then you won't really notice a difference between the two. You can easily transfer projects between the two websites if you want if you change your mind though.
 
What these guys have said so far.

We use subversion at work but the same principles apply, would find it hard to develop anything worthwhile without version control now.
 
I find Git to be more intuitive to use than SVN personally, we use SVN at work. I use Git at home.

I find that being able to branch when I start work on a feature or idea is incredibly useful, and often have a few branches on the go. My deployed projects just follow the release branch and I'm free to Noodle away without worrying about breaking stuff.

I use it for other non coding projects too, for instance modding games that are highly dependent on the order of mods applied. It allows me to rewind the install to any number of known states.
 
Version control is also a great way to store config files you use for various systems (bash/zsh, vim, git, tmux or whatever else you have to configure). You know you will never lose them and it's super easy to get set up on a machine you might not have used before. Also if you make a config change on one machine, you can easily pull that change to another.
 
hargi said:
say if i commit 1 file that works
I then commit it again with something faulty in it but dont realise
I then commit it again with a extra feature that works but still has the faulty code in it to.
Is there a way to merge the 1st commit and the last but with out the faulty code or have I got what git is totally wrong?
Click to expand...
If there is one person, you can do this equally well with Git or SVN.

Distributed Version Control Systems such as Git (and Mercurial) really come in to their own when you are merging branches. SVN only remembers one level of ancestry, whereas DVCSs remember everything, and are able to make much more sensible decisions when automerging for you. This is a godsend in large projects with multiple branches. It makes it possible to create a branch for each feature you are working on, because the labour involved in merging back is so much lower.

So you could go with Git or SVN for your purposes. SVN is simpler, but you might as well learn Git now, as it will probably replace SVN even in the corporate environment within 5 years.
 
Mailman86 said:
Version control is also a great way to store config files you use for various systems (bash/zsh, vim, git, tmux or whatever else you have to configure). You know you will never lose them and it's super easy to get set up on a machine you might not have used before. Also if you make a config change on one machine, you can easily pull that change to another.
Click to expand...
We generate our config files, from a set of hierarchical templates stored on our version control system. The golden rule in config files is to never repeat a piece of information, e.g an endpoint or a setting.
 
A few months back I begun the task of migrating our source control at work from an old copy of SourceGear Vault (:shudder:) to Mercurial. We now have most projects in it: everything from websites to windows apps/services to database schemas.

I weighed up the pros and cons of mercurial vs git and went with Mercurial in the end as the GUIs seemed better on Windows and I couldn't be bothered faffing around with mysysgit to get TortosieGit working (I have done it before and it's not difficult to be honest). We use TortoiseHg as a GUI.

I mostly find source control useful to double-check my changes: I'll quite often hack away at code, dropping in random debug code etc and then when I come to commit those changes diffs give me a nice quick visual check of exactly what my changes were, which I can then double-check to make sure there's no leftover debug code which really shouldn't be pushed live.
 
SmartGit is a better GUI, in my opinion :) Though I'm a CLI fan.

Also msysgit needs zero faff :o It's installed as part of Git (GitBash runs in msysgit)
 
agent_paul said:
version control is really useful if your developing with other developers where you can branch out and write code without affecting each other until you do a merge. (its even better with distributed version control when developers are at remote locations with poor data connections)

In your case, if your working on your own you dont really need version control unless you'd like to see your past commits.
Click to expand...

This is wrong. Version control offers you advantages when you're working alone. The main obvious one is a history so when you mess something up, it's an issue bisecting or rolling back, something you're not getting working direct with files without forward thinking and making sure you never forget your procedure. All code should be managed, always. Then backup the repo and not tons of code instances on ton of different servers.

agent_paul said:
To answer your question, no you dont normally merge versions of the same file from the same branch but you would be able to look at the history of the file and reimplement the fix for the file and commit that.
Click to expand...

Actually you can do this type of stuff in git and don't need to sit reimplementing code. You should read up a bit on git fully, it does a ton of stuff you'd never actually know about until you read the manual.

agent_paul said:
If there is one person, you can do this equally well with Git or SVN.
Click to expand...

I disagree. Sure, you can avoid the majority of SVNs issues by being the only person working on a set of files and making sure you work on things / commit things in order. Then again, you're asked to do a major project to your code base, you do the right thing and make a branch (you can't not commit to the trunk while you work on this project, obviously). While working on this you then get a different project prioritized, so now you have two branches. All the while people have been bugging you about small changes to the trunk. You're context switching and now have 3 different code bases, playing the system just like it has multiple users and you're going to have to deal with SVN merge which is where a lot of the whining about.

Theres also the fact SVN is typically slower than git and it's a pita.

Don't get me wrong, using SVN is a lot better than using nothing but anything learning new and any new projects should probably use git. You can argue that other DVCS are superior to git, but git probably is and will continue to be the most popular DVCS for quite some time.
 
Cheers

I'm going to give it a bash, most people are using it so its got to be useful. I suppose its just using it before you realise how much you need it
 
I mostly use ClearCase at work in a Windows environment, but recently for a project we're doing in Linux we've been using GIT (and eGIT plugin for Eclipse).
We are finding GIT a real pain to use at the minute.
I constantly get merge conflicts stopping me from pushing and pulling and I've no idea how to resolve the conflicts, or at least how to tell GIT I've resolved them. I've had merge conflicts on a file that nobody except me has changed!
 
Git is incredibly useful. Once you get a feel for how to use it from the command line it's really powerful (I've used both command line and GUI..the former is far better). Dunno what we would do without it at work :) I found it superior to SVN in every way.
 
GoogalyMoogaly said:
I mostly use ClearCase at work in a Windows environment, but recently for a project we're doing in Linux we've been using GIT (and eGIT plugin for Eclipse).
We are finding GIT a real pain to use at the minute.
I constantly get merge conflicts stopping me from pushing and pulling and I've no idea how to resolve the conflicts, or at least how to tell GIT I've resolved them. I've had merge conflicts on a file that nobody except me has changed!
Click to expand...
Code: 
git rebase --continue
once you have fixed conflicts.
 
You must log in or register to reply here.
Back
Top Bottom