ഒരു Git ഇമേജ് മെർജ് കോൺഫ്ലിക്റ്റ് ഞങ്ങൾ എങ്ങനെ പരിഹരിച്ചു (കൂടാതെ എന്തുകൊണ്ട് GitHub വെബ്സൈറ്റിന് അതിന് കഴിഞ്ഞില്ല)

കോഡിലെ മെർജ് കോൺഫ്ലിക്റ്റുകൾ തന്നെ അലോസരപ്പെടുത്തുന്നതാണ്. അവ ഒരു ഇമേജ് ഫയലിൽ സംഭവിക്കുമ്പോൾ, മിക്കവരും പകച്ചുപോകുന്നു — ഒരു ചിത്രത്തിന് "ഡിഫ് വ്യൂ" (diff view) ഇല്ല, കൂടാതെ GitHub-ൽ ബ്രൗസറിൽ പരിഹരിക്കാനുള്ള സാധാരണ ബട്ടൺ അവിടെ ഉണ്ടാകില്ല. ഈ പോസ്റ്റ് അത്തരത്തിലുള്ള ഒരു യഥാർത്ഥ കേസ് വിശദീകരിക്കുന്നു: എന്താണ് പ്രവർത്തിക്കാത്തത്, എന്താണ് പ്രവർത്തിച്ചത്.

ഇന്ന്, ഓഗസ്റ്റ് 29, 2026 ലെ കണക്കനുസരിച്ച്, ഇത് മനസ്സിലാക്കേണ്ടത് അത്യാവശ്യമാണ്, കാരണം കൂടുതൽ ചെറിയ ടീമുകൾ ഒരു ഡെസ്ക്ടോപ്പ് ആപ്പ് വഴി ടെക്സ്റ്റ്, ഇമേജ് മാറ്റങ്ങൾ പുഷ് ചെയ്യുന്ന നോൺ-ടെക്നിക്കൽ ആളുകളെ ഉപയോഗിച്ച് Git വഴി ഉള്ളടക്കം കൂടുതലുള്ള വെബ്സൈറ്റുകൾ പ്രവർത്തിപ്പിക്കുന്നു. ആ സമ്മിശ്രണം — പ്ലെയിൻ-ലാംഗ്വേജ് കണ്ടന്റ് എഡിറ്റർമാർ, ബൈനറി ഫയലുകൾ, കൂടാതെ ഒരു യഥാർത്ഥ ഡെപ്ലോയ് പൈപ്പ്‌ലൈൻ — കൃത്യമായി ഈ പ്രശ്നം ഉയർന്നുവരുന്ന ഇടമാണ്.

സജ്ജീകരണം: രണ്ട് ബ്രാഞ്ചുകൾ, പങ്കിട്ട ഒരു ഇമേജ്

പ്രോജക്റ്റ് ലളിതമായ ഒരു രണ്ട്-ബ്രാഞ്ച് വർക്ക്ഫ്ലോ ഉപയോഗിക്കുന്നു. staging ഇവിടെയാണ് ദൈനംദിന ജോലികൾ നടക്കുന്നത് — ഒരു കണ്ടന്റ് എഡിറ്റർ അവിടെ സ്വതന്ത്രമായി മാറ്റങ്ങൾ പുഷ് ചെയ്യുന്നു, അത് സ്വയമേവ ഒരു പ്രിവ്യൂ സൈറ്റിലേക്ക് ഡെപ്ലോയ് ചെയ്യപ്പെടുന്നു. main ഇതാണ് യഥാർത്ഥ ലൈവ് സൈറ്റ്, ഇതിൽ നിന്ന് അവലോകനം ചെയ്ത ഒരു പുൾ റിക്വസ്റ്റ് (Pull Request) ഉള്ളപ്പോൾ മാത്രം അപ്ഡേറ്റ് ചെയ്യപ്പെടുന്നു staging ഇതിലേക്ക് മെർജ് ചെയ്യപ്പെടുന്നു.

