On May 5, 2020 6:21 PM, Roman Gelfand Wrote: > Subject: GIT Branch Maintenance > I am in a process of designing a git strategy for our vs solution. > The vs solution is a legacy asp .net webforms app which is enormous. > CI is out of the question because of cumbersome db source setup. So, we > are pretty much relying on integration testing. We have roughly 6 people on > development team. Each of developers are assigned separate feature. > Sometimes, a feature spans several releases. > > Here are the branches: > Master - source that made it to prod > Feature - checked out from master Head. The Head represents previous > release. > QA - synchronized with master at the beginning of release development. > Upon completion, each active Feature branch is merged into QA. > Bugfix - in case of bug in current development, QA branch is checked out to > bugfix branch. Upon completion, it is merged back into QA branch. > > Over time these master and qa branches will be enormous. How do I keep it > concise preserving detailed history in case I need to hunt down a specific > commit? Answering a question with questions: 1. Have you looked up the GitFlow process, or perhaps in your case the GitLabFlow? The rest of the answer depends on this. 2. What enterprise git server are you using? GitHub, GitLab, BitBucket? You should consider one of those (no affiliation with any). My company uses all three brands of enterprise servers. Don't ask why - it's a very long discussion. 3. This is not a question: Look up merge --squash. You should consider using squashed merges going into master. If sequencing your features to multiple releases independently is important, then using a Pull Request (Merge Request in GitLab) is going to be important to you to pull in a change branch into a release. However, I would consider distinct release branches and feature branches (or topic branches). They are sequenced independently, from what you wrote, and I don't think Feature means exactly what you intend. It is more like the development HEAD where developers get their starting point - this may be your default branch, whatever you call it. Each feature would have its own branch rather than "Feature". So it BitBucket's GitFlow implementation, a branch would be like "feature/1234-topic-being-worked-on". You may not need your QA branch. Your definition of master may require some thought. It may actually represent the current prod release in general use (assuming multiple prod environments) rather than one "prod", somewhat like definitive prod, which is approximately what we use for the latest main release rather than just what made it to prod. Regards, Randall
