Git ಇಮೇಜ್ ಮರ್ಜ್ ಕಾನ್‌ಫ್ಲಿಕ್ಟ್ ಅನ್ನು ನಾವು ಹೇಗೆ ಸರಿಪಡಿಸಿದೆವು (ಮತ್ತು GitHub ನ ವೆಬ್‌ಸೈಟ್‌ಗೆ ಏಕೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ)

ಮರ್ಜ್ ಕಾನ್‌ಫ್ಲಿಕ್ಟ್‌ಗಳು ಕೋಡ್‌ನಲ್ಲಿಯೇ ಸಾಕಷ್ಟು ಕಿರಿಕಿರಿಯುಂಟುಮಾಡುತ್ತವೆ. ಅವು ಇಮೇಜ್ ಫೈಲ್‌ನಲ್ಲಿ ಸಂಭವಿಸಿದಾಗ, ಹೆಚ್ಚಿನ ಜನರು ಸ್ತಬ್ಧರಾಗುತ್ತಾರೆ — ಚಿತ್ರಕ್ಕೆ ಯಾವುದೇ "diff view" ಇರುವುದಿಲ್ಲ ಮತ್ತು GitHub ನಲ್ಲಿ ಸಾಮಾನ್ಯವಾದ fix-it-in-the-browser ಬಟನ್ ಇರುವುದಿಲ್ಲ. ಈ ಪೋಸ್ಟ್ ನಿಖರವಾಗಿ ಅದೇ ರೀತಿಯ ನೈಜ ಪ್ರಕರಣವನ್ನು ವಿವರಿಸುತ್ತದೆ: ಯಾವುದು ಕೆಲಸ ಮಾಡಲಿಲ್ಲ ಮತ್ತು ಯಾವುದು ಕೆಲಸ ಮಾಡಿತು.

ಇಂದು, ಆಗಸ್ಟ್ 29, 2026 ರ ಹೊತ್ತಿಗೆ, ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ ಹೆಚ್ಚಿನ ಸಣ್ಣ ತಂಡಗಳು Git ಮೂಲಕ ಕಂಟೆಂಟ್-ಹೆವಿ ವೆಬ್‌ಸೈಟ್‌ಗಳನ್ನು ನಡೆಸುತ್ತವೆ, ತಾಂತ್ರಿಕವಲ್ಲದ ಜನರು ಡೆಸ್ಕ್‌ಟಾಪ್ ಅಪ್ಲಿಕೇಶನ್ ಮೂಲಕ ಪಠ್ಯ ಮತ್ತು ಇಮೇಜ್ ಬದಲಾವಣೆಗಳನ್ನು ಪುಶ್ ಮಾಡುತ್ತಾರೆ. ಆ ಮಿಶ್ರಣ — ಸರಳ ಭಾಷೆಯ ಕಂಟೆಂಟ್ ಎಡಿಟರ್‌ಗಳು, ಬೈನರಿ ಫೈಲ್‌ಗಳು ಮತ್ತು ನಿಜವಾದ ಡಿಪ್ಲಾಯ್ ಪೈಪ್‌ಲೈನ್ — ನಿಖರವಾಗಿ ಈ ಸಮಸ್ಯೆ ಎದುರಾಗುವ ಸ್ಥಳವಾಗಿದೆ.

ಸೆಟಪ್: ಎರಡು ಬ್ರಾಂಚ್‌ಗಳು, ಒಂದು ಹಂಚಿಕೊಂಡ ಇಮೇಜ್

