Home » Newcomers » Newcomers » Best way to use GIT in our environment?
|
| Re: Best way to use GIT in our environment? [message #990698 is a reply to message #990669] |
Thu, 13 December 2012 17:58   |
|
On 12/13/2012 10:01 AM, Thomas Mancini wrote:
> 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?
Yes, Git is the right version control to use. It totally rocks. A year
and a half ago, I took the following notes:
http://www.javahotchocolate.com/tutorials/git.html
http://www.javahotchocolate.com/tutorials/git-lifecycle.html
http://www.javahotchocolate.com/notes/git.html
http://www.javahotchocolate.com/notes/github.html
Note that there is an integration with Eclipse called eGit. A colleague
of mine uses it. I do not because the command line is way faster than
all the pull down menu/choose/click/etc. required inside Eclipse. Just
my opinion and I'm a command-line sort of guy anyway.
I'm also available for specific questions.
Best of luck, I hope this helps,
Russ
|
|
| |
| Re: Best way to use GIT in our environment? [message #990896 is a reply to message #990742] |
Fri, 14 December 2012 17:24 |
|
On 12/13/2012 7:52 PM, Thomas Mancini wrote:
> After doing some further reading, I think a centralized version control
> system would be a better fit for us. Git seems great and has some
> awesome features, however most are not applicable to us. We don't do
> any branching and don't have a need to work offline. I believe
> Subversion would make more sense for us, but I'm still open to being
> proven wrong.
>
> We only need a VCS that would let us have a repository on a local server
> and allow all developers to maintain a local copy on their systems with
> as few headaches and as much ease as possible. Clean/builds through
> Eclipse would be much faster locally considering the size of our
> application.
> I'm still unsure how cleaning/building of the master repository would
> work. Does that just happen at the time of deployment?
Subversion works great. I used it for years. Here are some notes on it,
a bit older than my Git notes. I would suggest consuming Subversion from
Eclipse via subclipse* (and there's a dedicated Eclipse forum for this)
because it is better than using the command line. However, I would also
suggest, if you're using Windows, TortoiseSVN as being very useful too.
http://www.javahotchocolate.com/tutorials/subversion.html
http://www.javahotchocolate.com/tutorials/tortoisesvn.html
http://www.javahotchocolate.com/tutorials/subclipse.html
Your last question is answered in the first article. Note that I've
never hosted Subversion from any platform but Unix/Linux.
Hope this helps.
Russ
* I used subversive, another Eclipse-integration option, many years ago
the first time I used Subversion from Eclipse. It worked fine. However,
later I tried to set it up and could not. I set up and used subclipse
instead. Your mileage may vary, but I'm guessing subclipse is still
where it's at.
|
|
| |
| Re: Best way to use GIT in our environment? [message #990903 is a reply to message #990898] |
Fri, 14 December 2012 18:55 |
|
On 12/14/2012 10:34 AM, Thomas Mancini wrote:
> Thanks for all of your help. I'm assuming you prefer Git to Subversion
> at this point? Which do you think is more applicable and easier to set
> up based on our intended use?
Git isn't real easy to set up and manage if you're doing the back end
(server) yourself. The easiest thing to do for the back end is to
subscribe either to a commercial service like GitHub or a free one like
Atlassian/Bitbucket. I've used both, the former for my place of work and
the latter for at home. I'm slowly migrating projects out of Subversion
hosted on a Linux box at home to Got on Bitbucket.
If you don't need to branch (which, even if you're all alone, is
probably only because you've never done it before, because it's soooooo
useful), then Subversion remains the simplest to use. I'll admit that
Git was a steep learning curve, though I tried to make it more shallow
for my teammates by write my "lifecycle" notes.
Still, now that I'm on this side of things, it seems a lot simpler than
at first. I wrote my "everyday commit stuff" cheatsheet
(http://www.javahotchocolate.com/tutorials/git-everyday.html) to show
how a complicated use is really fairly simple in the end.
One thing you get in spades with Git is everyone having a copy of
everything on his local host in addition to the back end copy. (This
assumes that each keeps his local master pretty up-to-date.) That's nice
redundancy when you don't have an active back-up plan. And being careful
to push one's private branches to their remote gets them on the back
end, so private-branch back-ups are painless.
Russ
|
|
| |
| Re: Best way to use GIT in our environment? [message #990966 is a reply to message #990921] |
Sat, 15 December 2012 16:11 |
|
On 12/14/2012 03:01 PM, Thomas Mancini wrote:
> Once again thanks for your response. I am not seeing where the articles
> talk about cleaning/building. Also, does it make sense to have a
> 'master' working directory? Using Subversion and Tortoise I:
>
>
> Created a Repository
> Imported an existing project into the repository
> Checked out the repository into an empty directory on the same drive as
> the repository
> Imported a new project into Eclipse via "Checkout projects from SVN"
>
>
> I figured it would make sense to maintain a working directory on the
> same drive as the repository that will be used for distribution
> purposes. Is this common practice or how is this typically done?
I'm a little busy this weekend and don't have time to think hard about this.
Cleaning and building? What do you mean?
Associated with Git is the concept of a master branch everything else
(any other branches) just pour back into that one and from master you
typically build your product. It doesn't have to be that way, but
everyone I know does it that way.
You wouldn't have any development subdirectories on the host running
your Subversion back end. (Is that what you meant?)
|
|
|
| Re: Best way to use GIT in our environment? [message #991181 is a reply to message #990966] |
Mon, 17 December 2012 15:52 |
 Thomas Mancini
Messages: 11
Registered: March 2012 |
Junior Member |
|
|
One of the main reasons we're deciding to use a VCS is because of cleaning/building issues we've had on Eclipse due to the code being on a shared network drive.
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. We've unchecked the 'Build Automatically' flag because that seemed to give us even more problems.
I have been messing around with SVN a bit. I created a repository and imported an existing project into it, however this did not create a working directory out of the project (I knew it wouldn't). I guess my confusion is coming from the fact that I understand everyone will have a local copy of the project on their machines, but what is the best practice for maintaining a master working directory? I understand that's basically what the repository is, however when the time comes to JAR the classes and distribute the application, should this just be done from one of our developer's local working directories?
[Updated on: Mon, 17 December 2012 15:53] Report message to a moderator |
|
|
| Re: Best way to use GIT in our environment? [message #991185 is a reply to message #991181] |
Mon, 17 December 2012 16:14 |
|
On 12/17/2012 8:52 AM, Thomas Mancini wrote:
> One of the main reasons we're deciding to use a VCS is because of
> cleaning/building issues we've had on Eclipse due to the code being on a
> shared network drive.
> 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. We've unchecked the 'Build Automatically' flag
> because that seemed to give us even more problems.
>
> I have been messing around with SVN a bit. I created a repository and
> imported an existing project into it, however this did not create a
> working directory out of the project (I knew it wouldn't). I guess my
> confusion is coming from the fact that I understand everyone will have a
> local copy of the project on their machines, but what is the best
> practice for maintaining a master working directory? I understand
> that's basically what the repository is, however when the time comes to
> JAR the classes and distribute the application, should this just be done
> from one of our developer's local working directories?
This really isn't an Eclipse topic.
Changes move on independently, but developers push or commit them as
they reach a point in their own copy where some objective has been
achieved (even a tiny objective and, in fact, that's smarter than making
sweeping changes that will have to inflicted on colleagues) and unit
testing confirms that the changes were righteous. (Of course, you wrote
the unit tests to confirm the changes before even making the changes.)
Then, the developer commits the code via svn commit. You use svn status
to keep an eye on the magnitude of what's going on in your changes.
Other developers update via svn update to get changes. If there are
conflicts, they will need to be resolved. Conflicts are marked in
Subversion identically to how they're marked in Git (see the HEAD/jack
illustration at
http://www.javahotchocolate.com/tutorials/git-merge.html#resolving-differences).
The conflicting code will not compile (no matter what language you're
in). You edit it to choose what to keep and what to delete, then commit
again.
That's the short of it. If you wish to keep asking questions on this
topic, you should ask them directly of me as it's already gone well
beyond the interest of this forum.
Russ
|
|
| | |
Goto Forum:
Current Time: Thu Apr 25 05:04:02 GMT 2024
Powered by FUDForum. Page generated in 0.10124 seconds |
] 
Search
Help
Register
Login
Home
