நாங்கள் எப்படி ஒரு Git இமேஜ் மெர்ஜ் கான்ஃப்ளிக்டை சரிசெய்தோம் (மேலும் ஏன் GitHub இன் வலைத்தளத்தால் முடியவில்லை)

குறியீட்டில் மெர்ஜ் கான்ஃப்ளிக்ட்கள் போதுமான எரிச்சலூட்டுகின்றன. அவை ஒரு இமேஜ் கோப்பில் நிகழும்போது, ​​பெரும்பாலான மக்கள் உறைந்துவிடுகிறார்கள் — ஒரு படத்திற்கு "diff view" இல்லை, மேலும் GitHub இல் வழக்கமான fix-it-in-the-browser பட்டன் அங்கு இல்லை. இந்த பதிவு சரியாக அதைப் பற்றிய உண்மையான வழக்கை விவரிக்கிறது: எது வேலை செய்யவில்லை, மற்றும் எது வேலை செய்தது.

இன்று, ஆகஸ்ட் 29, 2026 நிலவரப்படி, இதைப் புரிந்துகொள்வது மதிப்புக்குரியது, ஏனென்றால் பல சிறிய குழுக்கள் Git மூலம் அதிக உள்ளடக்கம் கொண்ட வலைத்தளங்களை இயக்குகின்றன, தொழில்நுட்பம் அல்லாத நபர்கள் டெஸ்க்டாப் ஆப் மூலம் உரை மற்றும் பட மாற்றங்களை தள்ளுகிறார்கள். அந்த கலவை — எளிய மொழி உள்ளடக்க எடிட்டர்கள், பைனரி கோப்புகள், மற்றும் ஒரு உண்மையான டெப்ளாய் பைப்லைன் — அங்குதான் இந்த பிரச்சனை துல்லியமாக வெளிப்படுகிறது.

அமைப்பு: இரண்டு கிளைகள், ஒரு பகிரப்பட்ட படம்

திட்டம் எளிமையான இரண்டு-கிளை பணிப்பாய்வைப் பயன்படுத்துகிறது. staging அங்குதான் அன்றாட வேலைகள் நடக்கின்றன — ஒரு உள்ளடக்க எடிட்டர் மாற்றங்களை அங்கே சுதந்திரமாக தள்ளுகிறார், மேலும் அது தானாகவே ஒரு பிரிவியூ தளத்திற்கு டெப்ளாய் ஆகிறது. main உண்மையான நேரலை தளம், அதிலிருந்து மதிப்பாய்வு செய்யப்பட்ட புல் ரிக்வெஸ்ட் வரும்போது மட்டுமே புதுப்பிக்கப்படும் staging இதில் இணைக்கப்பட்டுள்ளது.

குழு சமீபத்தில் தளத்தின் படங்களை WebP ஆக மாற்றியது, இது அதே காட்சித் தரத்தில் PNG அல்லது JPG ஐ விட மிகச் சிறிய நவீன வடிவம். ஒவ்வொரு படமும் இப்போது ஒரு ஜோடியாக உள்ளது: அசல் .png, மற்றும் ஒரு பொருத்தம் .webp, ஒரு HTML உடன் ஒன்றாக இணைக்கப்பட்டுள்ளது <picture> element அதனால் WebP-திறனுள்ள உலாவிகள் சிறிய கோப்பை தானாகவே பெறுகின்றன, மற்ற அனைத்தும் அசலுக்குத் திரும்பும்.

பின்னர் கிட்டத்தட்ட ஒரே நேரத்தில் இரண்டு வெவ்வேறு கிளைகளில் இரண்டு விஷயங்கள் நடந்தன: யாரோ ஒரு தயாரிப்பு ஸ்கிரீன்ஷாட்டில் சிறிய, நேரடி திருத்தத்தை செய்தனர் main, வழக்கமான மதிப்பாய்வு ஓட்டத்தைத் தவிர்த்து, அதே நேரத்தில் உள்ளடக்க எடிட்டர் தனித்தனியாக அதே ஸ்கிரீன்ஷாட்டின் புதிய பதிப்பைப் பதிவேற்றினார் staging. இரண்டு திருத்தங்களும் ஒரே கோப்பு பாதையைத் தொட்டன. இரண்டு தரப்புக்கும் மற்றொன்றைப் பற்றித் தெரியாது.

