I'm actually very interested in your problem because I would like to know if Git and this or that workflow are genuinely not up to scratch for your needs.
In other words I'm interested to see what it is about your situation that differs from some more pedestrian one. You say "merging Word onto Xbox" and I'm wondering what this entails. I would perceive this (at first pass anyway) as best represented as distinct product branches in some repo. Ordinarily the model is "we have a production branch for our code" and all other branches are temporary and represent the work on some change or other, destined to become part of the production branch, the temp branch then being deleted. In your situation it seems - to me - that this calls for several "production" branches (which as you know are ordinarily named "master"). So having multiple masters might be a way to represent this: master_xbox master_android master_os360 then some generic change to Word would appear on some branch: word_fix_2045 (e.g. some bug fix to grammar processor) Delivering this (to production) would entail a pull-request from word_fix_2045 to master_xbox, word_fix_2045 to master_android etc etc. I think the important thing for me would be being clear about code that's platform agnostic and code that isn't - platform agnostic code (by definition) can be freely merged into master_xbox, master_android etc whereas platform specific code would need to be merged to this or that platform branch. You do seem to be saying - effectively - that you have distinct products (word xbox, word android) and perhaps representing this explicitly in the repo may help... On Tuesday, February 7, 2017 at 1:33:41 AM UTC-7, Philip Oakley wrote: > > Hi Hugh, > > It's all good if the projects (plural) already know where the features are > destined for. However, in many scenarios, that is just not the case. > > Consider merging Word onto Xbox and Android, and OS360 (a bit old that). > In my work envirnment we make bespoke hardware, so every unit gets bespoke > software each with bespoke features, and some features that worked on one > system then want porting to a new system (maybe 3-4 years later!). This > creates lots of misalignments and incompatibilities. > > At this point it all gets messy, with often only the top level concept > being properly carried over (like taking a computer science concept/lecture > from one machine to another) so in may way's it is just 're-implemented'. > Plus the hardware incompatibilities and non availability don't help (same > long timescales). > > Git is probably the best that is available because it provides control to > the user to have small incremental commits with auto > validation/verification via the object ID (sha1), without recourse to all > the old style VCS hassle. But it (any vcs) still doesn't have a nice way of > incrementally merging and recording the progress (see the Mikado method > regarding note taking etc.) > > I did see that on the SO answer you do provide individual forks which I > think is the right approach (rather that each user having special branches > on the master). > > Have you had a case of having to incoprporate incompatible code that you > could share? > Philip > > ----- Original Message ----- > > *Subject:* Re: [git-users] Git branching and merge strategy for merge > with lots of conflicts requiring multiple people > > I suspect that you are perceiving "merging" as a late, final step in the > process. This is where you are erring I think. Merging should be done > frequently, this was conflicts will not accumulate over time and grow in > scale. > > Generally "merging" means incorporating changes made outside of some > branch while work has been progressing on that branch, from the way you > word things it seems like you mean something a bit different? > > As soon as you create some branch (from some other, e.g. create project_x > from master) the project_x branch never gets/see ongoing updates made to > master. The project_x branch grows as people work and change code on that > branch but other changes being made to master are never seen. > > Over time project_x contains numerous changes. fixes etc that were not > there when the branch was created but it has also fallen behind other > ongoing updates made to master. > > However - eventually - project_x is destined to "go into" master (if > master equates to production say) so will need to be merged. > > If you do this merge late, say many months after numerous developers have > made hundreds of commits to both branches, then yes you'll get a > potentially large list of conflicts (lets say 300). > > But if you merge master INTO project_x every few days you'll be forcing > the developers to resolve fewer conflicts more often and the changes behind > the conflicts will be much fresher in their minds. > > If you do this, then after a long project your project_x branch is more or > less right up to date and has all of the project work PLUS all of the other > unrelated changes that have been getting made to master. > > The last merge from master into project_x will get done, conflicts > resolved etc and then creating a PR from project_x TO master will have zero > conflicts. > > > > On Thursday, January 26, 2017 at 2:37:47 PM UTC-7, Stephen Morton wrote: >> >> On Thursday, 26 January 2017 16:12:43 UTC-5, Philip Oakley wrote: >>> >>> ----- Original Message ----- >>> >>> I'm looking for a git branching and merge strategy for merge with lots >>> of conflicts requiring multiple people. I can make it work, and I >>> understand git, but it all seems kind of awkward and it feels like there >>> must be a better way. >>> >>> I've got a big git merge to do. There are lots of conflicts and it >>> requires many people to resolve them all. >>> >>> The only way to handle this in git, AFAIK, is to start the merge and >>> then just commit all files with conflicts in them and then let different >>> people work on the different conflicts, committing them as they go. That is >>> great for resolving the conflicts. In the diagram below, branchA is merged >>> into branchB with merge commit M. The code in the repo at M is full of >>> conflicts. Many of the conflicts in the merge are actually resolved in >>> commits x, y, z. >>> >>> o---o---o---o---- branchA >>> \ \ >>> \-o---o-M---x---y---z branchB >>> >>> >>> But I worry that the above strategy is not good for git's merge tracking >>> and future merges. Because if we do a 'git checkout branchA; git merge >>> branchB`, git will erroneously try to merge x,y,z into branchA. >>> >>> I *could *create branchB2 where I re-do the original merge but then >>> just `git checkout z -- . ` and commit that as the merge commit. That >>> would work well for the git merge tracking. Then I would keep branchB just >>> as historical reference for "who fixed what conflict and why" during the >>> merge. >>> >>> >>> The above would all work, but it seems so un-git-like. It feels like >>> there must be a much better and established practice, yet I have not found >>> anything online. Is there a better way to do this? >>> >>> Thanks, >>> Steve >>> >>> p.s. I'm aware of answers like "Your workflow is broken, with git you >>> merge often and therefore never have lots of conflicts." It's just too long >>> a discussion to argue that point, so let's just avoid it, ok. >>> >>> >>> OK, so what is your workflow, and work products, in a little more detail >>> - how is it made to 'work' at the moment? >>> >>> Is the project well modularised with no file >100 lines (excepting, >>> maybe, well developed libraries that never change), or are they mega-beast >>> files with a mix of long and short functions/objects/procedures ? >>> >>> How are the review / merges done? do you have a small core team that >>> hangs together that can work on each issue, or is it multiple functions >>> having a review by committee that then depatches instructions to a poor >>> coder to try and implement before the cycle continues.. >>> >>> Do you have any intermediate work products (in the current >>> process) where some parts are fully merged, and then you can move on to the >>> other parts; or it's all partly merged as an intermediate work product for >>> another round? >>> >>> What is the smallest work element you could extract and get merged >>> (done, done style) from beneath the management's radar, as that you can do >>> (with proper commit message) in Git. >>> >>> Have you seen the Mikado method (aka pick up sticks) as applied to >>> correctling faulty software. https://vimeo.com/54450491 is a nice >>> presentation from Lean Agile Scotland >>> <https://vimeo.com/leanagilescotland> a few years ago. >>> >>> -- >>> Philip >>> [If I were you I wouldn't start from here, he said] >>> >> >> Thanks for your reply Philip. >> >> I'm really not looking for "SW development workflow" advice. I'm looking >> for the best way to handle in git the situation I describe above. >> >> This is a huge corporate product. (If you're asking about files with 100 >> lines of code, you cannot begin to believe how far off you are.) Imagine, >> if you will, that the XBOX is based on Windows XP, and now it wants to >> merge all of its XBOX-specific changes (which permeate much of its version >> of the Windows XP code) with Windows 10. All the while, nothing is static: >> the XBOX coding continues, as do the Windows 10 patches. Once this is done, >> in several months, the XBOX code will remain based on Windows 10 for >> several years. In a few years, this will all be one again when the XBOX >> merges with Windows 2020. (This product is neither a gaming nor a Microsoft >> product, but the analogy is pretty good.) >> >> Steve >> >> >> -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