ടീം അടുത്തിടെ സൈറ്റിലെ ചിത്രങ്ങൾ ഒരേ വിഷ്വൽ ക്വാളിറ്റിയിൽ PNG അല്ലെങ്കിൽ JPG-യെക്കാൾ വളരെ ചെറിയ ആധുനിക ഫോർമാറ്റായ WebP-ലേക്ക് മാറ്റിയിരുന്നു. ഓരോ ചിത്രവും ഇപ്പോൾ ഒരു ജോഡിയായി നിലവിലുണ്ട്: ഒറിജിനൽ .png, കൂടാതെ പൊരുത്തപ്പെടുന്ന ഒരു .webp, ഒരു HTML-മായി ബന്ധിപ്പിച്ചിരിക്കുന്നു <picture> എലമെന്റ് ഉപയോഗിച്ച് WebP-ശേഷിയുള്ള ബ്രൗസറുകൾക്ക് സ്വയമേവ ചെറിയ ഫയൽ ലഭിക്കുന്നു, മറ്റെല്ലാത്തിനും ഒറിജിനലിലേക്ക് ഫാൾബാക്ക് ചെയ്യുന്നു.

തുടർന്ന് രണ്ട് വ്യത്യസ്ത ബ്രാഞ്ചുകളിൽ ഏതാണ്ട് ഒരേ സമയത്ത് രണ്ട് കാര്യങ്ങൾ സംഭവിച്ചു: സാധാരണ റിവ്യൂ ഫ്ലോ ഒഴിവാക്കിക്കൊണ്ട് ഒരാൾ ഒരു പ്രൊഡക്റ്റ് സ്ക്രീൻഷോട്ടിൽ നേരിട്ട് ഒരു ചെറിയ എഡിറ്റ് ചെയ്തു main, അതേസമയം കണ്ടന്റ് എഡിറ്റർ വെവ്വേറെ ആ സ്ക്രീൻഷോട്ടിന്റെ യഥാർത്ഥ പുതിയ പതിപ്പ് അപ്‌ലോഡ് ചെയ്തു staging. രണ്ട് എഡിറ്റുകളും ഒരേ ഫയൽ പാത്തിനെ സ്പർശിച്ചു. ഇരുപക്ഷത്തിനും മറ്റൊന്നിനെക്കുറിച്ച് അറിയില്ലായിരുന്നു.

എന്തുകൊണ്ട് GitHub വെബ്സൈറ്റിന് ഇത് പരിഹരിക്കാൻ കഴിഞ്ഞില്ല

കൊണ്ടുവരാൻ കണ്ടന്റ് എഡിറ്റർ ഒരു പുൾ റിക്വസ്റ്റ് (Pull Request) തുറന്നപ്പോൾ staging അപ്ഡേറ്റ് ഇതിലേക്ക് main, GitHub ഉടനടി അത് ഫ്ലാഗ് ചെയ്തു: "ഈ ബ്രാഞ്ചിന് പരിഹരിക്കേണ്ട കോൺഫ്ലിക്റ്റുകളുണ്ട്." സാധാരണഗതിയിൽ, അതിലൂടെ ക്ലിക്ക് ചെയ്യുന്നത് ഒരു ടെക്സ്റ്റ് ഫയലിന്റെ രണ്ട് പതിപ്പുകളും വശങ്ങളിലായി കാണിക്കുന്ന ഒരു വെബ് അധിഷ്ഠിത എഡിറ്റർ നിങ്ങൾക്ക് നൽകുന്നു, അതിനാൽ ഏത് ലൈനുകളാണ് നിലനിർത്തേണ്ടതെന്ന് നിങ്ങൾക്ക് തിരഞ്ഞെടുക്കാം.

ആ എഡിറ്റർ ഇമേജുകൾക്ക് ലഭ്യമല്ല. GitHub-ന്റെ ബ്രൗസർ അധിഷ്ഠിത കോൺഫ്ലിക്റ്റ് റെസല്യൂഷൻ ലൈൻ അധിഷ്ഠിത ടെക്സ്റ്റ് — കോഡ്, മാർക്ക്ഡൗൺ, കോൺഫിഗ് ഫയലുകൾ മാത്രമേ മനസ്സിലാക്കുന്നുള്ളൂ. ഒരു PNG അല്ലെങ്കിൽ WebP ഫയലിന് താരതമ്യം ചെയ്യാൻ "ലൈനുകൾ" ഇല്ല. ആരെങ്കിലും എത്ര ശ്രദ്ധയോടെ ക്ലിക്ക് ചെയ്താലും, ഇത് പരിഹരിക്കാൻ കഴിയുന്ന ഒരു ബട്ടണോ കാഴ്‌ചയോ വെബ്‌സൈറ്റിലൂടെയുള്ള വഴിയോ അവിടെ ഉണ്ടായിരുന്നില്ല. വ്യക്തമായി പറയേണ്ടതാണ്: കണ്ടന്റ് എഡിറ്റർ തെറ്റൊന്നും ചെയ്തിരുന്നില്ല. ടൂളിന് ഈ പ്രത്യേക പ്രശ്നം പരിഹരിക്കാൻ ഒരു വഴിയുമില്ലായിരുന്നു.