ஏன் GitHub இன் வலைத்தளத்தால் இதைச் சரிசெய்ய முடியவில்லை

உள்ளடக்க எடிட்டர் இதை கொண்டு வர ஒரு புல் ரிக்வெஸ்ட்டைத் திறந்தபோது staging இதில் புதுப்பிக்கவும் main, GitHub அதை உடனடியாகக் கொடியிட்டது: "This branch has conflicts that must be resolved." பொதுவாக, கிளிக் செய்வதன் மூலம் உரை கோப்பின் இரண்டு பதிப்புகளையும் அருகருகே காட்டும் வலை அடிப்படையிலான எடிட்டரைப் பெறுவீர்கள், எனவே எந்த வரிகளை வைத்திருக்க வேண்டும் என்பதை நீங்கள் தேர்வு செய்யலாம்.

அந்த எடிட்டர் படங்களுக்கு இல்லை. GitHub இன் உலாவி அடிப்படையிலான கான்ஃப்ளிக்ட் ரிசல்யூஷன் வரி அடிப்படையிலான உரையை மட்டுமே புரிந்துகொள்கிறது — குறியீடு, மார்க்டவுன், கான்பிக் கோப்புகள். ஒரு PNG அல்லது WebP கோப்பில் ஒப்பிட "lines" இல்லை. எவர் எவ்வளவு கவனமாக கிளிக் செய்தாலும், இதைத் தீர்க்க எந்த பட்டனும், பார்வையும், வலைத்தளத்தின் வழியாக எந்தப் பாதையும் இல்லை. வெளிப்படையாகச் சொல்வது மதிப்பு: உள்ளடக்க எடிட்டர் எந்தத் தவறும் செய்யவில்லை. இந்த குறிப்பிட்ட பிரச்சனையைத் தீர்க்க கருவிக்கு உண்மையிலேயே எந்த வழியும் இல்லை.

மறைக்கப்பட்ட இரண்டாவது பிரச்சனை

இதைச் சரிசெய்ய, கோப்பின் இரண்டு பதிப்புகளையும் உள்நாட்டில் இழுத்து அவற்றை நேரடியாக ஒப்பிட வேண்டும் — அங்குதான் ஒரு திருட்டுத்தனமான பிரச்சனை உருவானது. இதில் உள்ள புதிய ஸ்கிரீன்ஷாட் staging முன்பை விட பெரிய மற்றும் உயர் தெளிவுத்திறன் கொண்ட ஒரு உண்மையான அப்டேட். ஆனால் அதனுடன் இணைக்கப்பட்ட WebP கோப்பு நீண்ட காலமாகத் தொடப்படவில்லை — பரிமாணங்கள் கூட பொருந்தவில்லை. புதிய PNG 1024 க்கு 1024 பிக்சல்கள்; அதன் அருகில் உள்ள WebP இன்னும் 750 க்கு 750 ஆக இருந்தது, இது படத்தின் முந்தைய பதிப்பிலிருந்து முழுமையாக எஞ்சியிருந்தது.

அதாவது கான்ஃப்ளிக்ட்டில் "picking a side" — எந்தப் பதிப்பையும் மொத்தமாக வைத்திருப்பது — ஒரு பொருந்தாத ஜோடியை அனுப்பியிருக்கும். PNG புதிய ஸ்கிரீன்ஷாட்டைக் காண்பிக்கும், ஆனால் உலாவி WebP ஐ (பெரும்பாலான நவீன உலாவிகள்) விரும்பும் எந்த பார்வையாளரும் அமைதியாக பழைய, தவறான படத்தைக் காண்பார்கள். கான்ஃப்ளிக்ட் செய்தி மறைந்துவிடும்; உண்மையான பிழை கவனிக்கப்படாமல் அனுப்பப்படும்.

