Start a new topic
Add Reply
Posted 19 November 2009 - 09:12 AM
If you have experience with Git could you please share the advantages, disadvantages, or pitfalls.
We are considering Git for our source control (we currently have none). The main aspect of git I like (from my research) is the fact that everyone has a copy of the code locally and all can commit changes locally before having to merge back into the main trunk. Also, there is no central repository (although one can essentially be mimicked).
Thanks in advance!
Do you have any experience with Git?
Page 1 of 1
Do you have any experience with Git?
MultiQuote
#2
girasquid
- Barbarbar
-
- Group: Moderators
- Posts: 1,704
- Joined: 03-October 06
Dream Kudos: 825
Posted 19 November 2009 - 09:27 AM
If you're comparing git to svn, the Git Wiki has a helpful page at GitSvnComparison.
On my personal projects I tend to like using git for the reasons you described - because you don't have to push anywhere until/unless you want to, git stays way faster than svn for most of the things I need to do with it.
On my personal projects I tend to like using git for the reasons you described - because you don't have to push anywhere until/unless you want to, git stays way faster than svn for most of the things I need to do with it.
Was This Post Helpful?
0
#3
anirelles
- D.I.C Head
-
- Group: Members
- Posts: 81
- Joined: 01-January 09
Dream Kudos: 0
Posted 19 November 2009 - 09:43 AM
From what I understood Git was developed by Linus Torvald and he uses it for Linux like this :
he has a team of few person in which he has total trust and he only accept code coming from them. Each person of this team also have a network of trusted people, etc, etc ...
There is a hierarchy among developers.
When someone made some improvement in the software he makes a push to his "master" and this person accept or not the improvement. In case of Linus Torvald he only receive improvement of a few people and it's a lot easier to manage.
I never used Git so for me it's only interesting in situation like described.
Other people will say that it is interesting because you can work offline (all revision are in your machine), but nowadays we are connected to the network 99% of time.
I can even see a drawback in only commit in local, if the computer crash you can lost an important amount of work.
So maybe it's a good idea to use Git and Subversion in parallel to avoid this.
Well, for the moment I stay with CVS/Subversion and give a look at Git if I decide to contribute to open source. I'm not sure it is worth for a project with a quite small team of developers.
Once again I don't know Git very well I would like to hear other people opinion.
he has a team of few person in which he has total trust and he only accept code coming from them. Each person of this team also have a network of trusted people, etc, etc ...
There is a hierarchy among developers.
When someone made some improvement in the software he makes a push to his "master" and this person accept or not the improvement. In case of Linus Torvald he only receive improvement of a few people and it's a lot easier to manage.
I never used Git so for me it's only interesting in situation like described.
Other people will say that it is interesting because you can work offline (all revision are in your machine), but nowadays we are connected to the network 99% of time.
I can even see a drawback in only commit in local, if the computer crash you can lost an important amount of work.
So maybe it's a good idea to use Git and Subversion in parallel to avoid this.
Well, for the moment I stay with CVS/Subversion and give a look at Git if I decide to contribute to open source. I'm not sure it is worth for a project with a quite small team of developers.
Once again I don't know Git very well I would like to hear other people opinion.
Was This Post Helpful?
0
#4
girasquid
- Barbarbar
-
- Group: Moderators
- Posts: 1,704
- Joined: 03-October 06
Dream Kudos: 825
Posted 19 November 2009 - 12:49 PM
anirelles, on 19 Nov, 2009 - 09:43 AM, said:
Other people will say that it is interesting because you can work offline (all revision are in your machine), but nowadays we are connected to the network 99% of time.
I can even see a drawback in only commit in local, if the computer crash you can lost an important amount of work.
I can even see a drawback in only commit in local, if the computer crash you can lost an important amount of work.
This is sort of a weakness and a strength; I've run into a few situations recently where I needed to make some code changes and didn't have access to the internet. That being said, your point about having your computer crash is a good one - I host all my repositories with GitHub or Unfuddle so that I can push my changes to them whenever I do have network connectivity.
Was This Post Helpful?
0
#5
xerxes333
- D.I.C Regular
-
- Group: Contributors
- Posts: 486
- Joined: 05-July 07
Dream Kudos: 25
Posted 19 November 2009 - 01:16 PM
I have watched the Git presentation by Linus to Google and I understand his reasoning for wanting a version control system (VCS) to ensure file integrity. While I agree it is nice that the guaranteed file integrity is a nice feature I don't really think that should be part of the VCS. That's what backups are for! (and everyone ALWAYS backs up their data . . right 
)
I guess the reason I'm leaning towards Git is that the development process is only as structured as you want it to be. Our current system involves walking to the other devs office and asking him what changes he made and when, so ANY VCS is better than what we have in place.
)I guess the reason I'm leaning towards Git is that the development process is only as structured as you want it to be. Our current system involves walking to the other devs office and asking him what changes he made and when, so ANY VCS is better than what we have in place.
Was This Post Helpful?
0
#6
homemade-jam
- Gabe's Nemesis
-
- Group: Contributor w/DIC++
- Posts: 1,272
- Joined: 17-March 08
Dream Kudos: 50
Posted 20 November 2009 - 07:56 AM
I use the google code svn...really handy, especially with subclipse. Also use it for all my essays etc.
Was This Post Helpful?
0
#7
xerxes333
- D.I.C Regular
-
- Group: Contributors
- Posts: 486
- Joined: 05-July 07
Dream Kudos: 25
Posted 20 November 2009 - 11:44 AM
We are also considering SVN which is easier for me to grasp because I have experience using (just not administrating) CVS. It just seems to me that the administration portion of Git is better for smaller companies (less than 10 developers) where everyone is communicating on a daily basis. I'm still neck deep in researching and testing right now but as always any input is greatly appreciated.
Was This Post Helpful?
0
#8
Oler1s
- D.I.C Addict
-
- Group: Members
- Posts: 927
- Joined: 04-June 09
Dream Kudos: 0
Posted 20 November 2009 - 07:59 PM
Quote
While I agree it is nice that the guaranteed file integrity is a nice feature I don't really think that should be part of the VCS. That's what backups are for!
VCS should definitely be dealing with file integrity issues on large scale code, and a good VCS should allow for that option on small scale codebases that demand it.
Quote
It just seems to me that the administration portion of Git is better for smaller companies (less than 10 developers) where everyone is communicating on a daily basis. I'm still neck deep in researching and testing right now but as always any input is greatly appreciated.
1) Encouraging branching or allowing for it without penalties
2) Flexible hierarchy
I've found both critical in small teams. SVN in contrast is the one central, everyone depends on central type of model, which isn't flexible at all. When there's no central codebase (which is what I faced), SVN is very odd. If you don't have a central server, or a central server doesn't make sense because there is no social authority, SVN doesn't fit.
But the flip side is that once you have a DVCS:
1) You need to figure out a hierarchy and some kind of structure to the "flow" of code.
2) You do need to get comfortable with merging and merging issues that can crop up.
So I believe that teams with many inexperienced VCS users, especially those lacking a strong authority on how to structure a flexible hierarchy, should stick to centralized systems.
Was This Post Helpful?
0
#9
Programmist
- Slouching towards Bethlehem
-
- Group: Mentors
- Posts: 1,516
- Joined: 02-January 06
Dream Kudos: 100
Expert In: Java
Posted 21 November 2009 - 09:38 AM
I looked into Git a few years back after watching Linus' SCM diatribe. I thought it was interesting, but basically put it on the back burner because (as with most new things) it had no tools support/integration yet and was not worth bothering with for me. Since then it's picked up a lot of steam and has become a lot more popular. There are now IDE and CI server plugins. I would consider using it on my next project, but only if (as mentioned by the above poster) the majority off the team had plenty of experience dealing with branching and merging and followed best practices.
This brings up another point. Subversion, while a step up from CVS, can be deceptively simple. So long as your code base stays on the trunk and no one ever concurrently edits the same file, it will work like a dream. Once you start creating branches, however, things get complicated fast and if just on committer on your team doesn't know what he/she is doing it can screw up your entire system. This can be especially insidious if you don't have a CI server running builds and unit tests because then no one will know exactly when things were screwed up. Even with a CI server it might not cause a failure. The point is to make sure everyone has training on the best practices for creating and re-integrating SVN branches.
Also, (and this is critical!) don't use more than one SVN tool to manage checked out code. For instance, if you check out a project using TortoiseSVN and then use Subclipse to commit some changes you made in Eclipse, don't go back to using TortoiseSVN on the same code. In my experience they do not play well together and, for instance, it can cause your code to become out of sync with the repository but still think it's still in sync. This can be a total nightmare, especially if someone else is working in the same project because you won't get their updates.
Good luck on your project and, if you do use Git, please report back on how it worked for you.
This brings up another point. Subversion, while a step up from CVS, can be deceptively simple. So long as your code base stays on the trunk and no one ever concurrently edits the same file, it will work like a dream. Once you start creating branches, however, things get complicated fast and if just on committer on your team doesn't know what he/she is doing it can screw up your entire system. This can be especially insidious if you don't have a CI server running builds and unit tests because then no one will know exactly when things were screwed up. Even with a CI server it might not cause a failure. The point is to make sure everyone has training on the best practices for creating and re-integrating SVN branches.
Also, (and this is critical!) don't use more than one SVN tool to manage checked out code. For instance, if you check out a project using TortoiseSVN and then use Subclipse to commit some changes you made in Eclipse, don't go back to using TortoiseSVN on the same code. In my experience they do not play well together and, for instance, it can cause your code to become out of sync with the repository but still think it's still in sync. This can be a total nightmare, especially if someone else is working in the same project because you won't get their updates.
Good luck on your project and, if you do use Git, please report back on how it worked for you.
Was This Post Helpful?
0
Page 1 of 1
| 
