0

We currently do not use any kind of version control software. We recently started using Eclipse, and our source code is maintained on a network drive. An Eclipse project was created and everyone has imported the project into Eclipse on their machines. Due to the way we are set up, we are always getting stuck in clean/build loops throughout the day which is hurting productivity.

We would like to start using some kind of VCS (most likely GIT). I am envisioning a centralized workflow with each developer having a local copy of the code on his/her machine. We would rather use GitHub Enterprise for the shared repository instead of hosting the code on GitHub.

I am not quite sure where to start in getting this setup correctly. I have been watching videos and reading tutorials, however none seem to directly apply to how we would like to do things. Is GIT the right software to use for the type of setup we desire? Also, how does clean/building work with Eclipse and the local copies vs the shared repository?

Tommo
  • 977
  • 14
  • 35
  • 1
    Please give more detail on this clean/build problem. What's the issue? – ccleve Dec 13 '12 at 17:06
  • Just seems that with multiple developers having the shared project open and editing files at the same time, we will continuously get stuck in a loop where I make changes and save, Eclipse will clean/build the project, meanwhile another person edits/saves a file and their Eclipse tries to clean/build the project while mine is still going. A full clean/build also seems to take 5+ minutes as the code is stored on a network drive which is slowing things down. – Tommo Dec 13 '12 at 17:23
  • I think this is better suited for http://programmers.stackexchange.com/, if any. There is never "the best way" only "the most suitable way for my situation" which is quite subjective. – Felix Kling Dec 13 '12 at 20:57
  • I agree. We're basically just looking for the easiest way to have the code stored in a central location with each developer having a local copy on their machines that stays in sync. Cleaning/Building a project as big as ours will be significantly faster locally than it is over the network. – Tommo Dec 13 '12 at 21:29

6 Answers6

3

First, watch this video.

Second, if you're using Eclipse, you're gonna wanna use EGit. Very detailed tutorial here.

Third, don't throw yourself at GIT. Take SVN into consideration at some point (after documenting on GIT). Maybe a Central Version Control System will do you better than a Distributed Version Control System.

Edit:

Oh and by the way... there's a veeeeeeery long and famous Q&A right here regarding this topic. Best of luck.

Second edit:

As for SVN, here you have an easy tutorial on Subversive, and here you can find the full in-your-face Subversive documentation.

Community
  • 1
  • 1
Georgian
  • 8,795
  • 8
  • 46
  • 87
  • It seems like a lot of the features that make GIT useful wouldn't exactly apply to us. Our development is fairly linear. Occasionally we will spin off a new version, but we don't really do much branching where someone would take the project in a completely different direction. It definitely seems like GIT is great and useful, but for what we are trying to do and need, it would be much more complicated than it needs to be. – Tommo Dec 13 '12 at 17:46
  • Then `Subversion` is the right way to go. Its implementation for Eclipse is `Subversive`, which is a featured plug-in for the IDE. It's much easier to use than GIT - you are right. :) – Georgian Dec 13 '12 at 17:49
  • We don't really do branching or work offline, I just think that Subversion is built for exactly what we are trying to do and although it might not have the extra bells and whistles that GIT has, they aren't applicable to us anyway. – Tommo Dec 13 '12 at 18:16
  • I would urge you to reconsider subversion. – Adam Dymitruk Dec 13 '12 at 19:41
  • +1 - especially for link to great video. I have few years svn experience (quite well) and I like to switch to git (anyway). Now I understand why "think different" is quite important in this case :-). Thanks. – Michał Powaga Mar 02 '14 at 10:42
  • @Tommo (responding to an old comment, but in case anyone else reads this) “Our development is fairly linear.” Everyone said that before they tried Git. :) Git branches are good for many things that you wouldn’t initially think of as branches. That is, just because you think you have a linear development flow, don’t discount the strong possibility that branches will still help your existing flow work better. This is especially true with multiple developers, but I find it true on my solo projects as well. – Marnen Laibow-Koser Mar 19 '19 at 04:51
2

You have your needs now but your needs will change. Save yourself the headache of later moving to Git from SVN and start with Git. Here are the reasons to go with Git over Subversion:

  1. Speed - Git is WAY faster
  2. Disk space - Git history is small. Most of the time it takes up 1/10th the space of SVN history.
  3. No server - DVCS allows no admin and you can skip a centralized server altogether. Your central repository can just be files on a network share.
  4. Integrity - data corruption very easy to detect and correct.
  5. Snapshot history - the whole project is snapshotted for each version. No mixing and matching paths with versions.
  6. Open Source dependencies - most of the projects you may want to use are on Github. You can easily just add a submodule and version that dependency.
  7. Power:
    • git bisect - find a where a bug was introduced quickly
    • rerere - reuse how you fixed conflicts if they come up again
    • supports any workflow
    • proper 3-way merges - this will save a ton of headaches in the future
    • rebasing - you can keep your history linear, even after someone merged

