സന്ദർഭോചിതമായ പ്രതിബദ്ധതകൾ - എന്തുകൊണ്ട് Git ചരിത്രത്തിൽ ക്യാപ്‌ചർ ചെയ്യുന്നതിനുള്ള ഒരു തുറന്ന നിലവാരം

'എന്താണ്' എന്നതിനപ്പുറം: പരമ്പരാഗത കമ്മിറ്റുകളുടെ പ്രശ്നം

ഓരോ ഡെവലപ്പർക്കും ഈ ആചാരം പരിചിതമാണ്: `git add`, `git commit -m "fix: null pointer exception പരിഹരിക്കുക"`. ഞങ്ങൾ *എന്ത്* സൂക്ഷ്മമായി രേഖപ്പെടുത്തുന്നു. ഞങ്ങൾ ഒരു ബഗ് പരിഹരിച്ചു, ഒരു ഫീച്ചർ ചേർത്തു, അല്ലെങ്കിൽ ഒരു ഡിപൻഡൻസി അപ്ഡേറ്റ് ചെയ്തു. കൺവെൻഷണൽ കമ്മിറ്റുകൾ പോലെയുള്ള ടൂളുകൾ ഞങ്ങളുടെ പ്രതിബദ്ധത സന്ദേശങ്ങൾക്ക് മൂല്യവത്തായ ഘടന കൊണ്ടുവന്നു, ചേഞ്ച്ലോഗുകൾ സൃഷ്ടിക്കുന്നതിനും മാറ്റത്തിൻ്റെ സാങ്കേതിക കാൽപ്പാടുകൾ മനസ്സിലാക്കുന്നതിനും അവയെ മെഷീൻ റീഡബിൾ ആക്കി മാറ്റുന്നു. എന്നാൽ പസിലിൻ്റെ ഒരു നിർണായക ഭാഗം തുടർച്ചയായി കാണുന്നില്ല: *എന്തുകൊണ്ട്*. എന്തുകൊണ്ടാണ് ഈ നൾ പോയിൻ്റർ ഒഴിവാക്കൽ ആദ്യം അവതരിപ്പിച്ചത്? എന്തുകൊണ്ടാണ് ഞങ്ങൾ ഈ നിർദ്ദിഷ്ട മൊഡ്യൂൾ ഇപ്പോൾ റീഫാക്റ്റർ ചെയ്യാൻ തിരഞ്ഞെടുത്തത്? എന്തുകൊണ്ടാണ് API എൻഡ് പോയിൻ്റ് മാറ്റിയത്? കമ്മിറ്റ് സന്ദേശം നമ്മോട് പ്രവർത്തനത്തെ പറയുന്നു, പക്ഷേ സന്ദർഭം-യുക്തി, ബിസിനസ്സ് ആവശ്യം, വിശാലമായ ഒരു സംരംഭത്തിലേക്കുള്ള ലിങ്ക് - പലപ്പോഴും സ്ലാക്ക് ത്രെഡുകളിലോ ജിറ ടിക്കറ്റുകളിലോ മങ്ങിപ്പോകുന്ന മെമ്മറിയിലോ നഷ്ടപ്പെടും.

സാന്ദർഭിക കമ്മിറ്റുകൾ അവതരിപ്പിക്കുന്നു: 'എന്തുകൊണ്ട്' എന്നതിനായുള്ള ഒരു ഓപ്പൺ സ്റ്റാൻഡേർഡ്