ಪ್ರಾಜೆಕ್ಟ್ ಸರಳವಾದ ಎರಡು-ಬ್ರಾಂಚ್ ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ಬಳಸುತ್ತದೆ. staging ಇಲ್ಲಿಯೇ ದಿನನಿತ್ಯದ ಕೆಲಸಗಳು ನಡೆಯುತ್ತವೆ — ಕಂಟೆಂಟ್ ಎಡಿಟರ್ ಅಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಮುಕ್ತವಾಗಿ ಪುಶ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅದು ಪ್ರಿವ್ಯೂ ಸೈಟ್‌ಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಡಿಪ್ಲಾಯ್ ಆಗುತ್ತದೆ. main ನಿಜವಾದ ಲೈವ್ ಸೈಟ್ ಆಗಿದೆ, ಇಲ್ಲಿಂದ ರಿವ್ಯೂ ಮಾಡಿದ Pull Request ಅನ್ನು staging ಮರ್ಜ್ ಮಾಡಿದಾಗ ಮಾತ್ರ ಅಪ್‌ಡೇಟ್ ಆಗುತ್ತದೆ.

ತಂಡವು ಇತ್ತೀಚೆಗಷ್ಟೇ ಸೈಟ್‌ನ ಇಮೇಜ್‌ಗಳನ್ನು WebP ಗೆ ಕನ್ವರ್ಟ್ ಮಾಡಿತ್ತು, ಇದು ಒಂದೇ ದೃಶ್ಯ ಗುಣಮಟ್ಟದಲ್ಲಿ PNG ಅಥವಾ JPG ಗಿಂತ ತುಂಬಾ ಚಿಕ್ಕದಾದ ಆಧುನಿಕ ಫಾರ್ಮ್ಯಾಟ್ ಆಗಿದೆ. ಪ್ರತಿಯೊಂದು ಇಮೇಜ್ ಈಗ ಜೋಡಿಯಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ: ಮೂಲ .png, ಮತ್ತು ಹೊಂದಾಣಿಕೆಯಾಗುವ .webp, HTML ಜೊತೆಗೆ ಒಟ್ಟಿಗೆ ವೈರ್ ಮಾಡಲಾಗಿದೆ <picture> ಎಲಿಮೆಂಟ್, ಇದರಿಂದ WebP-ಸಾಮರ್ಥ್ಯವಿರುವ ಬ್ರೌಸರ್‌ಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಣ್ಣ ಫೈಲ್ ಅನ್ನು ಪಡೆಯುತ್ತವೆ ಮತ್ತು ಉಳಿದೆಲ್ಲವೂ ಮೂಲಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತವೆ.

ನಂತರ ಬಹುತೇಕ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಎರಡು ವಿಭಿನ್ನ ಬ್ರಾಂಚ್‌ಗಳಲ್ಲಿ ಎರಡು ವಿಷಯಗಳು ಸಂಭವಿಸಿದವು: ಯಾರೋ ಒಬ್ಬರು ಒಂದು ಪ್ರಾಡಕ್ಟ್ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗೆ ಸಣ್ಣ, ನೇರ ಎಡಿಟ್ ಮಾಡಿದರು main, ಸಾಮಾನ್ಯ ರಿವ್ಯೂ ಫ್ಲೋ ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡಿ, ಅದೇ ಸಮಯದಲ್ಲಿ ಕಂಟೆಂಟ್ ಎಡಿಟರ್ ಪ್ರತ್ಯೇಕವಾಗಿ ಅದೇ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಇದರ ಮೂಲಕ ಅಪ್‌ಲೋಡ್ ಮಾಡಿದರು staging. ಎರಡೂ ಎಡಿಟ್‌ಗಳು ಒಂದೇ ಫೈಲ್ ಪಾತ್ ಅನ್ನು ಸ್ಪರ್ಶಿಸಿದವು. ಎರಡೂ ಕಡೆಯವರಿಗೂ ಇನ್ನೊಬ್ಬರ ಬಗ್ಗೆ ತಿಳಿದಿರಲಿಲ್ಲ.

GitHub ನ ವೆಬ್‌ಸೈಟ್ ಇದನ್ನು ಏಕೆ ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ

ಕಂಟೆಂಟ್ ಎಡಿಟರ್ ಇದನ್ನು ತರಲು Pull Request ಅನ್ನು ತೆರೆದಾಗ staging ಅಪ್‌ಡೇಟ್ ಅನ್ನು main, GitHub ಅದನ್ನು ತಕ್ಷಣವೇ ಫ್ಲ್ಯಾಗ್ ಮಾಡಿದೆ: "This branch has conflicts that must be resolved." ಸಾಮಾನ್ಯವಾಗಿ, ಕ್ಲಿಕ್ ಮಾಡುವುದರಿಂದ ಪಠ್ಯ ಫೈಲ್‌ನ ಎರಡೂ ಆವೃತ್ತಿಗಳನ್ನು ಅಕ್ಕಪಕ್ಕದಲ್ಲಿ ತೋರಿಸುವ ವೆಬ್-ಆಧಾರಿತ ಎಡಿಟರ್ ಅನ್ನು ನಿಮಗೆ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಯಾವ ಸಾಲುಗಳನ್ನು ಇರಿಸಿಕೊಳ್ಳಬೇಕೆಂದು ಆಯ್ಕೆ ಮಾಡಬಹುದು.

ಆ ಎಡಿಟರ್ ಇಮೇಜ್‌ಗಳಿಗಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. 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

ಕೊನೆಯದಾಗಿ ಹಂಚಿಕೊಂಡಾಗಿನಿಂದ ಎರಡೂ ಬ್ರಾಂಚ್‌ಗಳು ಫೈಲ್ ಅನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಮಾರ್ಪಡಿಸಿವೆ ಎಂದು ಇದು ತೋರಿಸಿದೆ — ನಿಜವಾದ ತ್ರೀ-ವೇ ಡೈವರ್ಜೆನ್ಸ್, ಕೇವಲ "ಒಂದು ಕಡೆ ಹೊಸದಾಗಿದೆ" ಎಂದಲ್ಲ.

ಹಂತ 2: ಯಾವ ಆವೃತ್ತಿ ವಾಸ್ತವವಾಗಿ ಸರಿಯಾಗಿದೆ ಎಂಬುದನ್ನು ಗುರುತಿಸಿ

ಎರಡೂ PNG ಗಳನ್ನು ಅಕ್ಕಪಕ್ಕದಲ್ಲಿ ತೆರೆಯುವುದರಿಂದ ಇದು ಖಚಿತವಾಯಿತು staging ಆವೃತ್ತಿಯು ನಿಜವಾದ, ಉದ್ದೇಶಿತ ಅಪ್‌ಡೇಟ್ ಆಗಿತ್ತು, ತಪ್ಪು ಅಥವಾ ಭ್ರಷ್ಟಗೊಂಡ ಫೈಲ್ ಅಲ್ಲ.

ಹಂತ 3: ಸರಿಯಾದ ಮೂಲದಿಂದ WebP ಅನ್ನು ಮರುಸೃಷ್ಟಿಸಿ

ಎರಡು ವಿಭಿನ್ನ ಬೈನರಿ ಫೈಲ್‌ಗಳನ್ನು ಮರ್ಜ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುವ ಬದಲು — ಅದು ಸಾಧ್ಯವಿಲ್ಲ — ಪರಿಹಾರವೆಂದರೆ WebP ಅನ್ನು ಹೀಗೆ ಪರಿಗಣಿಸುವುದು ಇದರಿಂದ ಪಡೆಯಲಾಗಿದೆ PNG ನಿಂದ, ರಾಜಿ ಮಾಡಿಕೊಳ್ಳಲು ಪ್ರತ್ಯೇಕ ಫೈಲ್ ಅಲ್ಲ:

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