My last point is very important. You are just now starting to use source control. Start with the best option. You are at a point where you know the least about your needs. Things you think you don't need right now you will need later - guaranteed.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • Can you expand on "No server - DVCS allows no admin and you can skip a centralized server altogether. Your central repository can just be files on a network share." How would I set it up so the repository is just "files on a network share"? – Tommo Dec 13 '12 at 20:44
  • Assuming you have your share mapped as z, `cd /z/ && mkdir centralrepo && cd centralrepo && git init --bare`. Done. You don't even need git installed on the machine that z is pointing to. – Adam Dymitruk Dec 13 '12 at 20:47
  • Then I just dump the files in and clone it locally? – Tommo Dec 13 '12 at 21:12
  • nope. You initialize your repo on your machine first and then push them up to the remote: `cd yourproject && git init && git add . && git commit -m "my first commit" && git remote add origin /z/centralrepo && git push origin master` Now you project exists on the central repo as well as locally. Now one of your coworkers can get the project with `git clone /z/centralrepo`. But you can also just pull changes directly from other developers and not have anything central if you can reach each other via network shares. – Adam Dymitruk Dec 13 '12 at 21:29
  • Upvoted, but have to disagree that rebase is a good thing. If there’s a merge, your history should show it. – Marnen Laibow-Koser Mar 19 '19 at 04:49
2

I would create a git repository on the shared drive, you don't need a server like github at all. After setting it up developers can clone from the shared drive to their local computer and push the changes back when they are done.

Every developer will end up with a local copy of the code where they have their own build environment and never be in each others way anymore.

Start with a sample project with just some files in it and play around with it, since you will need to get some experience with a version control system. Also learn the git command line tools (for windows use msysgit), because most of the examples on the internet are writen for those. For more information on git be sure to read the free git book: http://git-scm.com/book

Also see this question about using git on a windows share: How to git clone a repo in windows from other pc within the LAN?

Community
  • 1
  • 1
Niels van Reijmersdal
  • 2,038
  • 1
  • 20
  • 36
  • "Use Git CLI-commands, because you can't use Git more-or-less reasonably with GUI-only way" will be more correct and fair definition: **all** Git GUIs hide **a lot** behind the scene – Lazy Badger Dec 13 '12 at 21:14
  • to use git as it was intended with all the benefits, you use it from the command line. – Adam Dymitruk Dec 13 '12 at 21:43
  • A GUI like SourceTree or GitX is helpful—but as an adjunct to the command line, not a replacement for it. – Marnen Laibow-Koser Mar 19 '19 at 04:48
0

EGIT for eclipse is the good one to integrate git in your eclipse project environment.

Besides, if you are on windows, you can download the Github for Windows, it's really simple, effective to use.

mtk
  • 13,221
  • 16
  • 72
  • 112
0

GIT is certainly the preferred way and nicely integrates with Eclipse IDE. But you could also use Subversion as all you want to have is a local copy of code on user machine(call it subversion branch). I say preferred way because GIT is way too flexible: Offline commits, full copy of body of code versus just branch etc....list is too long.

As you mentioned, you can also use github. Roughly, steps are as follows:

  1. Just signup for it
  2. create a repository.
  3. Get the link to repository and Point it as new git repository in Eclipse
  4. Push your code. Commit it.

You will have your code files in github. This will work provided you have Git installed in Eclipse. I believe Eclipse Juno already is setup with EGit (plugin for Git)

For resolving the build issues, you can use set up some Continuous Integration tools like Jenkins. This can be setup as Eclipse plugin as well.

Vikram
  • 4,162
  • 8
  • 43
  • 65
0

As some already noted, for question

the best way to use GIT?

in your situation (zero SCM-experience) best and fair unbiased answer will be

Do not use Git at all!

Contrary to "Why is Git better than Subversion?" topic you can also read (some subset as result of fast-recall)

and check other topics under git tag with multiple laments of Git-boys.

While Subversion is rather good choice (with some edge corners anyway: you may fall into "Merge Hell" even if you think about development as linear: some branches may and have to happen, into "Refactoring Nightmare" with famous "Tree conflict" error...) you can think about "Usable as Subversion and powerful more than Git" alternatives (even you'll use only small needed part or overall power): - Mercurial "DVCS with a human face, made by software engineers for software engineers, not for fashionable dudes".

  • MercurialEclipse is answer for Eclipse request (in Aragost recommendation Mercurial users trust)
  • TortoiseHG is user-friendly cross-platform GUI for all and any Mercurial needs outside Eclipse
  • Mercurial server require a lot less headache (notably "under Windows"), than equivalent Git-server
  • Mercurial real experts can be easy found (while Git-boys is more fun-club of rapturous teenagers)
Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • Agreed, git is a mess. Github, however, is extremely useful, and papers over git's problems. It's worth using git if only to get Github's features. – ccleve Dec 13 '12 at 21:44
  • @ccleve - BitBucket isn't worse for Mercurial (partially - better /free private repo/), For Git I'll choose anyway Assembla – Lazy Badger Dec 13 '12 at 21:49
  • Downvoting. Although I myself started on CVS (!), I know plenty of people who started on Git and were able to learn it. Git is very logical if you take the time to learn a few basic concepts (it’s all about creating trees of commits and synchronizing commits between repos). I recommend Git to anyone, and would also have done so in 2012, when this answer was posted. – Marnen Laibow-Koser Mar 19 '19 at 04:47