സാന്ദർഭിക കമ്മിറ്റുകൾ ഈ പ്രശ്നം പരിഹരിക്കാൻ ഒരു തുറന്ന നിലവാരം നിർദ്ദേശിക്കുന്നു. നിലവിലുള്ള കൺവെൻഷനുകളുടെ ഒരു വിപുലീകരണമാണ് അവ, പരമ്പരാഗത കമ്മിറ്റുകൾ പോലെ, Git ചരിത്രത്തിൽ തന്നെ ഒരു മാറ്റത്തിൻ്റെ സന്ദർഭം തടസ്സമില്ലാതെ ഉൾപ്പെടുത്താൻ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു. പ്രധാന ആശയം ലളിതവും എന്നാൽ ശക്തവുമാണ്: മാറ്റത്തിൻ്റെ യുക്തിസഹമായ സത്യത്തിൻ്റെ ഉറവിടത്തിലേക്ക് വിരൽ ചൂണ്ടുന്ന നിങ്ങളുടെ പ്രതിബദ്ധത സന്ദേശത്തിലേക്ക് ഒരു ഘടനാപരമായ `സന്ദർഭം` അടിക്കുറിപ്പ് ചേർക്കുക. ഇത് പ്രോജക്ട് മാനേജ്മെൻ്റ് ടൂളുകൾ മാറ്റിസ്ഥാപിക്കുന്നതിനെക്കുറിച്ചല്ല; ഇത് നിങ്ങളുടെ കോഡിനും അതിനെ രൂപപ്പെടുത്തിയ ചർച്ചകൾക്കും ഇടയിൽ സ്ഥിരവും കണ്ടെത്താവുന്നതുമായ ഒരു പാലം സൃഷ്ടിക്കുന്നതിനെക്കുറിച്ചാണ്.

വ്യത്യസ്‌ത ബിസിനസ് മൊഡ്യൂളുകളും ടീമുകളും മാറ്റങ്ങളുടെ വ്യക്തവും ഓഡിറ്റ് ചെയ്യാവുന്നതുമായ പാത നിലനിർത്തേണ്ട Mewayz പോലുള്ള പ്ലാറ്റ്‌ഫോമുകൾക്ക്, ഈ ലെവൽ ട്രെയ്‌സിബിലിറ്റി വിലമതിക്കാനാവാത്തതാണ്. കോഡ് മാറ്റങ്ങളുടെ കേവലമായ ഒരു റെക്കോർഡിൽ നിന്ന് ഇത് Git-നെ തീരുമാനമെടുക്കുന്നതിനുള്ള സമ്പന്നമായ ചരിത്രരേഖയാക്കി മാറ്റുന്നു.

• സ്റ്റാൻഡേർഡ് ഘടന: ഒരു സന്ദർഭോചിതമായ കമ്മിറ്റ് ഒരു അടിക്കുറിപ്പ് ഉപയോഗിക്കുന്നു, ഉദാഹരണത്തിന്, `സന്ദർഭം: <ഐഡൻ്റിഫയർ>`, ഇവിടെ `` എന്നത് `ഇഷ്യൂ`, `rfc` (അഭിപ്രായത്തിനുള്ള അഭ്യർത്ഥന), `ചർച്ച`, `സംഭവം`, മുതലായവ ആകാം. > കൂടാതെ ഐഡിയിൽ നിന്നുള്ള ഒരു ടിക്കറ്റ്, `<ഐഡൻ്റിഫയർ.` എന്നതിൽ നിന്ന് ഒരു അദ്വിതീയമായ ഒരു ടിക്കറ്റ്. നമ്പർ, ഒരു ഫോറം പോസ്റ്റ് ഐഡി).
• മെഷീൻ-വായിക്കാൻ കഴിയുന്നത്: ഘടനാപരമായ ഫോർമാറ്റ് സന്ദർഭം പാഴ്‌സ് ചെയ്യാനും സ്വയമേവ ഹൈപ്പർലിങ്കുകൾ സൃഷ്‌ടിക്കാനോ അനുബന്ധ വിവരങ്ങൾ നേടാനോ ഉപകരണങ്ങളെ അനുവദിക്കുന്നു, ഇത് ഡെവലപ്പർ അനുഭവം നേരിട്ട് Git ലോഗിൽ സമ്പന്നമാക്കുന്നു.
• ടൂൾ-അജ്ഞ്ഞേയവാദി: ജിറ, ലീനിയർ, ഗിറ്റ്ഹബ് ഇഷ്യൂസ്, സ്ലാക്ക്, ഒരു മെവയ്‌സ് മൊഡ്യൂൾ അല്ലെങ്കിൽ ഒരു ഇൻ്റേണൽ വിക്കി എന്നിവയ്‌ക്കൊപ്പം പ്രവർത്തിക്കാൻ സ്റ്റാൻഡേർഡ് രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു. റഫറൻസ് ചെയ്യുന്ന സിസ്റ്റത്തെ `തരം` നിർവ്വചിക്കുന്നു.
• ചരിത്രം സംരക്ഷിക്കുന്നു: തകരാൻ സാധ്യതയുള്ള ബാഹ്യ ലിങ്കുകളിൽ നിന്ന് വ്യത്യസ്തമായി, ഈ സന്ദർഭം റിപ്പോസിറ്ററിയുടെ മാറ്റമില്ലാത്ത ചരിത്രത്തിലേക്ക് ചുട്ടുപഴുപ്പിക്കപ്പെടുന്നു, "എന്തുകൊണ്ട്" എന്നത് കോഡ്ബേസിൻ്റെ ജീവിതകാലം മുഴുവൻ ആക്സസ് ചെയ്യാവുന്നതായിരിക്കും.