മറഞ്ഞിരിക്കുന്ന രണ്ടാമത്തെ പ്രശ്നം

ഇത് പരിഹരിക്കുന്നതിന് ഫയലിന്റെ രണ്ട് പതിപ്പുകളും ലോക്കലായി പുൾ ചെയ്ത് നേരിട്ട് താരതമ്യം ചെയ്യേണ്ടതുണ്ട് — അവിടെയാണ് കൂടുതൽ സൂക്ഷ്മമായ ഒരു പ്രശ്നം ഉയർന്നുവന്നത്. പുതിയ സ്ക്രീൻഷോട്ട് ഇവിടെ staging മുമ്പത്തേതിനേക്കാൾ വലുതും ഉയർന്ന റെസല്യൂഷനുമുള്ള യഥാർത്ഥ അപ്ഡേറ്റായിരുന്നു അത്. എന്നാൽ അതിന്റെ ജോഡിയായ WebP ഫയൽ വളരെക്കാലമായി സ്പർശിക്കപ്പെട്ടിരുന്നില്ല — ഡൈമൻഷനുകൾ പോലും പൊരുത്തപ്പെടുന്നില്ല. പുതിയ PNG 1024 മുതൽ 1024 പിക്സൽ വരെയായിരുന്നു; അതിനടുത്തുള്ള WebP പൂർണ്ണമായും ചിത്രത്തിന്റെ പഴയ പതിപ്പിൽ നിന്ന് അവശേഷിക്കുന്ന 750 ബൈ 750 ആയി തുടർന്നു.

അതായത്, കോൺഫ്ലിക്റ്റിൽ ഒരു വശം തിരഞ്ഞെടുക്കുന്നത് — ഏത് പതിപ്പ് പൂർണ്ണമായി സൂക്ഷിച്ചാലും — പൊരുത്തപ്പെടാത്ത ഒരു ജോഡിയെ ഷിപ്പ് ചെയ്യുമായിരുന്നു. PNG പുതിയ സ്ക്രീൻഷോട്ട് കാണിക്കും, എന്നാൽ ബ്രൗസർ WebP തിരഞ്ഞെടുക്കുന്ന ഏത് സന്ദർശകനും (മിക്ക ആധുനിക ബ്രൗസറുകളും) നിശബ്ദമായി പഴയതും തെറ്റായതുമായ ഇമേജ് കാണും. കോൺഫ്ലിക്റ്റ് മെസ്സേജ് അപ്രത്യക്ഷമാകും; യഥാർത്ഥ ബഗ് ശ്രദ്ധിക്കപ്പെടാതെ ഷിപ്പ് ചെയ്യും.

ഘട്ടം 1: രണ്ട് പതിപ്പുകളും ശരിയായി താരതമ്യം ചെയ്യുക

ആദ്യ ഘട്ടം ഒന്നും പരിഹരിക്കുക എന്നതായിരുന്നില്ല — എന്താണ് യഥാർത്ഥത്തിൽ മാറിയതെന്നും എവിടെയാണെന്നും മനസ്സിലാക്കുന്നതിന്, രണ്ട് ബ്രാഞ്ചുകളിലുമുള്ള ഫയൽ സൈസുകളും ഡൈമൻഷനുകളും അവയുടെ പൊതുവായ ആരംഭ പോയിന്റുമായി താരതമ്യം ചെയ്യുകയായിരുന്നു അത്.

git fetch origin
git diff --stat origin/main origin/staging -- path/to/image.png path/to/image.webp

ഫയൽ അവസാനമായി പങ്കിട്ടതിനുശേഷം രണ്ട് ബ്രാഞ്ചുകളും സ്വതന്ത്രമായി പരിഷ്കരിച്ചതായി ഇത് കാണിച്ചു — വെറും "ഒരു വശം പുതിയതാണ്" എന്നതിലുപരി യഥാർത്ഥമായ ഒരു ത്രിമുഖ ഡൈവേർജൻസ് (divergence).

ഘട്ടം 2: ഏത് പതിപ്പാണ് യഥാർത്ഥത്തിൽ ശരിയെന്ന് തിരിച്ചറിയുക