ಇದು ಸರಿಯಾದ 1024 ಬೈ 1024 ಆಯಾಮಗಳಲ್ಲಿ ಹೊಸ WebP ಅನ್ನು ನಿರ್ಮಿಸಿತು, ಹೊಸ PNG ಗೆ ಸರಿಯಾಗಿ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ. -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 ಕ್ಲೀನ್ ಮತ್ತು ಮರ್ಜ್ ಮಾಡಬಹುದಾದಂತೆ ತೋರಿಸಿದೆ ಮತ್ತು ಲೈವ್ ಸೈಟ್ ಪ್ರತಿಯೊಬ್ಬ ಸಂದರ್ಶಕರಿಗೆ ಹೊಸ ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ಅನ್ನು ಸರಿಯಾಗಿ ಒದಗಿಸಿದೆ, ಅವರು 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 ಗಳು, ಕಂಪೈಲ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳು, ಸರಳ ಪಠ್ಯವಲ್ಲದ ಯಾವುದಾದರೂ — ಕೋಡ್ ಕಾನ್‌ಫ್ಲಿಕ್ಟ್‌ಗಳ ರೀತಿಯಲ್ಲಿ ಪರಿಹರಿಸಲಾಗುವುದಿಲ್ಲ. ತರ್ಕಿಸಲು ಯಾವುದೇ ಲೈನ್-ಬೈ-ಲೈನ್ ಡಿಫ್ ಇಲ್ಲ. ಕೇವಲ ಒಂದು ಆವೃತ್ತಿಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಆರಿಸಿಕೊಳ್ಳುವುದು ಮಾತ್ರ ನೈಜ ಆಯ್ಕೆಗಳು, ಅಥವಾ, ಎರಡು ಆವೃತ್ತಿಗಳು ವಾಸ್ತವವಾಗಿ ಇಮೇಜ್ ಮತ್ತು ಅದರ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಪ್ರತಿಯಂತಹ ಹೊಂದಾಣಿಕೆಯ ಜೋಡಿಯಾಗಿರುವಾಗ, ಸರಿಯಾದ ಮೂಲದಿಂದ ಪಡೆದ ಫೈಲ್ ಅನ್ನು ಮರುಸೃಷ್ಟಿಸುವುದು. ನೀವು ಯಾವ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಯುದ್ಧದ ಬಹುಪಾಲು ಭಾಗವಾಗಿದೆ.

ಅನುಕೂಲಗಳು

• ಪಡೆದ ಫೈಲ್ ಅನ್ನು ಮರುಸೃಷ್ಟಿಸುವುದು (ಈ ಸಂದರ್ಭದಲ್ಲಿ WebP) ಯಾವ ಕಡೆಯನ್ನು ನಂಬಬೇಕು ಎಂದು ಊಹಿಸುವ ಬದಲು ಸ್ಥಿರತೆಯನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ.
• ಅಪಾಯಕಾರಿಯಾಗಿ ಕಾಣುವ ಶಾರ್ಟ್‌ಕಟ್ ಅನ್ನು ನಂಬುವ ಮೊದಲು, ಪ್ರತ್ಯೇಕ ಬ್ರಾಂಚ್‌ನಲ್ಲಿ ಪರೀಕ್ಷಿಸುವುದು ತಪ್ಪು ಊಹೆಗಳನ್ನು ಸುಲಭವಾಗಿ ಹಿಡಿಯುತ್ತದೆ.
• ಮೂಲ ಫೈಲ್ ಫಾರ್ಮ್ಯಾಟ್ ಅನ್ನು ಫಾಲ್‌ಬ್ಯಾಕ್ ಆಗಿ ಇಟ್ಟುಕೊಳ್ಳುವುದು (ಇದರ ಮೂಲಕ <picture> ಎಲಿಮೆಂಟ್, ಈ ಸಂದರ್ಭದಲ್ಲಿ) ಅಂದರೆ ತಾತ್ಕಾಲಿಕವಾಗಿ ಮುರಿದ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಪ್ರತಿಯು ಕೂಡ ಸಂದರ್ಶಕರಿಗೆ ಪುಟವನ್ನು ಎಂದಿಗೂ ಸಂಪೂರ್ಣವಾಗಿ ಮುರಿಯುವುದಿಲ್ಲ.

ಅನಾನುಕೂಲಗಳು