വികസന ടീമുകൾക്കുള്ള മൂർത്തമായ നേട്ടങ്ങൾ

സാന്ദർഭിക കമ്മിറ്റുകൾ സ്വീകരിക്കുന്നത് ഉടനടി ദീർഘകാല നേട്ടങ്ങൾ നൽകുന്നു. ഒരു പ്രോജക്റ്റിലേക്ക് കയറുന്ന പുതിയ ടീം അംഗങ്ങൾക്ക്, Git ലോഗ് വായിക്കുന്നത് ഒരു വിദ്യാഭ്യാസ യാത്രയായി മാറുന്നു. "refactor(auth): ടോക്കൺ മൂല്യനിർണ്ണയം ലളിതമാക്കുക" എന്ന് കാണുന്നതിന് പകരം, അവർ `സന്ദർഭം: rfc #45` ഉപയോഗിച്ച് ഒരു പ്രതിബദ്ധത കാണുന്നു, അത് വിവിധ സമീപനങ്ങളെ ചർച്ച ചെയ്യുന്ന ഡിസൈൻ ഡോക്യുമെൻ്റിലേക്ക് നേരിട്ട് ലിങ്ക് ചെയ്യുന്നു. ഇത് പ്രോജക്റ്റിൻ്റെ വാസ്തുവിദ്യയെയും തീരുമാനമെടുക്കൽ പ്രക്രിയകളെയും കുറിച്ചുള്ള അവരുടെ ധാരണയെ നാടകീയമായി ത്വരിതപ്പെടുത്തുന്നു.

ബഗ് പരിഹരിക്കുമ്പോഴോ സംഭവം പോസ്റ്റ്‌മോർട്ടം ചെയ്യുമ്പോഴോ, ഡെവലപ്പർമാർക്ക് ഒരു കോഡ് വ്യത്യാസത്തിൽ മാത്രമല്ല, യഥാർത്ഥ ബഗ് റിപ്പോർട്ടിലേക്കോ സംഭവ ലോഗിലേക്കോ (`സന്ദർഭം: സംഭവം #2024-001`) പ്രശ്നകരമായ മാറ്റം കണ്ടെത്താനാകും. പരിഹാരം മൂലകാരണത്തെ അഭിസംബോധന ചെയ്തതാണോ അതോ കേവലം ഒരു പാച്ച് മാത്രമാണോ എന്നതിനെക്കുറിച്ചുള്ള നിർണായക ഉൾക്കാഴ്ച ഇത് നൽകുന്നു. Mewayz പോലെയുള്ള ഒരു മോഡുലാർ സിസ്റ്റം ഉപയോഗിക്കുന്ന ടീമുകൾക്ക്, ഒരു ബിസിനസ് മൊഡ്യൂളിലെ മാറ്റം മറ്റൊന്നിലെ ഫീച്ചർ അഭ്യർത്ഥനയുമായി എങ്ങനെ ബന്ധപ്പെട്ടിരിക്കുന്നു എന്ന് മനസ്സിലാക്കുന്നത് നിസ്സാരമാണ്, കാരണം കോൺടെക്സ്റ്റ് ഫൂട്ടർ മുഴുവൻ ബിസിനസ്സ് OS-ലും വ്യക്തമായ ഡിപൻഡൻസി ഗ്രാഫ് സൃഷ്ടിക്കുന്നു.