படி 1: இரண்டு பதிப்புகளையும் சரியாக ஒப்பிடுக

முதல் படி எதையும் தீர்க்கவில்லை — இது உண்மையில் என்ன மாறியது மற்றும் எங்கே என்பதைப் புரிந்துகொள்ள, இரண்டு கிளைகளிலும் உள்ள கோப்பு அளவுகள் மற்றும் பரிமாணங்களை அவற்றின் பொதுவான தொடக்கப் புள்ளியுடன் ஒப்பிடுவது.

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

இது கடைசியாகப் பகிரப்பட்டதிலிருந்து இரு கிளைகளும் சுயாதீனமாக கோப்பை மாற்றியிருப்பதைக் காட்டியது — ஒரு உண்மையான மூன்று-வழி விலகல், வெறுமனே "one side is newer" அல்ல.

படி 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

இதற்குப் பிறகு, புல் ரிக்வெஸ்ட் சுத்தமானதாகவும் இணைக்கக்கூடியதாகவும் காணப்பட்டது, மேலும் நேரலை தளம் WebP திறன் கொண்டதா இல்லையா என்பதைப் பொருட்படுத்தாமல் ஒவ்வொரு பார்வையாளருக்கும் புதிய ஸ்கிரீன்ஷாட்டை சரியாக வழங்கியது.

பரிசீலிக்கப்பட்ட மற்றும் நிராகரிக்கப்பட்ட முறைகள்

வழியில் சில வேகமாகத் தோன்றும் ஷார்ட்கட்கள் வந்தன, ஒவ்வொன்றையும் பற்றித் தெரிந்துகொள்வது மதிப்பு, அது ஏன் பயன்படுத்தப்படவில்லை என்பதைத் தெரிந்துகொள்வதும் மதிப்பு.

டெஸ்க்டாப் 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" கான்ஃப்ளிக்ட், அதன் சொந்த எச்சரிக்கை செய்தியுடன். இது பிரச்சனையைத் தவிர்ப்பதற்குப் பதிலாக மறுபெயரிடுகிறது.

கான்ஃப்ளிக்ட்டின் மீது ஃபோர்ஸ்-புஷ் செய்வது. இன்னும் ஒரு கடுமையான விருப்பம், ஃபோர்ஸ் புஷ் மூலம் மற்ற கிளையின் வரலாற்றுடன் லைவ் கிளையை முழுவதுமாக மேலெழுதுவது. இது உண்மையில் கான்ஃப்ளிக்ட் ரிசல்யூஷன் அல்ல — இது ஒரு தரப்பின் மாற்றங்களை முற்றிலுமாக நிராகரிப்பது, வேறொருவரின் உண்மையான வேலையை அமைதியாக இழக்க நேரிடும். லைவ் தளத்திற்கு டெப்ளாய் ஆகும் ஒரு கிளையில், அது உண்மையிலேயே ஒரு ஆபத்தான நடவடிக்கை, எடுக்க வேண்டிய ஷார்ட்கட் அல்ல.

முடிவுரை

பைனரி கோப்பு கான்ஃப்ளிக்ட்கள் — படங்கள், PDFகள், தொகுக்கப்பட்ட கோப்புகள், எளிய உரை அல்லாத எதுவும் — குறியீடு கான்ஃப்ளிக்ட்களைத் தீர்க்கும் வழியில் தீர்க்க முடியாது. பகுத்தறிய வரிக்கு வரி diff இல்லை. உண்மையான விருப்பங்கள் மட்டுமே ஒரு பதிப்பை மொத்தமாகத் தேர்ந்தெடுப்பது, அல்லது, இரண்டு பதிப்புகளும் உண்மையில் ஒரு படமும் அதன் உகந்த நகலும் போன்ற பொருத்தப்பட்ட ஜோடியாக இருக்கும்போது, ​​சரியான மூலத்திலிருந்து பெறப்பட்ட கோப்பை மீண்டும் உருவாக்குவது. நீங்கள் எந்த சூழ்நிலையில் இருக்கிறீர்கள் என்பதைப் புரிந்துகொள்வதே பெரும் போர்.

