I have been using Eclipse IDE with egit and pdt for a couple of years. I have a local git repo outside my workspace and a remote private repo, largely for bckup - I am the only active developer. In addition to my projects (several sub-projects) I have imported a Joomla installation so that I can debug my projects in their working environment. So far so good.
Recently, I needed to start work on a big upgrade. So I created a new workspace and a new local git repo cloned from the remote repo. I imported a different Joomla installation and created a separate branch for the new code.
I am using one workspace to push to the remote master and the other workspace to push to the remote branch. I can 'see' both branches in both workspaces and I get myself confused because they are not usually in sync. And I get very confused when it comes to merging something from the master into the side branch. So far I have muddled along but I can't help feeling this is wrong and bound to lead to disaster.
It would be fair to say I don't know nearly enough about Eclipse or Git to figure out how I should have set this project up in the first place. And I don't know the exact steps I followed to set up the structure I have right now.
Can someone offer advice on a practical repo and workspace structure for working on branches that require different testing environments?
Related
I am sure this is a RTFM thing, but after a few days of research I still cannot determine the correct (or best) workflow for this.
I have an Eclipse Workspace with a number of Java Projects in it and a number of C++/Arduino projects.
I want to start using GitHub as an online repository (easily reachable from outside my private LAN dev environment) for my projects
I was thinking I would like a separate C++/Arduino and Java GitHub repos. More could come for Python, PowerShell, etc. (But I will happily entertain other recommendations for repo structures).
Outside of the actual mechanics of using Egit, I cannot figure out the most appropriate workflow/folder structure for accomplishing this. Should I create local Git repos and push to GitHub as a remote? Should I use GitHub's web interface to import the entire Eclipse Workspace? Should I work directly with the Eclipse Workspace or have separate Git folders?
I guess the crux of my problem is that after reading a few related posts on this site I get conflicting advice about creating a local repo from the Eclipse workspace vs. a separate local repo. I think I need to understand this distinction first before I ultimately determine the best overall workflow.
I apologize for the broad nature of this question, but I hope that the community can help me narrow the workflow process design (or the question itself).
Two things up front:
Never put your entire workspace in source control; projects: yes, workspace: no. The .metadata folder contains data specific to that location and your machine, and that's ignoring any potential security risks with making it public.
eGit works with your git clones' own metadata, so if you're more comfortable doing certain things from the command line, go for it. I know I am, but I still appreciate the UI and decorations that eGit provides. Just make sure any automatic refresh/update preferences on the Workspace or Git preference pages are turned on.
You probably want the repository to contain multiple projects, rather than having a separate repository for each one. That way histories and changes that belong together are together. Nest the layout however you like, but remember that you're not constrained to a single repository for everything, either.
I don't know that there's a best practice for this, especially with projects that already exist, but projects should themselves be relocatable. My recommendation, after backing it all up:
Make the Github projects, clone their repos locally. I do it this way, from the command line, to save me any headaches with the history, remotes, and refs. I don't think you can modify the repository metadata in this method, though.
Move the workspace projects into the local clone. You can delete them from the workspace (be sure not to delete the underlying files), physically move the directories while outside of Eclipse, and then import them as projects back in from the Git Repositories View--unless they're Maven projects, in which case it's better to use M2E's import wizard.
Stage, commit, and push the projects up to the remote origin. For Java projects, don't forget to set the JRE System Library in the Java Build Path to use an Execution Environment. It's a simple bit of indirection that makes them more portable across machines.
We are trying to set up Eclipse so that two users can share the same project directory on our server. Is this possible? Every time we try, it creates a new folder and project.
Thanks!
Chris
No, this isn't possible. Eclipse only supports a single user accessing a workspace (not just a project) at a time.
Use a source control system such as Git or SVN to share code. Eclipse supports many such systems and has extensive sharing support in the 'Team' menus.
The best way to do this would be to use source control.
Sharing the actual workspace or the files with different eclipse instance is a recipe for trouble.
An easy way to do this would be to install git on your machine and also on his machine. Eclipse actually already has git in it ready to go so you probably dont need to install anything.
The one with the files locally will create a repo locally on his computer and commit the files to it.
Next you want to init a new empty repository on a shared folder and push your local chances to this as you would to github for example.
Your partner can then git clone from this repository to his machine and work locally.
Each of you will develop on your own copy and commit your changes locally. You will share your changes by pushing your commits in that central repo and pulling from it to get changes from your partner.
You could also just open an account on GitHub, GitLab or BitBucket (there are many others too) and use that instead of a shared folder. big advantage with these services is that they will be available from anywhere.
I am experimenting the use Git to manage development environment for one of my client project which is on CVS (and can't move out). Since the environment is quite complicated and has multiple steps to setup, I am hoping version controlling would help. So far it is actually very helpful to do it. However, all the project CVS setting (like the CVS module and branch) are not tracked by git via EGit plugins. so when we recreate the environment we have to reshare the projects that is really inconvenient.
I dig down on the issue and found that EGit does not track CVS folders in those project so the CVS information is lost.
Is there a way to tell EGit to track those folders?
Thanks all.
I'm trying to set up EGit with Eclipse and I've used neither of them before. I understand the basics around Git and Eclipse is more or less just another IDE. The problem I'm having is setting up a reasonable work environment.
I have file-server at home which I want to use as a Bare repository which I push and pull changes to. To test it out I've done the setup locally.
I have a bare repository created through the Git Repository perspective.
I've cloned that repository into a local non-bare repository.
I've created a project in a subdir of the non-bare repository (is this the way to go? Is it possible to do have the project directly in the workspace with the .git folder within it? So far I've had a lot of trouble with it when trying to create an Eclipse project out of it. What is the proper way to do it?)
I've made some changes to this cloned repository and added the indexes, committed the changes and attempted to push the changes to upstream.
The thing is that no changes are made to upstream. Would someone like to explain the procedure in doing the push so that I'm not misunderstanding something? Or am I completely wrong on utilizing a bare repository instead of just working non-bare?
As mentioned in this tutorial, you create your Git repo right where your project is (ie your .classpath and .project files are).
Pushing to a bare repo is a good idea (see the links mentioned in "Git - pull & push - production server")
You need though to specify what you want to push:
Click at least on "Add all branch spec".
Group,
We use Borland Starteam as our source control system. I develop Java code and use Eclipse as my IDE. I recently started using EGit as my personal source control system and came up with the following workflow to streamline my dev work, which consists of checking out code, adding features, fixing bugs, testing, merging with the parent source in Star team (huge effort if lots of people have made changes in the meanwhile), build, test, and install. I want to use EGit to simplify the compile, merge and test process, while developing and also just before code install after big merges are made. This is what I have come up with.
Create file system folders - 'Master' and 'Work'
Check out fresh source folder structure from Starteam into 'Work'.
Create Eclipse workspace called 'Work' and import Eclipse projects from 'Work' folder add those projects to an EGit repository.
Add features/fix bugs while in 'Work' workspace. Test, etc. Create a patch when ready to install. Now its time to make the big merge, rebuild, test again.
Check out fresh source from Starteam on the day of the install into 'Master' folder in the file system.
Create Eclipse workspace 'Master' from source in 'Master' folder, import Eclipse projects and add those to a newly created EGit repository.
Import patch into 'Master' workspace, perform merge. Fix compile errors, test, etc.
Install.
Is this workflow efficient? Are there more advanced features in EGit that would simply this any further?
Thanks for any guidance.
Ranjit
Unless I'm understanding this wrong, it looks like you are using eclipse workspaces in place of the existing git branch functionality. Egit, if I'm correct, can manage branches all on its own so you don't need to run back and forth switching workspaces. You can create then merge branches and do all the other fun stuff within a single project.
The workflow from here is all git. A good article on maintaining a sane workflow can be found here: http://sandofsky.com/blog/git-workflow.html