"ഞങ്ങൾ ആറ് മാസം മുമ്പ് സന്ദർഭോചിതമായ കമ്മിറ്റുകൾ ഉപയോഗിക്കാൻ തുടങ്ങി, ഞങ്ങളുടെ കോഡ്ബേസുമായി ഞങ്ങൾ ഇടപഴകുന്ന രീതി ഇത് അടിസ്ഥാനപരമായി മാറ്റിമറിച്ചു. Git ലോഗ് ഇനി മാറ്റങ്ങളുടെ ഒരു തണുത്ത പട്ടികയല്ല; ഇതൊരു വിവരണമാണ്. ഇത് ഞങ്ങളുടെ കോഡിനെ ഞങ്ങളുടെ സംഭാഷണങ്ങളുമായി ബന്ധിപ്പിക്കുന്നു, ഓരോ വരിയുടെയും പിന്നിലെ ഉദ്ദേശ്യം ടീമിലെ എല്ലാവർക്കും വ്യക്തമാക്കുന്നു." - ഫിൻടെക് സ്റ്റാർട്ടപ്പിലെ സീനിയർ എഞ്ചിനീയർ.

സാന്ദർഭിക പ്രതിബദ്ധതകൾ ഉപയോഗിച്ച് ആരംഭിക്കുക

നിങ്ങളുടെ വർക്ക്ഫ്ലോയിലേക്ക് സന്ദർഭോചിതമായ പ്രതിബദ്ധതകൾ സമന്വയിപ്പിക്കുന്നത് നേരായ കാര്യമാണ്. കൺവെൻഷനിലെ ടീം കരാറോടെയാണ് ഇത് ആരംഭിക്കുന്നത്. നിങ്ങളുടെ ടൂളുകൾക്ക് പ്രസക്തമായ ഒരു കൂട്ടം സന്ദർഭ തരങ്ങൾ നിങ്ങൾക്ക് നിർവ്വചിക്കാം (ഉദാ. `ഇഷ്യൂ`, `സ്ലാക്ക്`, `മീവേയ്സ്-മൊഡ്യൂൾ`). `സന്ദർഭം:` അടിക്കുറിപ്പ് ഉൾപ്പെടുത്താൻ ഡെവലപ്പർമാരെ ഓർമ്മിപ്പിക്കുന്നതിന് നിങ്ങളുടെ പ്രതിബദ്ധത സന്ദേശ ടെംപ്ലേറ്റ് അപ്‌ഡേറ്റ് ചെയ്യുക എന്നതാണ് അടുത്ത ഘട്ടം. സ്ഥിരത ഉറപ്പാക്കാൻ പല ടീമുകളും ജിറ്റ് ഹുക്കുകൾ അല്ലെങ്കിൽ CI പരിശോധനകൾ വഴി ഇത് നടപ്പിലാക്കുന്നു. ലക്ഷ്യം പൂർണതയല്ല, പുരോഗതിയാണ് - കാര്യമായ മാറ്റങ്ങൾക്ക് വേണ്ടിയാണെങ്കിലും, "എന്തുകൊണ്ട്" ഘടനാപരമായ രീതിയിൽ ക്യാപ്‌ചർ ചെയ്യാൻ തുടങ്ങുന്നു. കാലക്രമേണ, ഈ സമ്പ്രദായം നിങ്ങളുടെ പതിപ്പ് നിയന്ത്രണ സംവിധാനത്തിൽ നേരിട്ട് ശക്തമായതും തിരയാൻ കഴിയുന്നതുമായ ഒരു വിജ്ഞാന അടിത്തറ നിർമ്മിക്കുന്നു, നിങ്ങളുടെ Git ചരിത്രത്തെ നിങ്ങളുടെ പ്രോജക്റ്റിൻ്റെ പരിണാമത്തിൻ്റെ സമഗ്രമായ കഥയാക്കി മാറ്റുന്നു.

പതിവ് ചോദിക്കുന്ന ചോദ്യങ്ങൾ

'എന്താണ്' എന്നതിനപ്പുറം: പരമ്പരാഗത കമ്മിറ്റുകളുടെ പ്രശ്നം