രണ്ട് PNG-കളും വശങ്ങളിലായി തുറന്നത് ഇത് സ്ഥിരീകരിച്ചു staging പതിപ്പ് യഥാർത്ഥവും ഉദ്ദേശിച്ചതുമായ അപ്‌ഡേറ്റായിരുന്നു, തെറ്റോ കേടായ ഫയലോ അല്ല.

ഘട്ടം 3: ശരിയായ ഉറവിടത്തിൽ നിന്ന് WebP പുനരുജ്ജീവിപ്പിക്കുക

രണ്ട് വ്യത്യസ്‌ത ബൈനറി ഫയലുകൾ മെർജ് ചെയ്യാൻ ശ്രമിക്കുന്നതിന് പകരം — ഇത് അസാധ്യമാണ് — WebP-യെ ഒന്നായി കണക്കാക്കുക എന്നതായിരുന്നു പരിഹാരം ഇതിൽ നിന്ന് ഉരുത്തിരിഞ്ഞത് PNG അല്ലാതെ രഞ്ജിപ്പിലെത്താൻ ഒരു പ്രത്യേക ഫയലല്ല:

cwebp -q 82 image.png -o image.webp

ഇത് പുതിയ PNG-യുമായി ശരിയായി പൊരുത്തപ്പെടുന്ന, ശരിയായ 1024 ബൈ 1024 ഡൈമൻഷനുകളിൽ ഒരു പുതിയ WebP നിർമ്മിച്ചു. -q 82 ഒരു ക്വാളിറ്റി സെറ്റിംഗ് മാത്രമാണ് — ഫയൽ സൈസിനും ഷാർപ്പ്നെസിനും ഇടയിലുള്ള ഒരു നല്ല ബാലൻസ്.

ഘട്ടം 4: മെർജ് പൂർത്തിയാക്കി സ്ഥിരീകരിക്കുക

git checkout staging
git merge origin/main
git checkout --ours path/to/image.png          # keep the staging PNG
cp image-regenerated.webp path/to/image.webp   # use the freshly regenerated WebP
git add path/to/image.png path/to/image.webp
git commit
git push origin staging

ഇതിനുശേഷം, പുൾ റിക്വസ്റ്റ് (Pull Request) ക്ലീൻ ആയും മെർജ് ചെയ്യാവുന്നതായും കാണിച്ചു, കൂടാതെ ലൈവ് സൈറ്റ് ഓരോ സന്ദർശകനും വെബ്‌പി-ശേഷിയുണ്ടെങ്കിലും ഇല്ലെങ്കിലും പുതിയ സ്ക്രീൻഷോട്ട് ശരിയായി നൽകി.

പരിഗണിച്ചതും നിരസിച്ചതുമായ രീതികൾ

വഴിയിൽ കുറച്ച് വേഗതയേറിയ കുറുക്കുവഴികൾ ഉയർന്നുവന്നു, ഓരോന്നും അറിഞ്ഞിരിക്കേണ്ടതാണ്, എന്തുകൊണ്ട് അത് ഉപയോഗിച്ചില്ല എന്ന് അറിയുന്നതും പ്രധാനമാണ്.

ഒരു ഡെസ്ക്ടോപ്പ് Git ക്ലയന്റിൽ ഒരു പതിപ്പ് തിരഞ്ഞെടുക്കുന്നു. മിക്ക Git ഡെസ്ക്ടോപ്പ് ആപ്പുകളും "use my version" അല്ലെങ്കിൽ "use theirs" തിരഞ്ഞെടുത്ത് ഒരു ബൈനറി കോൺഫ്ലിക്റ്റ് പരിഹരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു — താരതമ്യമില്ല, മൊത്തത്തിലുള്ള തിരഞ്ഞെടുപ്പ് മാത്രം. നോൺ-ടെക്നിക്കൽ ആയ ഒരു ടീം അംഗത്തിന് ഇത് സ്വയം ചെയ്യാൻ കഴിയും. കുഴപ്പം: ഇത് പഴയതും പൊരുത്തപ്പെടാത്തതുമായ WebP ഫയൽ സൂക്ഷിക്കുമായിരുന്നു, മുകളിൽ വിവരിച്ച അതേ നിശബ്ദ ബഗ് ഷിപ്പ് ചെയ്യുന്നു. വേഗത്തിലുള്ളത്, എന്നാൽ തെറ്റ്.

