Best way to use git with Liferay development?

[Cameron McBride, geändert vor 12 Jahren.]

I wanted to get an idea of how others were using git (with Liferay) for their custom development, particularly in an environment where there are several developers. Up until now I have worked on projects using CVS and SVN. It's time to make a change...

Are you using one big repository for everything, several smaller repositories (like one for all your portlets one for hooks) or a separate repository for every portlet, hook, etc?

If you are using one big repository have you created folders in there like /repo/portlets/<project> and /repo/hooks/<project> where your developers can check out just one portlet?

Does each developer have the ability to commit changes back to the remote repository? The alternative would be higher level developers check out other developers changes when they are finished and they commit them if the code is good.

Do you do any peer-to-peer source control where Sally can check out Billy's branch and try out his new feature?

Does each developer have their own remote repository where they can check in experimental work but keep it separate from the main repository? Good for letting other check out your work and so when the boogeyman breaks your laptop nothing is lost.

What does your environment for git look like, meaning windows local workstations, linux git server or windows local/windows git server, etc?

[Cameron McBride, geändert vor 12 Jahren.]

I found this wiki guide on sharing projects: http://www.liferay.com/community/wiki/-/wiki/Main/Liferay+IDE+Sharing+Projects It doesn't really go over git or any other SCM. It also makes sharing projects seem crazy complicated.

Update: I suspect method 1 of this guide is no good for git since you will be checking out everything and not just one portlet.

[Jack Bakker, geändert vor 12 Jahren.]

yeah, we really need a good git wiki for per project sharing

I am using LR and git extensively through github, with a github 'organization' with repo stored in each LR IDE project (I do this to share with portlet developers in one github team and theme/layout developers in another team, where for some their paths may cross)

for helping out on the Liferay IDE front through github, you may want to read: http://www.liferay.com/community/wiki/-/wiki/Main/Build+Liferay+IDE+From+Source+using+github

I think git is fantastic ; but also has incurred and continues to incur for me a wacky learning curve - I try to hang my single hat on a tree of life where the head of one limb might need merging, rebasing, and so on across branches/forks of dev

[Cameron McBride, geändert vor 12 Jahren.]

I followed method #2 of this guide: http://www.liferay.com/community/wiki/-/wiki/Main/Liferay+IDE+Sharing+Projects and I checked in the plugins SDK into git.

My complaint is that my plgunis sdk shows up in Eclipse under source control, my individual projects do not...event though they are linked. See my attached picture where the blue arrow shows me plugins sdk under revision control. The red arrow points to my portlet, which really exists in the plugins sdk. It would be more useful if it also showed as revision controlled...

[Jack Bakker, geändert vor 12 Jahren.]

install eGit
right click LR project
Team
Share Project
git
check "Use or create repository in parent folder of project"
click project
create repository
Finish

in git repository exploring perspective, I created remotes for push, fetch as needed to github repos

--
I am on Ubuntu with Indigo and above went smoothly ; but another I work with is on Windows and wasn't as smooth and I had to move .git folder into the actual project folder as it ended up nested in another folder with same name as project, but I can't remember the details right now and don't really know why there was a difference

I'm sure someone else can do a good wiki on this but my brain dump above is all I can do atm

[Cameron McBride, geändert vor 12 Jahren.]

So that means your making a new repository for every hook, portlet, theme, etc? I was going to try to keep them all in one repository similar to Method #2. When I shared the project with git I picked the egit box to keep the project in its current location, which means it made a .git folder inside my project.

I am now trying to decide where to put portlets that I want to keep safe (off my laptop) but I don't want to store them in the remote master branch.

[Jack Bakker, geändert vor 12 Jahren.]

So that means your making a new repository for every hook, portlet, theme, etc?

yes

I seperate per project because I/teamMembers want/need to push/fetch on per repo basis where github organization 'teams' are given access per repo - thus segregating expertise amongst each in a team according to a need to know basis delineated by theme/layout, portlet ... etc.

on the offsite backup front ; well, there is bacula... and also whatever repo you might push to ?

[Cameron McBride, geändert vor 12 Jahren.]

Your multiple repository approach seems interesting. Can you elaborate on how you handle a few things.

What steps do your developers take to get a portlet/project from the remote into eclipse?
File->Import-Projects from Git
Configure URI (yuck no way to browse and select the repository easily)
Change default directory from whatever it is to <plugins sdk>\portlets (if it is a portlet)
** Note you cant just select the parent directory here you have to actually paste or type in the full path (another yuck)
At this point it's already more complicated than management would ever accept over CVS.