• ಯಾವುದೇ ವೇಗದ ಆಯ್ಕೆಗಳು (pick-a-version, forced merge strategy, deleting and re-merging) ವಾಸ್ತವವಾಗಿ ಹೊಂದಿಕೆಯಾಗದ-ಜೋಡಿಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ — ಅವು ಕೇವಲ ಕಾನ್‌ಫ್ಲಿಕ್ಟ್ ಸಂದೇಶವನ್ನು ಕಣ್ಮರೆಯಾಗುವಂತೆ ಮಾಡುತ್ತವೆ.
• ಇದನ್ನು ಸರಿಯಾಗಿ ಸರಿಪಡಿಸಲು ನೇರ ಸರ್ವರ್ ಅಥವಾ ಕಮಾಂಡ್-ಲೈನ್ ಆಕ್ಸೆಸ್ ಮತ್ತು ಇಮೇಜ್-ಕನ್ವರ್ಶನ್ ಟೂಲ್ ಅಗತ್ಯವಿತ್ತು, ಇದು ಕೇವಲ ಬ್ರೌಸರ್ ಅಥವಾ ಡೆಸ್ಕ್‌ಟಾಪ್-ಅಪ್ಲಿಕೇಶನ್ ಮಾತ್ರ ಮಾಡುವ ವರ್ಕ್‌ಫ್ಲೋನ ಹೊರಗಿದೆ.
• ಮೂಲ ಕಾರಣ — ಸಾಮಾನ್ಯ ರಿವ್ಯೂ ಫ್ಲೋ ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡಿ, ಲೈವ್ ಬ್ರಾಂಚ್‌ಗೆ ನೇರ ಎಡಿಟ್ ಮಾಡುವುದು — ಇದು ಒಂದು-ಬಾರಿಯ ತಾಂತ್ರಿಕ ಪರಿಹಾರವು ಮತ್ತೆ ಸಂಭವಿಸುವುದನ್ನು ತಡೆಯದ ಪ್ರಕ್ರಿಯೆಯ ಅಂತರವಾಗಿದೆ.

ಎಚ್ಚರಿಕೆ

ಈ ಲೇಖನವು ಶೈಕ್ಷಣಿಕವಾಗಿದೆ ಮತ್ತು ಸಾಮಾನ್ಯ ಪರಿಭಾಷೆಯಲ್ಲಿ ನೈಜ ಪರಿಸ್ಥಿತಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ; ನಿರ್ದಿಷ್ಟ ಫೈಲ್ ಹೆಸರುಗಳು, ಪಾತ್‌ಗಳು ಮತ್ತು ಐಡೆಂಟಿಫೈಯರ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯೀಕರಿಸಲಾಗಿದೆ. ಇಲ್ಲಿ ತೋರಿಸಿರುವ ಕಮಾಂಡ್‌ಗಳು ನೈಜ ಫೈಲ್‌ಗಳು ಮತ್ತು ಬ್ರಾಂಚ್ ಇತಿಹಾಸವನ್ನು ಮಾರ್ಪಡಿಸಬಹುದು ಅಥವಾ ತ್ಯಜಿಸಬಹುದು — ಯಾವಾಗಲೂ ಮೊದಲು ಪ್ರತ್ಯೇಕ ಬ್ರಾಂಚ್ ಅಥವಾ ತ್ರೋವೇ ಪ್ರತಿಯಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ, ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ "ours" ಮತ್ತು "theirs" ಯಾವ ದಿಕ್ಕನ್ನು ಸೂಚಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಿ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ, ಮತ್ತು ಬಲವಂತವಾಗಿ ಕಾನ್‌ಫ್ಲಿಕ್ಟ್ ಅನ್ನು ಪರಿಹರಿಸುವ ಯಾವುದನ್ನಾದರೂ ರನ್ ಮಾಡುವ ಮೊದಲು ಬ್ಯಾಕ್ಅಪ್ ಅಥವಾ ಮರುಪಡೆಯುವ ಮಾರ್ಗವನ್ನು ನೀವು ಹೊಂದಿರುವಿರಾ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿ. ಯಾವುದೇ ಕಮಾಂಡ್ ಅನ್ನು ಅವಲಂಬಿಸುವ ಮೊದಲು ನಿಮ್ಮ ಸ್ವಂತ ರೆಪೊಸಿಟರಿಯ ನೈಜ ಸ್ಥಿತಿಯ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಿ.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

• 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