ഒരു സ്ട്രാറ്റജി ഫ്ലാഗ് ഉപയോഗിച്ച് മെർജ് ചെയ്യാൻ നിർബന്ധിക്കുന്നു. കമാൻഡ് ലൈനിൽ നിന്ന്, git merge origin/main -X ours (അല്ലെങ്കിൽ -X theirs) ചോദിക്കാൻ നിർത്താതെ, ഓരോ ഫയലിനും ഒരു വശം പൂർണ്ണമായും തിരഞ്ഞെടുത്ത് ഏത് കോൺഫ്ലിക്റ്റും സ്വയമേവ പരിഹരിക്കാൻ Git-നോട് പറയുന്നു:

git merge origin/main -X ours

ഒരു ഡെസ്‌ക്‌ടോപ്പ് ആപ്പിൽ ഒരു പതിപ്പ് തിരഞ്ഞെടുക്കുന്നതിന് സമാനമായ ഒരു ന്യൂനതയാണ് ഇതിനുള്ളത് — Git ഒരു കോൺഫ്ലിക്റ്റ് ഉള്ള ബൈനറി ഫയലിനെ അവിഭാജ്യമായ ഒരു ബ്ലോക്കായി കണക്കാക്കുന്നു, അതിനാൽ പൊരുത്തപ്പെടാത്ത പകുതിയിൽ എത്തി അത് മാത്രം പരിഹരിക്കാൻ ഇതിന് കഴിയില്ല.

ബേസ് ബ്രാഞ്ചിൽ നിന്ന് ഫയൽ ആദ്യം ഡിലീറ്റ് ചെയ്യുന്നു. തിയറി: ലൈവ് ബ്രാഞ്ചിൽ ഫയൽ ഇല്ലെങ്കിൽ, കോൺഫ്ലിക്റ്റ് ഉണ്ടാകാൻ യാതൊന്നുമില്ല, അതിനാൽ മെർജ് ക്ലീൻ ആയി നടക്കണം. ഇത് വെറുതെ ഊഹിക്കുന്നതിന് പകരം ഒറ്റപ്പെട്ട ഒരു ബ്രാഞ്ചിൽ നേരിട്ട് പരീക്ഷിച്ചു:

git rm image.png image.webp
git commit -m "test: delete file"
git merge origin/staging

അതിന്റെ ഫലം ഒരു ക്ലീൻ മെർജ് ആയിരുന്നില്ല. ബ്രാഞ്ചുകൾ വേർപിരിയുന്ന സമയത്ത് ഫയൽ നിലവിലുണ്ടായിരുന്നതായി Git ഓർക്കുന്നു, അതിനാൽ അത് ഒരു വശത്ത് മാറ്റുമ്പോൾ മറുവശത്ത് അത് ഇല്ലാതാക്കുന്നത് ഇപ്പോഴും ഒരു കോൺഫ്ലിക്റ്റ് ഉണ്ടാക്കുന്നു — അതിന്റേതായ മുന്നറിയിപ്പ് മെസ്സേജ് ഉള്ള ഒരു "modify/delete" കോൺഫ്ലിക്റ്റ്. ഇത് പ്രശ്നം ഒഴിവാക്കുന്നതിന് പകരം അത് വീണ്ടും ലേബൽ ചെയ്യുന്നു.

കോൺഫ്ലിക്റ്റിന് മുകളിലൂടെ ഫോഴ്സ്-പുഷ് ചെയ്യുന്നു. ഒരു ഫോഴ്സ് പുഷ് (force push) വഴി ലൈവ് ബ്രാഞ്ച് പൂർണ്ണമായും മറ്റൊരു ബ്രാഞ്ചിന്റെ ഹിസ്റ്ററി ഉപയോഗിച്ച് തിരുത്തിയെഴുതുക എന്നതാണ് കൂടുതൽ കടുത്ത ഒരു ഓപ്ഷൻ. ഇത് യഥാർത്ഥത്തിൽ ഒരു കോൺഫ്ലിക്റ്റ് റെസല്യൂഷൻ അല്ല — ഇത് ഒരു വശത്തിന്റെ മാറ്റങ്ങൾ പൂർണ്ണമായും നിരസിക്കുകയാണ് ചെയ്യുന്നത്, ഇത് മറ്റൊരാളുടെ യഥാർത്ഥ വർക്ക് നിശബ്ദമായി നഷ്ടപ്പെടാൻ സാധ്യതയുണ്ട്. ഒരു ലൈവ് സൈറ്റിലേക്ക് ഡെപ്ലോയ് ചെയ്യുന്ന ഒരു ബ്രാഞ്ചിൽ, അത് തികച്ചും അപകടസാധ്യതയുള്ള ഒരു നീക്കമാണ്, അല്ലാതെ സ്വീകരിക്കേണ്ട ഒരു കുറുക്കുവഴിയല്ല.

