I developed 3 projects that, despite sharing 80% of the code, the way they get data is completely different. The sharing code is basically UI, helpers, some model classes, among others.
Now I have been able to create a single project that contains these 3 projects organised and structured by targets. I am also trying to achieve a branch creation for each target so, is there a friendly way to organise branches by targets in Xcode.
Maybe the question does not make a lot of senses. If so, let me know.
I think a better approach is to put the 80% common code into a .framework that is used by the 3 apps. The framework and the apps need their own git repo (so 4 total) and you can use git modules to import the framework repo into the app git repos.
Your approach is counter-intuitive as it's more conventional to have a separate git repo for each app and it can be fiddly to cherry-pick between branches if you are making changes to the common code.
Related
My team is working on translating several legacy mobile applications to Xamarin Forms apps. Currently each application is in its own solution, which is not ideal when it comes to the fact that they all use a common set of backend software libraries. We were planning to consolidate all the smaller solutions into a single solution, containing the apps as well as the common libraries.
However, one of my teammates brought up a valid concern about how with a single Xamarin Forms app, several projects could get generated (core, Android, iOS, etc.), with the eventual result of a generally unwieldy solution. I agree with him that the current setup probably would not scale too well as we add more apps -- even if we group projects in solution folders, Visual Studio will eventually slow to a crawl after a certain amount of projects exist in the solution.
So we are considering just going back to having each app in its own solution, each solution containing the few Xamarin Forms projects for that app, as mentioned above. But this brings us back to the question of how to reasonably manage the shared library code. My current thought would be to just use shared project(s) for the libraries, or maybe assemble them into NuGet package(s) the app solutions would consume. Am I on the right track here, or does anyone know of a better way to do this?
There are several different ways to manage a shared code project using subtrees, submodules, NuGet packages, etc. There are pros and cons to each so it's best to decide based on the expected use case for that project.
Subtrees essentially take a copy of the remote repo and pull it into the parent repo. This makes it easy to pull in changes from the remote repo but if changes are expected to be pushed back it can be significantly more difficult since it has no knowledge of the remote repo. While it is possible to push changes back it can take a significant among of time to do depending on the amount of history of the repos.
Submodules are similar to subtrees except that instead of taking a copy it tracks the remote repo based on a specific commit it's pointed to. This essentially can be thought of as another repo inside of the parent that makes pushing changes back to the remote repo much easier but at the cost of making pulling/updating from it a little bit more difficult.
NuGet packages are extremely convenient to install, update, and release to others without having to make the source code public, but that comes with a bit more initial setup to generate each package version and comes at the cost of making it more difficult to debug than with the actual source code. This is particularly a great option if the shared code library will be distributed to others.
For most projects, if changes are expected to be potentially made to that shared project from a consuming one I'd recommend a repo for each project and set up the shared one as a submodule in each. It does take a bit of learning to get used to the different processes of checking out and updating a submodule but actually isn't all that difficult and worth learning the few git commands required. The docs provide a great example of how to get started using submodules.
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've started working on a new Perl module and I've decided that I want to make a Ruby version of it as well (once I finish the Perl version). Do people tend to make separate repositories for each language? Or put them in the same repository?
I can easily see how the two sets of code are different enough to be treated as separate projects. But at the same time it's the same functionality written in two languages, so from that perspective it seems like a single project with two language ports.
What's considered best practice in this situation?
FWIW, I'm using git.
EDIT: I should be more clear here. These aren't modules in the sense of git submodules. They're modules that will be submitted to CPAN and RubyGems. Users of this project will likely be installing it via cpan or gem and then using/requiring it in the normal fashion.
In the course of my group's research, we have a couple repos, some with different technologies in each. We divide the repos by research question and checkout only the projects we are working on, with the repos having a uniform hierarchal directory structure that is the same for all projects. Since we already know the repo directory structural, running scripts and finding data becomes much easier.
I would recommend taking the same approach. The higher the division between the two technologies, the easier it will be to contribute to one of them without being confused by the presence of the other.
In the end ask yourself this: If I were to add another language, would I still keep it in one repo? If the answer is yes, keep doing what you're doing. If not, keep these libraries in two separate repos and manage the projects and contributers distinctly.
my experience in this kind of case is to have 2 smaller git repos for each of the modules and either cloning one branch into the consumer projects repo makes it quite simple. another way is to create a naked clone from the module's repo into the consumer projects repo, then just keep updating it as each module's development progresses. the consumer project should ignore the injected repos.
once other dev clones module A, and/or B, then he/she can just push to consumer project, as permissions allow. this is either a pro or a con depends.
Picture the following scenario. I have an iPhone application contained in Xcode project A, and an iPhone application contained project B, each one of these Xcode projects is contained in a separate git repository. There are a bunch of things that I would like to do:
Be able to create a library or Framework from parts of project B that I would then use in project A or other projects. How can I create a Framework in Xcode, and then clone it into another project using git, so that any changes I make to the framework are reflected. Ideally the framework would remain part of the larger git repository and Xcode project B.
Without creating a framework, how can I do the above, namely, import a part of a git repository (call it B1) into another one A, so that I can still keep on developing and improving B1 as part of B, but can eventually see those changes in A?
Last point: is there an easy way to merge two Xcode projects (if they have fairly similar structure) using git, or a recommended way, at least to make it as painless as possible.
the first two you ask about can be done using
git submodule --add <remote repository>
manpage
As for merging you could try creating git project C with git project A and project B as remote repositories. Assuming no or little overlap in files they might just merge together seamlessly. I think however that submodules is probably a better bet.
The best solution I have found to this problem is basically to create a static library out of any code I want to use between the two projects, and then import that from the other Xcode project. Very well explained in this post here:
Shared Libraries
This allowed us to keep the repositories separate, but still pull from one another as needed.
If I have a C# solution with multiple projects in it, what would be better, to have the Git repo created in the solution folder, or in each individual project folder? Multiple developers will be working on the projects. What are your experiences with this?
I use several (sometimes overlapping) solutions to contain a collection of related independent applications and shared libraries. As others have mentioned, you really don't want to have a single Git repository containing the source for multiple, independent projects as it makes it much too difficult to track isolated changes.
So, if your solution is structured as mine is then you will definitely want individual Git repositories for each project. This has worked well for me for ten to twelve applications and doesn't create as much maintenance overhead as you might think.
If your solution is truly monolithic (and you're sure you want it that way forever and ever), then it probably makes sense to only have a single repository.
It depends. git repositories are most suited to containing a single configuration item with its own independent lifecycle. If your projects have their own release cycle and are shared between multiple solutions then it might make sense to have them in their own repositories. Usually, though, it is the solution that represents a configuration item with all the constituent projects forming part of the same build. In this case a single git repository at the solution level makes more sense.
git submodule is probably worth consideration here. Each project gets its own repo, the solution gets a repo, and the projects are submodules.
I assume that your solution represents some kind of a product while the projects are just a part of the product.
In this situation I would create the repository on the solution level. This way it is a lot easier to build the whole product at once, especially if the projects depend on each other.
Some though and 3 solutions on the subject can be read on that blog:
https://www.atlassian.com/blog/git/git-and-project-dependencies
package management tool, i.e. nuget in VS, so using reference to a package/compiled module
git submodule (only with command line in VS?)
other build and cross-stack dependency tools
Another solution is just to add a project from the other repo and let it out of the current repo, and latter use the Team Explorer to commit its changes.