I am wondering how to manage kind of git "parent" repository.
I started with Android project, where couple of first commits are preparing a project - additional Gradle plugins, dynamic versioning, etc.
Now I would like to externalize it to separate repository, which can be a kind of the template for new projects but also a common place to maintain a project configuration like Gradle and plugins versions, build and sonar configuration, etc. So when I change anything common to all projects, I can easily merge it to all "child" projects.
I thought about few approaches:
fork from the parent project - not really sure, because it is not a real fork
separate projects with remote to parent or parent with remotes to children and pull/push
git submodules it is rather not helpful in this case, or I am wrong?
others?
others...?
Related
Using android studio 1.0 for my project, I plan to code a library module inside it. But I am wondering whether sharing only the library module (for example in its own github repository) is easy : I mean, someone fetching this repository, can integrate it as a library module in its own project easily. Also, does the library module has to define at least an activity, or can it just contain independents classes and resources ?
Of course, I also plan to share the global project on a github repository.
So what is the "safest" and easier way to proceed ?
Apologizing if the question may seem too obvious or bad explained.
The only real way to separate a project into multiple git repositories is through submodules. It's not a bad concept, but what it effectively means is that you have a git repository inside another. One the remote side, they are separate repositories with one being included via submodule.
More information, and the command line tools you'll need to get started can be found at: http://git-scm.com/book/en/v2/Git-Tools-Submodules
Note, there is a lot of hate for submodules, and some of it is earned. It's not intuitive and is often considered an expert Git feature. For that reason, I recommend you read it thoroughly and make sure you understand. Perhaps even throw together a couple of unrelated repositories to play with. BTW, you can have a git repository on your computer anywhere (git init --bare to create it). Then you can clone it anywhere else with git clone file:///<your-path-here> Thus your local and remote are on one computer so you can play/learn without having to create more repositories on git hub or some such.
Since you are using Android Studio, I assume you use Gradle as the build system. With that assumption, below are my answers:
Your library project needs not have Activity, but will need AndroidManifest.xml and a Gradle project layout (src, res folder etc).
If your library project is hosted on Github (or locally outside the root folder of the main project you plan to use it), then you can use Git submodule like lassombra suggested to bring it under root folder of main project.
Once you have the library under the root folder of your main project, you can use Gradle multi-project setup to link them.
I want to organize all my java, C and Android projects with Git.
I have several folders:
something_like_gdlib
example_library1
example_library2
...
example_project1
example_project2
...
In each of those projects I use some of those libraries. But if I update a library, I want all projects to get the changes for that library.
Usually I work alone on those projects and I just want to have a change history.
Now I want to work together with another programmer, that should get access to only one project and the corresponding libraries.
How should I set up git? I heard of subtrees or submodules? Or is there a better solution?
Submodules or subtrees could indeed be a solution.
On the other hand you could keep the repos totally independent from a git point of view, and publish your libraries.
Eg: Assuming you're working with Maven in Java, when you want to upgrade example_library1 in example_project1 you could:
Build a new version of the library (and tag the corresponding commit)
Put this binary either in a local or shared maven repository
Update the version of the library in the pom.xml of your project
An advantage of this approach would be that there are no need to do anything complicated with Git
Drawbacks would be:
It may be cumbersome if you want to upgrade in your application every time you commit in your library
If you don't already have a "package architecture", you may need to set it up first
I recently wanted to adopt submodules from GIT with my Android projects but stumbled into some problems.
Backstory
I have multiple projects but many use the same external library (Android library-project), in order to make the GIT cleaner and make the GIT for each project contain all the needed material I though of using GIT sub-modules for the Android library project. This part works fine I got the library included as a sub-module for the projects.
Issue
But Android uses these library-projects which basically is a regular project which is added to the project and I can only add the same project once in Eclipse. So if I need to work on more than one project at a time I have to use multiple instances of Eclipse/workspace instead of using Eclipse the regular way.
Is there a way to have only 1 instance of my library project in eclipse and at the same time have all the projects reference to their respective libraries? Or any other suggestions how I should handle this?
Any help is very appreciated
You cannot have the library project as a single instance in Eclipse for the following reason.
Each project which uses the library might reference a different version of the library. Since your submodule is a physical checkout (working directory) of a particular version there is no way to represent more then one state of the repository at a certain point in time.
Workaround:
Prepare a "server" location for the library project. It is good enough to create a clone using git clone --bare.
Clone the "server" library project into your workspace.
Prefix the library project to reflect the name of the main project it is used in.
Repeat step 2 and 3 for each main project you need the library to work with.
Everytime you do changes in the library project create a feature branch. In each main project consider if the new feature might be useful or hindering. If it does not fit you obviously need to rewrite the feature you just created. When you are done update the version of the library (don't be shy using tags with Semantic Versioning).
I have a large Android Library project of reusable components that multiple application use. This library is under git control. The multiple applications that use this Android Library need to point to different commits of the Android Library project (Git Submodules). But Eclipse does not let submodules be children directories of the current project but rather siblings in the current workspace. How can I make this work?
For instance if I update the Android Library for and one of the applications, I still want the other application pointing to the original commit of the Android Library.
Any help would be much appreciated...
For my projects I keep the submodules as subdirectories within the original project and then import the submodules as separate projects alongside the parent.
I have an android project versioned with SVN. I have three eclipse projects inside my repository. Library project, free version project, paid version project. My current repository structure is:
repository/
branches/
tags/
trunk/
freeversion/
paidversion/
library/
Is there a better structure for this contents?
Thanks!
Are the two versions of the application going to be so different that they require their own views, intents, activities, etc or does the paid version simply add more functionality to the application?
Either way, I would probably share everything except for the views, which is usually all that's going to make a difference to the user once they run the application.
Something like this:
repo/
branches/
tags/
trunk/
src/
lib/
views/
free/
premium/
Upvote for rage faces!
I use the above structure, with a few tweaks to support re-use of library projects:
In each app project, I create an externals dir, with all library projects loaded via relative svn:externals
svn pg svn:externals externals/
../../libSquello libSquello
../../FacebookSDK FacebookSDK
In each project, I modify default.properties, to reference relative paths to libraries
android.library.reference.1=externals/FacebookSDK
android.library.reference.2=externals/libSquello
I like this approach because as my collection of apps grows, I can checkout a single project instead of needing to checkout every app to ensure I've also got the dependencies
The down-side of this approach is that you need to take a little care if you edit the library files inside multiple projects.