ഉപസംഹാരം

ബൈനറി ഫയൽ കോൺഫ്ലിക്റ്റുകൾ — ഇമേജുകൾ, PDF-കൾ, കംപൈൽഡ് ഫയലുകൾ, പ്ലെയിൻ ടെക്സ്റ്റ് അല്ലാത്ത എന്തും — കോഡ് കോൺഫ്ലിക്റ്റുകൾ പരിഹരിക്കാൻ കഴിയുന്ന രീതിയിൽ പരിഹരിക്കാനാകില്ല. ചിന്തിക്കാൻ ലൈൻ-ബൈ-ലൈൻ ഡിഫ് (diff) ഇല്ല. ഒരു പതിപ്പ് മൊത്തത്തിൽ തിരഞ്ഞെടുക്കുകയോ അല്ലെങ്കിൽ രണ്ട് പതിപ്പുകൾ യഥാർത്ഥത്തിൽ ഒരു ചിത്രവും അതിന്റെ ഒപ്റ്റിമൈസ് ചെയ്ത പകർപ്പും പോലുള്ള പൊരുത്തപ്പെടുന്ന ജോഡിയായിരിക്കുമ്പോൾ, ശരിയായ ഉറവിടത്തിൽ നിന്ന് ഡിറൈവ്ഡ് ഫയൽ പുനരുജ്ജീവിപ്പിക്കുകയോ ചെയ്യുക എന്നതാണ് യഥാർത്ഥ ഓപ്ഷനുകൾ. നിങ്ങൾ ഏത് സാഹചര്യത്തിലാണ് ഉള്ളതെന്ന് മനസ്സിലാക്കുക എന്നതാണ് പ്രധാന കടമ്പ.

ഗുണങ്ങൾ

• ഏത് വശം വിശ്വസിക്കണമെന്ന് ഊഹിക്കുന്നതിന് പകരം ഡിറൈവ്ഡ് ഫയൽ പുനരുജ്ജീവിപ്പിക്കുന്നത് (ഈ സാഹചര്യത്തിൽ WebP) സ്ഥിരത ഉറപ്പുനൽകുന്നു.
• ഒരു അപകടസാധ്യതയുള്ള കുറുക്കുവഴി വിശ്വസിക്കുന്നതിന് മുമ്പ് ഒറ്റപ്പെട്ട ഒരു ബ്രാഞ്ചിൽ ആദ്യം പരിശോധിക്കുന്നത്, തെറ്റായ അനുമാനങ്ങൾ വിലകുറഞ്ഞ രീതിയിൽ പിടിക്കാൻ സഹായിക്കുന്നു.
• ഒറിജിനൽ ഫയൽ ഫോർമാറ്റ് ഒരു ഫാൾബാക്ക് ആയി സൂക്ഷിക്കുന്നത് (ഒരു വഴി <picture> എലമെന്റ്, ഈ സാഹചര്യത്തിൽ) അർത്ഥമാക്കുന്നത് താൽക്കാലികമായി കേടായ ഒപ്റ്റിമൈസ് ചെയ്ത ഒരു കോപ്പി പോലും സന്ദർശകനായുള്ള പേജിനെ പൂർണ്ണമായി തകർക്കുന്നില്ല എന്നാണ്.

ദോഷങ്ങൾ