[josejuan.montiel josejuan.montiel, geändert vor 8 Jahren.]

Hi, reading different aprox, why no pull to git the sdk directory ignoring "all" least new proyects... something like

cd PATH_TO_SDK
git init
touch .gitignode
/.project
/apps/*
/dependencies/*
/hooks/*
/layouttpl/*
/portlets/*
/shared/*
/tools/*
/webs/*
/ext/*
/lib/*
/misc/*
/osgi/*
/CONTRIBUTING.markdown
/README.markdown
/app-servers.gradle
/build-common-ivy.xml
/build-common-osgi-plugin.xml
/build-common-plugin.xml
/build-common-plugins-inspector.xml
/build-common-plugins.xml
/build-common.xml
/build-node.xml
/build-plugins.gradle
/build-themes.gradle
/build.gradle
/build.properties
/build.xml
/ci.properties
/common.bnd
/copyright.txt
/gradle.properties
/ivy-settings-publisher.xml
/ivy-settings.xml
/ivy.xml
/sdk.gradle
/settings.gradle
/source-formatter.properties
/util.gradle
/versions.gradle
# Themes...
/themes/*

git remote add origin [e-mail]
git push -u origin master

cd themes
./create newtheme "New Theme"

cd ..
echo '/themes/newtheme >> .gitignore
git commit .gitignore

## Another user
unzip SDK.zip
cd PATH_TO_SDK
git init
git remote add origin PATH/TO/REPO
git fetch
git checkout -t origin/master
git pull

And now, the share only new modules inside sdk

[Vishal Kumar, geändert vor 8 Jahren.]

More or less all repository have similar feature. But this is informational post.

[Jan Geißler, geändert vor 8 Jahren.]

Hi there!
We are also using git excessively. Our setup is somewhat different.
First the structure of our workspace in eclipse:
-workspace-dir
--liferay-plungins-sdk-XXX
--tomcat-xxx
--Servers

Now we do have one folder called git in an arbitrary dir. For example, I like to keep my git folder in my Home dir. (I am using a Mac) My Collegue has it on a separate drive on his Windows Machine. I just want to point out, that the location is quite unimportant.

So, we have the following structure in our git folder:
-myGitFolder
--portlet-repo1
--portlet-repo2
--portlet-repo3
--hook-repo-1
--hook-repo-2
--hook-repo-3
--theme-repo-1
--theme-repo-1
--...

We are using one Repository for one Portlet Project. The repos itself are build like this:
-master (current version of the LATEST Liferay release.)
-6.x GAX branches for every Version the portlets supports.
When we start to support a new Version, we develop against the master branch, BUT before starting the work, we create a branch for the Version supported at the moment. For Example:
Liferay has a new Version (let's call it 7). When we start adjusting the portlet to work with 7.X we would :
1. Create a branch from the master branch a call it 6.2GA4 (As this is the latest 6.2 release)
2. Adjust the master branch to work with 7.x

So far so good. There actually IS one more adjustment you have to do. In order for your ANT builds to work you have to adjust your build. I created a ANT property in Eclipse, to tell ANT where the Project Files actually are. Liferay Plugin SDK assumes, all your code is in the SDK directory in the known structure. However, this is not the case anymore, as all our Code resides in the subfolder of myGitFolder.
So we use our new Property to tell ANT where to look for the Code. (See Attached Screenshots)
This has some Pros:
- You don't have to check-in the Plugins SDK.
-You don't force a developer to checkout a lot of portlets he maybe does not need at the Moment.
-Devs can check out only the Repos they need. If you have dependent portlets, you can check those out individually as well, but most of the time you won't need to.
-You are quite flexible ;)

Also it has some benefits on CI. You have better control over everything.

Now a disclaimer:
This is all a very personal opinion (mine). There surely are people out there, who do things completely different, and may think this approach is not good for whatever reason.
Having said that:
Hope this helps you ;)


(EDIT)
Now I just saw, that this thread is a revival of an very dusty (aehm) thread, I will close this thread now.

[Fernando Fernandez, geändert vor 7 Jahren.]

Hi all,

I know this is an old thread but I'd like to add one more dimension to the discussion.

Many times our Liferay projects include some templates and user-editable content (web content, files/folders, etc.). These files, typically, are not accessible on the dev environment, so they normally don't make it into the git repository.

I've been using webdav to mount the liferay content on my filesys and then keep the versions on git but it seems a bit unstable. I'm using 6.2 CE ga6 at this point but it has problems with national chars in filenames, for instance.

Anybody has a different approach?

Thanks

Fernando