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).
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.
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.
I am looking at moving our .net(c#) projects from TFS to git. The general consensus in the tema that we do not want to continue with tfs has been reached and we wish to trial git. We currentley do not have that many projects to migrate over but we expect these to grow as our old systems are replaced.
Currently we have a tfs project for all things that we think will be needed by multiple projects, database stuff, 3rd party dll's etc. What is the best way to have a similar structure in git?
The best way I could see is to have a similar thing to our current structure, with a seperate repository for all the common files.
I have read about using submodules but there seems to be a lot of complaints about these. Is it worth trying something like repo or another alternative? Or is there a better way to handle this?
This question is going to be pretty subjective, but IMO I would solve this by having a separate repository for your common stuff.
Another option is to migrate your common stuff to Nuget packages so you can move your common stuff forward without worrying about breaking all your existing projects.
In my experience common projects in an Enterprise environment tend to calcify your ability to respond to change quickly. Instead you spend lot's of time worrying about how changes in your "Core" or "Lib" modules will affect the 80+ projects you have that are using them. Worse, people just start shoving everything into those modules even if it is only pertinent to a few projects simply because it's easy.
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
Where I work at, we have about 2 dozen or more projects, using SVN as version control. My boss is pretty strict about the repositories, but misguided I think. For example, we always have one "Current" branch for development, which gets merged into Trunk before a release. For all other purposes, "Current" is the trunk and we don't ever make more branches. Likewise, he's picky about file contents, most pointedly, all the References in the project files must adhere to a "flat" directory structure between projects (ie, all project folders in one directory.)
Now, I figure that one way I can make my life easier would be to use Bazaar locally so I can work on features in their own branches, make frequent commits locally (for change tracking), possibly reorganize my projects, and generally make my life a little easier.
Except I can't quite get the repository structure for Bazaar figured out! The standard would seem to be something like
Project-Repo (Shared Repo)
/Project-Trunk (Bound to SVN)
/Project-Feature1 (Branch of Trunk)
/Project-Feature2 (Branch of Trunk)
Some projects have up to a half-dozen or more references to other projects. And most features will require changes to at least 2 projects at any given time. I have no idea how to handle that. If I break the feature branches out into other folders, I lose the shared repository benefits. And if I leave them in place, then I'll have to reconfigure all the references each time I need to branch projects for a new feature.
The best I can think to do is just deal with the lack of shared repos and do something like this:
Branches
/Feature1
/ProjectA-Branch
/ProjectB-Branch
/Feature2
/ProjectB-Branch
/ProjectC-Branch
With the trunks all being stored as individual repos elsewhere just for the purpose of merging and final commits back up to SVN.
Is that the best layout I'll be able to get with Bazaar or are there techniques that I'm unaware of? Repository layout is a very challenging exercise considering how common it should be.
I think, given the constraints about them all having flat local names, this is probably the best setup.
You could make some of those directories actually not be whole branches, but just checkouts of the common branch, if you don't intend to modify them.