I'm developing with Laravel a suite of applications which are very different from each other, but must have the same base (graphics-functions-components-login-ecc.).
I just finished the base project, which I simply called 'template', and which is under git-versioning.
Now I have to develop the real applications, which will be extensions of 'template', but I want to keep pulling the base from 'template' and create some sort of 'git extension' for each application.
I would like to do this to keep the laravel tree structure of the project (so not use external folders) while avoiding to update each single application when I modify the 'template'.
I thought about link the same project folder to two different repositories (template+extension), using 'gitignore' to manage which file links to which repository, but I think it could be troublesome in case of new file added or so.
Maybe git has already an existing way to solve this, but I'm quite new and not expert to this, so I hope you'll guide me to the light.
You can use git Submodules. Submodules are Git repositories nested inside a parent Git repository at a specific path in the parent repository’s working directory. For detail visit https://git-scm.com/docs/git-submodule.
Related
Let say there is a team working on main Git repository using branching model. Now a second team joins and is starting to work a subset of a project. As the starting point they need to collaborate on one folder from the repository. They are not allowed to see rest of the code base. What is the best way to achieve that?
Going forward they would need to be able to merge their changes into the main code base and get any updates from that one folder along the way too.
This is all based on Windows OS with Atlassian Stash and Git on internal network.
That would mean that one folder needs to be its own repo:
added as a submodule (tracking a branch) in the main Git repo
forked by the second team, for them to push to the fork and make PR or synchronize from the original folder git repo.
I would suggest separating the subset into a sub-project, and use language-specific ways to deliver it during building of you main project. For example, if you use MS Visual Studio, you could turn it into library or module and use nuget to deliver it during build of your main project.
In my experience it appears to be much more convenient than using submodules, when it comes to merging.
Another reason to do that - and maybe even more important one - that the other team would be able to handle the project as a compilable and testable unit, instead of a pile of source files.
I have several projects which use code from a large set of component libraries. These libraries are under source control.
The libraries repository contains all the libraries used by all my projects and contains multiple versions of multiple libraries. Each library/version pair lives in its own folder. Each of my projects identifies the specific library/version pairs it needs through the folder paths of the references in its project file.
For example $(LibraryPath)\SomeLibrary\v1.1.5
Please note that the libraries repository is only ever added to. No changes are made to stuff already in the repository. Ever.
I have been of course been able to configure my build plan to pull the libraries repository to a libraries subfolder of the working directory. So far so good. However, using the auto branch management feature of Bamboo, this setup means that the libraries repository is cloned for each and every branch in all projects.
Not funny. No, really, not funny...
What I would like to do is:
pull the libraries repository in each build plan
but pull it to a fixed location that is the same for all build plans
it doesn't have to be an absolute path
but it does need to be outside the working directory of the current build plan to avoid unnecessary duplication
Unfortunately the Checkout Directory of the Source Code Checkout configuration task in a Bamboo build plan doesn't allow me to specify either an absolute path or a relative one that goes "up" for one or more levels from the working dir. The hint text explicitly states "(Optional) Specify an alternative sub-directory to which the code will be checked out." And indeed, specifying something like ..\Library gets punished with the message "Checkout to parent directory is forbidden".
I have seen information on the "artifact sharing" feature of Bamboo. This will probably work, but it seems like overkill for what I want to achieve.
What would be the easiest and least complicated way to achieve my goal using Atlassian's Bamboo Continuous Integration?
Out-of-the-box alternatives are welcome, but please don't direct me to any products that require intimate CLI use and/or whose documentation assumes (extensive) knowledge of 'nix and/or Java setup. I am on Windows and spoiled rotten by powerful (G)UI's.
I have the same problem - with a repository weighing in at around 2GB.
I'd like to simply "git checkout myBranch" and "git clean -fxd" instead of cloning every time (which should save a lot of time and disk space). However I also like Bamboo's automatic trigger with new branches showing up.
Like the OP, I'd love to be able to put "..\SharedDirectory" in the "CheckoutDirectory" for the
"Source Code Checkout" task but it won't let me go out above the \JOB_KEY\ folder
One possible solution is: replacing the "Source Code Checkout" task with the two git commands above. That way I can specify exact when/where/how to do the checkout. I think there may be problems with the initial checkout in this case - but once that is solved, all subsequent branches would use the same shared folder, and no more pulling down 2GB every time.
We have 3 projects and a 4th one that is shared among them.
A multiple project in gradle requires one to create a wrapper project and include all the sub projects in it.
Each of our sub projects are being worked on by different team members and we use git as an svn.
Our concern before going into gradle is the fact that we will only have 1 git repository that consists of the wrapper project with all sub projects instead of 4 different repos, each for each sub project.
1) Are we missing something?
2) Is it possible to create 4 repos on a multi project?
3) One of our requirements is to deploy a single war (for example only webapp #1 out of the 4)--does using the multi project template make it possible?
ad 1) You have some choices:
Use a single Git repo.
Use multiple Git repos and exchange artifacts via a binary repository (e.g. Artifactory), with artifacts being produced on a regular basis by CI jobs.
Use something like Github submodules to create a "virtual" overall Git repo (wouldn't recommend this one).
ad 2) Gradle doesn't really care how many Git repos the build is comprised of, as long as everything that settings.gradle points to (at least all build scripts) exists on disk when the build starts. Of course it may be inconvenient for developers (and CI admins) to juggle multiple Git repositories and put them in the right (relative) locations.
ad 3) Yes.
I stumbled across this question on the same quest, and only later somebody pointed out another option to me (it's really a variant of the third choice listed under ad 1 in https://stackoverflow.com/a/20678444/1016514), which seems like an elegant hack:
You keep the subprojects in separate Git repos, and from within your root project point to them by setting the respective rootDir properties. This requires a fixed checkout layout, obviously, but that would usually be the case anyway.
The approach is described here: https://medium.com/codequest/gradle-multi-project-build-substituting-jar-dependencies-with-local-projects-4a5323f8680b
Update with Gradle 7.3+: this will now yield a warning, and likely not work after some point in the future:
Subproject ':xyz' has location '...\xyz' which is outside of the project root.
This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0.
Consult the upgrading guide for further information:
https://docs.gradle.org/7.3.1/userguide/upgrading_version_7.html#deprecated_flat_project_structure
I want to use Git for some personal projects I work on. I'm new to git and don't know how to start...
Should I first create the project (say an ASP.NET MVC application) in Visual Studio and then turn the folder that is created into a repository, or should I create a repository first and then create the project inside that folder?
Also, are there any best-practises for how to structure the folders inside the "repository root folder"?
These are my two questions right now, but any pointers to articles etc for best-practises using Git and Visual Studio are welcome!
Git repositories are so lightweight that it doesn't really matter whether you create the project and then create the repo or create the repo and add the folders. You will anyway be doing a git add and git commit after the folders have been created.
But, for me, I usually create the project from VS and restructure the folders so that at the root there is the src folder and the .sln and project files are within the src folder. VS would typically create the root folder with the project name which I rename to src. Then I create the repo, add the standard .gitignore and .gitattributes and commit the repo.
See my preferred structure here: https://github.com/manojlds/cmd
Of course, you can have whatever structure you want.
For using in VS you can use Git extensions. It integrates into the IDE and provides nice GUI over the basic Git operations.
As for the folder structure, it depends so much on the project, so no answer can be given here. There's no better practice than organizing based on the way you work!
As for the moment of repo creation, just create it as early as possible, so I'd say first create it and then add your project.
Organize your files and folders however makes since to your project and workflow, git doesn't care how the files are organized.
Since Visual Studio complains when I try to create a project in an existing folder, I follow the following steps.
Create a bare remote repository.
Clone empty repository locally.
add .gitignore, etc. and make initial commit.
Create VS project in a different folder.
Then I do one of the following.
copy the files from the .git repository into the VS solution folder -- which changes the location of the local repo.
close VS, copy solution files to local repository and then reopen VS.
I really should take the time to automate it, but I spend more time working on existing projects than starting anew so it hasn't been much of an annoyance yet.
I've tried all the visual git tools, including those that integrate with VS, but always end up using PowerShell instead -- just a matter of preference. Give them a try, they may work well with your workflow.
We develop with Visual Studio 2010 (in C#) and migrated a while ago from SVN to GIT. Now we try to split up our repository (which is quite big - ~30.000 files) to many git repositories - one for each solution.
The solutions share some projects, mostly libraries we develop in-house and like to add to from all the solutions.
The new repositories have a flat layout. One subdirectory for each project (shared projects are submodules).
In the big old repo, the projects are in a tree structure.
The Problem occurs with external references in the submodules. In the new repos, the path to a referenced project may be "......libs\someproject", while in the new layout the correct path would be "..\someproject".
We already had some edit wars concerning this and are not keen on more.
Half-baked Solutions I could think of:
use "Reference Paths" in ...csproj.user and exclude this file from version control (has to be redone for each developer and after each reopsitory cleanup)
use branches for each situation and try to teach everyone where "real" commits should go and where "environment-change" commits should go (submodules are already not the simplest concept...)
embed binaries instead of the submodules (but what about developing changes to the submodules? what about different log4net versions?)
Does anyone know of a sane solution?
Since you are asking for a sane solution, I can only advise you to look into setting up your own NuGet service (look at http://www.MyGet.org for inspiration)
http://nuget.codeplex.com/
IF you go down the route of package management, consider OpenWrap. However, embedding the package management artefacts in source code is a bad idea. You can use such tools to update what is actually stored in submodules, but don't rely on them at build time. Expect the binaries to be there from the point of view of your build scripts.
So if I understand you correctly, the problem is with Visual Studio and not with Git? If that's the case, use the old tree structure that worked with Visual Studio. Make your submodules structure a tree structure too. So the top of the tree would be one super repo whose sub modules (the branches) would have submodules of their own, until you get down to the leaves of your tree. It would be a pain to setup at first, but it should just work.
Use one submodule to house all "common libraries". Just one level. But you should move the common libraries as services with well defined contracts. This way you can incrementally rollout new versions with no down time. This way you only have a submodule in each that holds the contracts. These could be interfaces or messages.
I have a similar problem using VS 2013.
I want to use git-svn instead of SVN directly. SVN has a gigantic set of directories. I could not create a single git-repository that would contain all of our trunk folder. Git-always exited with an error and the repository was corrupted. I worked around the problem by doing as follows:
Using git-svn, I cloned the subset of folders off SVN/trunk that I needed by creating one git-repository per folder.
Created a local parent git repository that contains all my git-svn-cloned folders.
Each git-repository was added as a sub-module to the parent git-repository.
The problem with Visual Studio is that it does not recognize the multiple projects outside the main project where I opened the solution. This solution is in a folder that contains the only files recognized by Visual Studio as being under git-source control.
I tried setting the git-preferences to use the upper level parent directory as the location of the git-repostitory without noticing any difference.