ഓരോ ഡെവലപ്പർക്കും ഈ ആചാരം പരിചിതമാണ്: `git add`, `git commit -m "fix: null pointer exception പരിഹരിക്കുക"`. ഞങ്ങൾ *എന്ത്* സൂക്ഷ്മമായി രേഖപ്പെടുത്തുന്നു. ഞങ്ങൾ ഒരു ബഗ് പരിഹരിച്ചു, ഒരു ഫീച്ചർ ചേർത്തു, അല്ലെങ്കിൽ ഒരു ഡിപൻഡൻസി അപ്ഡേറ്റ് ചെയ്തു. കൺവെൻഷണൽ കമ്മിറ്റുകൾ പോലെയുള്ള ടൂളുകൾ ഞങ്ങളുടെ പ്രതിബദ്ധത സന്ദേശങ്ങൾക്ക് മൂല്യവത്തായ ഘടന കൊണ്ടുവന്നു, ചേഞ്ച്ലോഗുകൾ സൃഷ്ടിക്കുന്നതിനും മാറ്റത്തിൻ്റെ സാങ്കേതിക കാൽപ്പാടുകൾ മനസ്സിലാക്കുന്നതിനും അവയെ മെഷീൻ റീഡബിൾ ആക്കി മാറ്റുന്നു. എന്നാൽ പസിലിൻ്റെ ഒരു നിർണായക ഭാഗം തുടർച്ചയായി കാണുന്നില്ല: *എന്തുകൊണ്ട്*. എന്തുകൊണ്ടാണ് ഈ നൾ പോയിൻ്റർ ഒഴിവാക്കൽ ആദ്യം അവതരിപ്പിച്ചത്? എന്തുകൊണ്ടാണ് ഞങ്ങൾ ഈ നിർദ്ദിഷ്ട മൊഡ്യൂൾ ഇപ്പോൾ റീഫാക്റ്റർ ചെയ്യാൻ തിരഞ്ഞെടുത്തത്? എന്തുകൊണ്ടാണ് API എൻഡ് പോയിൻ്റ് മാറ്റിയത്? കമ്മിറ്റ് സന്ദേശം നമ്മോട് പ്രവർത്തനത്തെ പറയുന്നു, പക്ഷേ സന്ദർഭം-യുക്തി, ബിസിനസ്സ് ആവശ്യം, വിശാലമായ ഒരു സംരംഭത്തിലേക്കുള്ള ലിങ്ക് - പലപ്പോഴും സ്ലാക്ക് ത്രെഡുകളിലോ ജിറ ടിക്കറ്റുകളിലോ മങ്ങിപ്പോകുന്ന മെമ്മറിയിലോ നഷ്ടപ്പെടും.

സാന്ദർഭിക കമ്മിറ്റുകൾ അവതരിപ്പിക്കുന്നു: 'എന്തുകൊണ്ട്' എന്നതിനായുള്ള ഒരു ഓപ്പൺ സ്റ്റാൻഡേർഡ്

സാന്ദർഭിക കമ്മിറ്റുകൾ ഈ പ്രശ്നം പരിഹരിക്കാൻ ഒരു തുറന്ന നിലവാരം നിർദ്ദേശിക്കുന്നു. നിലവിലുള്ള കൺവെൻഷനുകളുടെ ഒരു വിപുലീകരണമാണ് അവ, പരമ്പരാഗത കമ്മിറ്റുകൾ പോലെ, Git ചരിത്രത്തിൽ തന്നെ ഒരു മാറ്റത്തിൻ്റെ സന്ദർഭം തടസ്സമില്ലാതെ ഉൾപ്പെടുത്താൻ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു. പ്രധാന ആശയം ലളിതവും എന്നാൽ ശക്തവുമാണ്: മാറ്റത്തിൻ്റെ യുക്തിസഹമായ സത്യത്തിൻ്റെ ഉറവിടത്തിലേക്ക് വിരൽ ചൂണ്ടുന്ന നിങ്ങളുടെ പ്രതിബദ്ധത സന്ദേശത്തിലേക്ക് ഒരു ഘടനാപരമായ `സന്ദർഭം` അടിക്കുറിപ്പ് ചേർക്കുക. ഇത് പ്രോജക്ട് മാനേജ്മെൻ്റ് ടൂളുകൾ മാറ്റിസ്ഥാപിക്കുന്നതിനെക്കുറിച്ചല്ല; ഇത് നിങ്ങളുടെ കോഡിനും അതിനെ രൂപപ്പെടുത്തിയ ചർച്ചകൾക്കും ഇടയിൽ സ്ഥിരവും കണ്ടെത്താവുന്നതുമായ ഒരു പാലം സൃഷ്ടിക്കുന്നതിനെക്കുറിച്ചാണ്.