• വേഗത്തിലുള്ള ഓപ്ഷനുകളൊന്നും (pick-a-version, forced merge strategy, deleting and re-merging) യഥാർത്ഥത്തിൽ ഒരു പൊരുത്തമില്ലാത്ത ജോഡി പ്രശ്നം പരിഹരിക്കുന്നില്ല — അവ കോൺഫ്ലിക്റ്റ് മെസ്സേജ് അപ്രത്യക്ഷമാക്കുക മാത്രമാണ് ചെയ്യുന്നത്.
• ഇത് ശരിയായി പരിഹരിക്കുന്നതിന് ഡയറക്ട് സെർവർ അല്ലെങ്കിൽ കമാൻഡ്-ലൈൻ ആക്സസും ഒരു ഇമേജ്-കൺവേർഷൻ ടൂളും ആവശ്യമാണ്, ഇത് ഒരു ബ്രൗസർ-ഓൺലി അല്ലെങ്കിൽ ഡെസ്ക്ടോപ്പ്-ആപ്പ്-ഓൺലി വർക്ക്ഫ്ലോയ്ക്ക് ചെയ്യാൻ കഴിയുന്നതിന് പുറത്താണ്.
• അടിസ്ഥാന കാരണം — ലൈവ് ബ്രാഞ്ചിലേക്കുള്ള ഒരു നേരിട്ടുള്ള എഡിറ്റ്, സാധാരണ റിവ്യൂ ഫ്ലോ ഒഴിവാക്കുന്നു — എന്നത് ഒരു പ്രോസസ്സ് വിടവാണ്, അത് വീണ്ടും സംഭവിക്കുന്നത് ഒരു ഒറ്റത്തവണ സാങ്കേതിക പരിഹാരത്തിന് തടയാൻ കഴിയില്ല.

മുന്നറിയിപ്പ്

ഈ ലേഖനം വിദ്യാഭ്യാസപരമാണ്, കൂടാതെ ഒരു യഥാർത്ഥ സാഹചര്യത്തെ പൊതുവായ പദങ്ങളിൽ വിവരിക്കുന്നു; നിർദ്ദിഷ്ട ഫയൽ നാമങ്ങൾ, പാത്തുകൾ, ഐഡന്റിഫയറുകൾ എന്നിവ പൊതുവൽക്കരിച്ചിരിക്കുന്നു. ഇവിടെ കാണിച്ചിരിക്കുന്ന കമാൻഡുകൾക്ക് യഥാർത്ഥ ഫയലുകളും ബ്രാഞ്ച് ഹിസ്റ്ററിയും പരിഷ്കരിക്കാനോ ഉപേക്ഷിക്കാനോ കഴിയും — എപ്പോഴും ഒറ്റപ്പെട്ട ബ്രാഞ്ചിലോ അല്ലെങ്കിൽ ത്രോഅവേ കോപ്പിയിലോ ആദ്യം പരീക്ഷിക്കുക, നിങ്ങളുടെ നിർദ്ദിഷ്ട സാഹചര്യത്തിൽ "ours", "theirs" എന്നിവ ഏത് ദിശയിലേക്കാണ് വിരൽ ചൂണ്ടുന്നതെന്ന് നിങ്ങൾ മനസ്സിലാക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, ഒപ്പം ഒരു കോൺഫ്ലിക്റ്റ് ബലമായി പരിഹരിക്കുന്ന എന്തെങ്കിലും റൺ ചെയ്യുന്നതിന് മുമ്പ് നിങ്ങൾക്ക് ഒരു ബാക്കപ്പോ വീണ്ടെടുക്കാനുള്ള വഴിയോ ഉണ്ടെന്ന് സ്ഥിരീകരിക്കുക. ഒരു കമാൻഡിനെ ആശ്രയിക്കുന്നതിന് മുമ്പ് നിങ്ങളുടെ സ്വന്തം റിപ്പോസിറ്ററിയുടെ യഥാർത്ഥ അവസ്ഥയുമായി ബന്ധപ്പെട്ട് അത് പരിശോധിക്കുക.

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ (FAQ)

