Recently i had extensive use of git subtree in a project.
Works all really fine.
Now it turns out, that this project will be reused a lot of times, whenever i need this kind of project for a customer.
You can imagine something like a "framework".
So in Visual Studio I would create a "Solution Template" for simple reusing of the skeleton parts, to adapt only when needed.
But since this skeleton was built with a bunch of subtrees (each of them is a project for itself), i need a mechanism to recreate the git subtree references.
I don't want that every developer which uses the skeleton (via solution templates or cloning a repository) has to know about the references to recreate them.
So, is there a (best-practice?) way of accomplish this workflow?
Thanks in advance
Related
First of all, thanks very much for having me in this community! :D
Secondly, let's go straight to the issue!
Today, I'm the unique responsible for a bunch of projects, and after some time, we decided to delegate these projects to other employees, because many times the code modification isn't needed to be made by me, the technician can do it easily. For today, each code modification is delegated to me, so in that way, its easy to control the Projects.
Then if we start working with more people, it will be more difficult to control these projects. Then I wondered (haha) that why don't use Git as our project controller?
I started deveolping an application that uses LibGit2Sharp (which is great!) for controlling the projects, but then I realized that I'll have to create tons of projects for controlling each one. And each projects is more like a configuration file, not development. It would be great if all these projects could be controlled in the same project (as a submodule, for example). I started looking for what submodules gives me and I don't think is the same as I need.
The project structure would be like this:
/Master Project
/.git
/MySoftwareV1
/Customer1
/.git
ConfigFile1.cfg
ConfigFile2.cfg
ConfigFile3.cfg
/Customer2
...
/Customer3
...
/Customer4
...
/MySoftwareV2
/Customer5
/.git
ConfigFile1.cfg
ConfigFile2.cfg
ConfigFile3.cfg
/Customer6
...
/Customer7
...
/Customer8
...
Is it possible to implement?
In this case, my application will control the submodules for the users check-out/in.
If you guys need more information, please don't hesitate to tell me!
Thanks in advance!
Best Regards
I would keep it simple, use a single Git repository without fancy stuff like submodules and instead mirror the project structure as a file folder hierarchy.
If you want to have more control on what the technicians do, you could let each one of them work on their own branch, so they can't damage someone else's work. It would be your (or your LibGit2Sharp-based application's) task to review their changes and to merge them to the master branch.
Since Git keeps track of the whole change history, you can always undo unwanted changes.
We have two projects written with c# on Visiual Studio, let's name them A and B. Both of these can be used as seperate products. Bu B can be integrated to A or to other products as a module. We were using SVN but now we are switching to Git with VSTS(azure devops).
We mostly develop B project while we develop A project, in the same solution.
Is there any way to set these repos seperately and commit changes of both projects in same branch with out switching solutions?
What is the right strategy we should use to manage this situation?
We solve this using git submodules. A submodule is a separate git repository inside another git repository. You commit separately in both repositorys, and the parent repository "remembers" which commit of the submodule repository it currently points to.
You can find plenty of documentation about submodules, e.g. in the pro git book. There are some pitfalls, but if you once get the workflow, it's a good approach for your problem.
Git Subtrees might be an alternative.
As an alternative to the submodules approach, you might want to consider a monorepo approach; in other words, keeping both projects in the same git repository.
There is nothing in Git (or Visual Studio, for that matter) that requires you to use the repository's root folder as your working directory when working with the code in the repo, so your current developer workflow within each individual project could probably work just fine. You also get the benefit that working on B and A in the same solution will feel very natural.
Depending on your team structure, etc, there are of course drawbacks as well (for example, without good discipline it can be cumbersome to be very many people working in the same repository), so don't see this as a "silver bullet" - see it as one of many possible solutions to your problem; evaluate them and pick one based on what seems like it would work for you (and switch again if it didn't work out).
We have two projects underway and want to share some classes between them. The shared source must be in a single location so when a programmer on Project1 updates the code those changes are immediately seen in Project2.
The important part is that we do not want to maintain multiple copies of the same code. i think we would agree that its simply bad practise to do so.
The only option appears to be putting the code in a class library and load it as a plugin into each project. But I don't believe this works when referencing Unity types like GameObject or transform.
In C/C++ land we could put the source in a directory and include it into any solution we wanted - doesn't seem to be so easy in Unity-land. Is their a better way to share code between unity projects?
EDIT: All projects, including the shared code, are already under source control. This is not a Source Control question, its a framework issue. (And obviously I need to write better questions!)
Lets say the directory structure looks like this...
C:\
Project1\
Assets\
CodeForProject1\
StandardAssets\
Library\
C:\
Project2\
Assets\
CodeForProject2\
Resources\
Library\
D:\
UsefulCode\
PlayerClass\
WeaponsClass\
DataAccessClass\
Can Unity reference code from other projects? Can Unity reference code outside of its own Assets folder? If so, how?
I understand exactly what you're facing, we faced the same problem here some time ago.
The idea of our shared code is to be sort of a middleware, so it is natural that it will evolve through. Our solution was to create a git module for the shared code. I know you said that it's not a source control question, but at least here in my company, create a dll was not a good solution since we are changing the shared code constantly (we tried soft-links too, but it was very painful to maintain in all machines).
Here we created two projects: one for the middleware and another just for the tests. The last one have only the gitmodule to the middleware and a bunch of unit tests. We did it to ensure that there is no dependency to other projects. Both are in the source control. So when someone wants to implement a new feature inside the middleware, he/she make it inside the tests project, and when it's done commits to both projects.
Oh! And you can make a dll with Unity types and use them normally.
Firstly, I'm new to VSTS and Git, so apologies if my terminology gets muddled!
PROBLEM
My situation is that I have a VS/C# Project (called "PluginBase") that is, essentially, "starting template" code for a plugin. Historically, I've would just copy that PluginBase project code every time I wanted to create a new "tailored/derived" build for a particular customer.
What I would like to be able to do is, as and when bug fixes are resolved and features are added to the PluginBase project, I'd like the option to migrate these changes to one or more of the "tailored/derived" builds. Likewise, if the bug was first found while developing a "tailored/derived" build, I'd like to migrate that back to the PluginBase plugin.
IDEAS
From my research, I've come across a few "possible" ways of achieving my goal, but I'm not sure which (if any) of these approaches are suitable.
Branches
Seems the common approach, perhaps the "best", but...
Means all code must be in the same repository? (otherwise can't "cherry pick" across) - which I'd prefer to avoid as this may not always be possible
Git Submodules
Seems more intended when projects are sharing a common "library" (not deriving from same code-base)
Also not sure Visual Studio fully supports this feature
Cherry Pick
Doesn't seem possible to do this from one repository to another?
Git Patch
Doesn't seem Visual Studio supports this feature yet?
So, if anyone has any advice, guidance or new suggestions for approaches I could (or should) be using, I'd really appreciate your input.
Many thanks! :)
Git Branches are definitely the way to go. The code indeed has to be in the same repository, git stores change sets and in order for a change set to be applied git has to know what happened since the code-paths split or it can not replace the correct lines of code.
Make a branch for each time you roll out a version to a customer, you can then cherry-pick across the different branches.
We are working on an enterprise level .net project, where-in we have a huge code base. We have our own different small frameworks implemented in the project.
While working, many a times it happens that I want to see a particular module's (or it's framework's) class hierarchy at a glance, which seems difficult. I have to drill down in different class files to see the relationships. Which is little difficult to do and takes time.
One way is that, I can create a dummy class.diagram file and drag drop particular class files to check the relationships. But it doesn't work that well.
Is there some other practice being used which I am not aware of ?
One thing I know of is Visual Studio 2013 Ultimate edition has Architecture tab (I know 2010 and 2012 also have it, but never used in them), that can be used to generate dependency graph of all projects in a particular solution. That can be used to generate dependencies within the projects.
I have seen it shows dependencies to the class levels.
You can take help of this Channel9 link to know more about it.
I've used .NET Reflector (with various plugins) in the same context.
There's a huge amount of plugins available at https://reflectoraddins.codeplex.com/ that ease the task even further.
On the "free" side, you'll probably want to give the following combo a try:
ILSpy (http://ilspy.net/) + AssemblyVisualizer (http://denismarkelov.github.io/AssemblyVisualizer/)
Note: all of the above is used to view the assembly's hierachy, not from a source point of view.