நன்மைகள்

• எந்தப் பக்கத்தை நம்புவது என்று யூகிக்காமல், பெறப்பட்ட கோப்பை (இந்த விஷயத்தில் WebP) மீண்டும் உருவாக்குவது நிலைத்தன்மைக்கு உத்தரவாதம் அளிக்கிறது.
• ஆபத்தானது போல் தோன்றும் ஷார்ட்கட்டை நம்புவதற்கு முன், முதலில் ஒரு தனிமைப்படுத்தப்பட்ட கிளையில் சோதிப்பது, தவறான அனுமானங்களை மலிவாகப் பிடிக்கும்.
• அசல் கோப்பு வடிவத்தை ஒரு ஃபால்பேக்காக வைத்திருப்பது (இதன் மூலம் ஒரு <picture> எலிமெண்ட், இந்த விஷயத்தில்) என்பது தற்காலிகமாக உடைந்த உகந்த நகல் கூட ஒரு பார்வையாளருக்கு பக்கத்தை ஒருபோதும் முழுமையாக உடைக்காது என்பதாகும்.

தீமைகள்

• வேகமான விருப்பங்கள் எதுவும் (பதிப்பைத் தேர்ந்தெடுப்பது, கட்டாய மெர்ஜ் உத்தி, நீக்குதல் மற்றும் மீண்டும் இணைத்தல்) உண்மையில் பொருந்தாத ஜோடி பிரச்சனையைத் தீர்க்காது — அவை கான்ஃப்ளிக்ட் செய்தியை மறையச் செய்யும்.
• இதைச் சரியாகச் சரிசெய்வதற்கு நேரடி சர்வர் அல்லது கமாண்ட்-லைன் அணுகல் மற்றும் ஒரு பட மாற்றக் கருவி தேவைப்பட்டது, இது உலாவி-மட்டும் அல்லது டெஸ்க்டாப்-ஆப்-மட்டும் பணிப்பாய்வு செய்யக்கூடியதற்கு அப்பாற்பட்டது.
• அடிப்படையான காரணம் — வழக்கமான மதிப்பாய்வு ஓட்டத்தைத் தவிர்த்து, லைவ் கிளையில் நேரடியாகத் திருத்துவது — ஒரு செயல்முறை இடைவெளியாகும், இது மீண்டும் நடப்பதை ஒரு முறை தொழில்நுட்பத் திருத்தம் தடுக்காது.

எச்சரிக்கை

இந்தக் கட்டுரை கல்விக்குரியது மற்றும் பொதுவான சொற்களில் உண்மையான சூழ்நிலையை விவரிக்கிறது; குறிப்பிட்ட கோப்பு பெயர்கள், பாதைகள் மற்றும் அடையாளங்காட்டிகள் பொதுமைப்படுத்தப்பட்டுள்ளன. இங்கு காட்டப்பட்டுள்ள கமாண்ட்கள் உண்மையான கோப்புகள் மற்றும் கிளை வரலாற்றை மாற்றலாம் அல்லது நிராகரிக்கலாம் — எப்போதுமே தனிமைப்படுத்தப்பட்ட கிளை அல்லது தூக்கி எறியும் நகலில் முதலில் சோதிக்கவும், உங்கள் குறிப்பிட்ட சூழ்நிலையில் "ours" மற்றும் "theirs" எந்த திசையைக் குறிக்கின்றன என்பதைப் புரிந்துகொள்கிறீர்கள் என்பதை உறுதிப்படுத்தவும், மேலும் கான்ஃப்ளிக்ட்டைக் கட்டாயப்படுத்தித் தீர்க்கும் எதையும் இயக்குவதற்கு முன், உங்களிடம் காப்புப்பிரதி அல்லது மீட்டெடுப்பதற்கான வழி இருப்பதை உறுதிப்படுத்தவும். எந்தவொரு கமாண்டையும் நம்புவதற்கு முன் உங்கள் சொந்த ரெப்போசிட்டரியின் உண்மையான நிலைக்கு எதிராக சரிபார்க்கவும்.

