{"thread":{"id":"16869","subject":"Managing several threads of the same project in GIT","startedAt":"2008-12-26T11:20:57Z","lastAt":"2008-12-26T12:35:32Z","messageCount":3,"participants":["pggrd","Santi Béjar","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"98722","messageId":"loom.20081226T110416-269@post.gmane.org","threadId":"16869","inReplyTo":null,"subject":"Managing several threads of the same project in GIT","fromName":"pggrd","fromEmail":"git@paggard.com","sentAt":"2008-12-26T11:20:57Z","receivedAt":"2008-12-26T11:20:57Z","isPatch":false,"sender":{"key":"git@paggard.com","avatar":null},"body":"Hello,\n\nI've been studying GIT for some time already, but still have not figured out if\nit can be used for the scenario like this:\n\nfor example:\n\nI have a project, which divides to threads aiming to different clients\nmost of the code in the project is shared between the threads\nin certain files there are different code parts to meet client requirements \nbut even those files share the rest of the code\n\nWhat I need to be able to do is:\n- to get code for any thread I like at any time\n- to be able to develop each thread separately\n- to be able to merge certain changes from one thread to another, at the same\ntime without loosing the changes specific to the thread, and keep track of merge\nhistory\n\nWith GIT strategy to treat content as a single unity - if you will try to merge\nbranches - everything will be merged thus overwriting the changes that need to\nstay. But in the example above, if I make a change in the shared code in one\nthread, I need to be able to populate this change to all the threads, but this\nchange only.\n\nso - is this possible in GIT and if yes - what kind of strategy should be used?\n\nthanks \n"},{"id":"98723","messageId":"adf1fd3d0812260350h6da65cf0p164b52407ce6767@mail.gmail.com","threadId":"16869","inReplyTo":"loom.20081226T110416-269@post.gmane.org","subject":"Re: Managing several threads of the same project in GIT","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2008-12-26T11:50:34Z","receivedAt":"2008-12-26T11:50:34Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"2008/12/26 pggrd <git@paggard.com>:\n> Hello,\n>\n> I've been studying GIT for some time already, but still have not figured out if\n> it can be used for the scenario like this:\n>\n> for example:\n>\n> I have a project, which divides to threads aiming to different clients\n\nI suppose what you call threads are branches in git.\n\n> most of the code in the project is shared between the threads\n> in certain files there are different code parts to meet client requirements\n> but even those files share the rest of the code\n>\n> What I need to be able to do is:\n> - to get code for any thread I like at any time\n> - to be able to develop each thread separately\n> - to be able to merge certain changes from one thread to another, at the same\n> time without loosing the changes specific to the thread, and keep track of merge\n> history\n>\n\nGit works best with convergent branches, so all branches should have\nmore or less the same code.\n\nWhat you can do is to have different configuration for each client (or\nMakefile variables), in the same way git supports different\narchitectures, different sha1 implementations, etc. All the code is\nthere and you just choose which one to use.\n\nSanti\n"},{"id":"98727","messageId":"slrngl9jsj.mos.sitaramc@sitaramc.homelinux.net","threadId":"16869","inReplyTo":"loom.20081226T110416-269@post.gmane.org","subject":"Re: Managing several threads of the same project in GIT","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2008-12-26T12:35:32Z","receivedAt":"2008-12-26T12:35:32Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2008-12-26, pggrd <git@paggard.com> wrote:\n\n> most of the code in the project is shared between the threads\n> in certain files there are different code parts to meet client requirements \n> but even those files share the rest of the code\n\nHow different are the chunks of code per client?  A few\nminor differences, or large chunks of code?\n\n> What I need to be able to do is:\n> - to get code for any thread I like at any time\n> - to be able to develop each thread separately\n> - to be able to merge certain changes from one thread to another, at the same\n> time without loosing the changes specific to the thread,\n> and keep track of merge history\n\n> With GIT strategy to treat content as a single unity - if\n> you will try to merge branches - everything will be merged\n> thus overwriting the changes that need to stay. But in the\n> example above, if I make a change in the shared code in\n> one thread, I need to be able to populate this change to\n> all the threads, but this change only.\n\nSeems largely the same as maintaining an older release and\nbackporting changes from the main trunk to it (or sometimes\nthe other direction), while keeping them distinct.  Which\nhappens all the time...\n\nHowever, a maint release eventually atrophies -- changes\nstop coming in, and eventually your last customer using it\nhas upgraded and the branch becomes unused.\n\nYou can't do that with your \"client branch\", so eventually\nthis will start diverging further and further from the\ntrunk.\n\nThe way to mitigate that is to have your main trunk contain\nonly the stuff that is common to *all* your clients, and let\neach client branch maintain differences from this.  So in\neffect, those \"topic branches\" are never getting merged back\nto the mainline.  When you make changes that should go to\nevery client, you make them on the master and merge them\ninto the \"topic branch\" (your client branch).  When you want\na commit from client A to be used for client B, you\ncherry-pick (cherry-pick from within gitk is pretty neat for\noccasional, manual, cherry picks).\n\nThe only caveat I see is that once in a while you'll want to\njust rebase each client branch against the master just for\nsanity.  This should be done on one repository, and be a\ncoordinated thing so that all the developers who're working\non that particular client branch can re-fetch.  You might\nend up doing this once in a few months so it's not bad I\nguess.\n\nSitaram\n\nPS: I think all this will work, but others with more\nexperience need to weigh in... it's always a bad idea to ask\nquestions during the holidays, you never know who's manning\nthe support lines ;-)\n\nPPS: As Santi said in the other reply, you should also\nconsider making these changes part of a single code base,\nwith some sort of configuration deciding what actually gets\ndone.  Would be cleaner in the long run I guess...\n"}]}