വികസന ടീമുകൾക്കുള്ള മൂർത്തമായ നേട്ടങ്ങൾ

സാന്ദർഭിക കമ്മിറ്റുകൾ സ്വീകരിക്കുന്നത് ഉടനടി ദീർഘകാല നേട്ടങ്ങൾ നൽകുന്നു. ഒരു പ്രോജക്റ്റിലേക്ക് കയറുന്ന പുതിയ ടീം അംഗങ്ങൾക്ക്, Git ലോഗ് വായിക്കുന്നത് ഒരു വിദ്യാഭ്യാസ യാത്രയായി മാറുന്നു. "refactor(auth): ടോക്കൺ മൂല്യനിർണ്ണയം ലളിതമാക്കുക" എന്ന് കാണുന്നതിന് പകരം, അവർ `സന്ദർഭം: rfc #45` ഉപയോഗിച്ച് ഒരു പ്രതിബദ്ധത കാണുന്നു, അത് വിവിധ സമീപനങ്ങളെ ചർച്ച ചെയ്യുന്ന ഡിസൈൻ ഡോക്യുമെൻ്റിലേക്ക് നേരിട്ട് ലിങ്ക് ചെയ്യുന്നു. ഇത് പ്രോജക്റ്റിൻ്റെ വാസ്തുവിദ്യയെയും തീരുമാനമെടുക്കൽ പ്രക്രിയകളെയും കുറിച്ചുള്ള അവരുടെ ധാരണയെ നാടകീയമായി ത്വരിതപ്പെടുത്തുന്നു.

സാന്ദർഭിക പ്രതിബദ്ധതകൾ ഉപയോഗിച്ച് ആരംഭിക്കുക

നിങ്ങളുടെ വർക്ക്ഫ്ലോയിലേക്ക് സന്ദർഭോചിതമായ പ്രതിബദ്ധതകൾ സമന്വയിപ്പിക്കുന്നത് നേരായ കാര്യമാണ്. കൺവെൻഷനിലെ ടീം കരാറോടെയാണ് ഇത് ആരംഭിക്കുന്നത്. നിങ്ങളുടെ ടൂളുകൾക്ക് പ്രസക്തമായ ഒരു കൂട്ടം സന്ദർഭ തരങ്ങൾ നിങ്ങൾക്ക് നിർവ്വചിക്കാം (ഉദാ. `ഇഷ്യൂ`, `സ്ലാക്ക്`, `മീവേയ്സ്-മൊഡ്യൂൾ`). `സന്ദർഭം:` അടിക്കുറിപ്പ് ഉൾപ്പെടുത്താൻ ഡെവലപ്പർമാരെ ഓർമ്മിപ്പിക്കുന്നതിന് നിങ്ങളുടെ പ്രതിബദ്ധത സന്ദേശ ടെംപ്ലേറ്റ് അപ്‌ഡേറ്റ് ചെയ്യുക എന്നതാണ് അടുത്ത ഘട്ടം. സ്ഥിരത ഉറപ്പാക്കാൻ പല ടീമുകളും ജിറ്റ് ഹുക്കുകൾ അല്ലെങ്കിൽ CI പരിശോധനകൾ വഴി ഇത് നടപ്പിലാക്കുന്നു. ലക്ഷ്യം പൂർണതയല്ല, പുരോഗതിയാണ് - കാര്യമായ മാറ്റങ്ങൾക്ക് വേണ്ടിയാണെങ്കിലും, "എന്തുകൊണ്ട്" ഘടനാപരമായ രീതിയിൽ ക്യാപ്‌ചർ ചെയ്യാൻ തുടങ്ങുന്നു. കാലക്രമേണ, ഈ സമ്പ്രദായം നിങ്ങളുടെ പതിപ്പ് നിയന്ത്രണ സംവിധാനത്തിൽ നേരിട്ട് ശക്തമായതും തിരയാൻ കഴിയുന്നതുമായ ഒരു വിജ്ഞാന അടിത്തറ നിർമ്മിക്കുന്നു, നിങ്ങളുടെ Git ചരിത്രത്തെ നിങ്ങളുടെ പ്രോജക്റ്റിൻ്റെ പരിണാമത്തിൻ്റെ സമഗ്രമായ കഥയാക്കി മാറ്റുന്നു.