• എന്തുകൊണ്ട് GitHub വെബ്സൈറ്റിന് ഇമേജ് ഫയലുകളിലെ കോൺഫ്ലിക്റ്റുകൾ പരിഹരിക്കാൻ കഴിയുന്നില്ല? — അതിന്റെ ബ്രൗസർ അധിഷ്ഠിത കോൺഫ്ലിക്റ്റ് എഡിറ്റർ ലൈൻ അധിഷ്ഠിത ടെക്സ്റ്റ് മാത്രമേ മനസ്സിലാക്കുന്നുള്ളൂ; ആ ഇന്റർഫേസിലൂടെ PNG അല്ലെങ്കിൽ WebP പോലെയുള്ള ബൈനറി ഡാറ്റ താരതമ്യം ചെയ്യാനോ മെർജ് ചെയ്യാനോ ഒരു വഴിയുമില്ല.
• എന്താണ് "modify/delete" കോൺഫ്ലിക്റ്റ്? — ഒരു ബ്രാഞ്ച് ഒരു ഫയൽ ഡിലീറ്റ് ചെയ്യുകയും മറ്റൊരു ബ്രാഞ്ച് അത് മാറ്റുകയും ചെയ്യുമ്പോൾ ഇത് സംഭവിക്കുന്നു; ഏത് മാറ്റമാണ് വിജയിക്കേണ്ടതെന്ന് ഊഹിക്കുന്നതിന് പകരം Git ഇത് ഫ്ലാഗ് ചെയ്യുന്നു.
• ഒരു ബ്രാഞ്ചിൽ നിന്ന് ഒരു ഫയൽ ഡിലീറ്റ് ചെയ്യുന്നത് മെർജ് കോൺഫ്ലിക്റ്റ് ഒഴിവാക്കുമോ? — ഇല്ല. ബ്രാഞ്ചുകൾ വേർപിരിയുമ്പോൾ ഫയൽ നിലവിലുണ്ടായിരുന്നെങ്കിൽ, ഒരു വശത്ത് അത് മാറ്റം വരുത്തുമ്പോൾ മറുവശത്ത് അത് ഡിലീറ്റ് ചെയ്യുന്നത് ഇപ്പോഴും ഒരു കോൺഫ്ലിക്റ്റ് ഉണ്ടാക്കുന്നു, ഒരു വ്യത്യസ്ത തരം എന്ന് മാത്രം.
• ഒരു ഇമേജ് കോൺഫ്ലിക്റ്റിന് ഒരു ഡെസ്ക്ടോപ്പ് Git ക്ലയന്റിലെ "use my version" അല്ലെങ്കിൽ "use theirs" സുരക്ഷിതമാണോ? — ഇത് കോൺഫ്ലിക്റ്റ് പരിഹരിക്കുന്നു, എന്നാൽ ഒരു ഫയൽ അതേപടി സൂക്ഷിക്കുന്നതിലൂടെ മാത്രം; WebP കോപ്പി പോലെയുള്ള ഒരു ഡിറൈവ്ഡ് കൗണ്ടർപാർട്ട് സ്വയമേവ പരിഹരിക്കപ്പെടില്ല.
• എന്താണ് git merge -X ours യഥാർത്ഥത്തിൽ ചെയ്യുന്നത്? — ചോദിക്കാൻ നിർത്താതെ, മൊത്തത്തിലുള്ള ലയനത്തിനായി കറന്റ് ബ്രാഞ്ചിന്റെ പതിപ്പ് സൂക്ഷിച്ചുകൊണ്ട് വൈരുദ്ധ്യമുള്ള എല്ലാ ഫയലുകളും സ്വയമേവ പരിഹരിക്കാൻ ഇത് Git-നോട് പറയുന്നു.
• WebP ഫയൽ ലയിപ്പിക്കുന്നതിന് പകരം എന്തുകൊണ്ട് അത് പുനരുജ്ജീവിപ്പിക്കണം? — ഇത് ഒറിജിനൽ ഇമേജിന്റെ കംപ്രസ് ചെയ്ത ഒരു ഡിറൈവേറ്റീവ് ആണ്; കംപ്രസ് ചെയ്ത രണ്ട് വ്യത്യസ്ത പതിപ്പുകൾ "മെർജ്" ചെയ്യാൻ അർത്ഥവത്തായ ഒരു വഴിയുമില്ല, അതിനാൽ ശരിയായ ഉറവിടത്തിൽ നിന്ന് അത് പുനഃസൃഷ്ടിക്കുക എന്നത് മാത്രമാണ് ശരിയായ പരിഹാരം.
• ടീമുകൾ എങ്ങനെയാണ് ഇത്തരം കോൺഫ്ലിക്റ്റ് ആദ്യം തന്നെ ഒഴിവാക്കുന്നത്? — ഒന്നിലധികം സ്ഥലങ്ങളിൽ നിന്ന് ലൈവ് ബ്രാഞ്ചിലേക്ക് നേരിട്ട് എഡിറ്റുകൾ അനുവദിക്കുന്നതിന് പകരം, ലൈവ് ബ്രാഞ്ചിൽ എത്തുന്നതിന് മുമ്പ് എല്ലാ മാറ്റങ്ങളും ഒരു വർക്കിംഗ് ബ്രാഞ്ചിലൂടെ കടന്നുപോകുന്ന ഒരു സ്ഥിരതയുള്ള ഫ്ലോ നിലനിർത്തുന്നതിലൂടെ.

ടാഗുകൾ

#git #github #webp #imageoptimization #webdev #devops #versioncontrol #mergeconflict #cicd #webperformance