அடிக்கடி கேட்கப்படும் கேள்விகள்

• ஏன் GitHub இன் வலைத்தளத்தால் படக் கோப்புகளில் உள்ள கான்ஃப்ளிக்ட்களைத் தீர்க்க முடியாது? — அதன் உலாவி அடிப்படையிலான கான்ஃப்ளிக்ட் எடிட்டர் வரி அடிப்படையிலான உரையை மட்டுமே புரிந்துகொள்கிறது; அந்த இன்டர்ஃபேஸ் மூலம் PNG அல்லது WebP போன்ற பைனரி தரவை ஒப்பிடவோ அல்லது இணைக்கவோ வழி இல்லை.
• ஒரு "modify/delete" கான்ஃப்ளிக்ட் என்றால் என்ன? — ஒரு கிளை ஒரு கோப்பை நீக்கிவிட்டு, கடைசியாக வரலாற்றைப் பகிர்ந்ததிலிருந்து மற்றொரு கிளை அதை மாற்றும்போது இது நிகழ்கிறது; எந்த மாற்றம் வெல்ல வேண்டும் என்று ஊகிப்பதற்குப் பதிலாக Git இதைக் கொடியிடுகிறது.
• ஒரு கிளையிலிருந்து கோப்பை நீக்குவது மெர்ஜ் கான்ஃப்ளிக்ட்டைத் தவிர்க்கிறதா? — இல்லை. கிளைகள் பிரிந்தபோது கோப்பு இருந்திருந்தால், ஒரு பக்கத்தில் அது மாற்றப்படும்போது மறுபக்கத்தில் அதை நீக்குவது இன்னும் ஒரு கான்ஃப்ளிக்ட்டை உருவாக்குகிறது, இது ஒரு வித்தியாசமான வகை.
• டெஸ்க்டாப் Git கிளையண்டில் "use my version" அல்லது "use theirs" என்பது ஒரு இமேஜ் கான்ஃப்ளிக்ட்டுக்குப் பாதுகாப்பானதா? — இது கான்ஃப்ளிக்ட்டைத் தீர்க்கிறது, ஆனால் ஒரு கோப்பை அப்படியே வைத்திருப்பதன் மூலம் மட்டுமே; WebP நகல் போன்ற பெறப்பட்ட இணையானவை தானாகவே சரிசெய்யப்படாது.
• இது என்ன செய்கிறது git merge -X ours உண்மையில் செய்யுமா? — இது கேட்க நிற்காமல், முழு மெர்ஜுக்கும், தற்போதைய கிளையின் பதிப்பை வைத்திருப்பதன் மூலம் ஒவ்வொரு கான்ஃப்ளிக்ட் கோப்பையும் தானாகவே தீர்க்க Git இடம் சொல்கிறது.
• WebP கோப்பை இணைப்பதற்குப் பதிலாக ஏன் அதை மீண்டும் உருவாக்க வேண்டும்? — இது அசல் படத்தின் சுருக்கப்பட்ட வழித்தோன்றல்; இரண்டு வெவ்வேறு சுருக்கப்பட்ட பதிப்புகளை "merge" செய்ய அர்த்தமுள்ள வழியெதுவும் இல்லை, எனவே சரியான மூலத்திலிருந்து அதை மீண்டும் உருவாக்குவது மட்டுமே சரியான திருத்தம்.
• குழுக்கள் இதுபோன்ற கான்ஃப்ளிக்ட்டை முதலில் எப்படித் தவிர்க்கின்றன? — பல இடங்களிலிருந்து லைவ் கிளைக்கு நேரடி திருத்தங்களை அனுமதிப்பதற்குப் பதிலாக, எல்லா மாற்றங்களும் லைவ் கிளையை அடைவதற்கு முன் ஒரு வேலை செய்யும் கிளை வழியாகச் செல்லும் ஒரு சீரான ஓட்டத்தை வைத்திருப்பதன் மூலம்.

குறிச்சொற்கள்

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