ଆମେ କିପରି ଏକ Git Image Merge Conflict କୁ ସମାଧାନ କଲୁ (ଏବଂ କାହିଁକି GitHub ର Website କରିପାରିଲା ନାହିଁ)

କୋଡ୍ ରେ Merge conflict ଗୁଡିକ ବହୁତ ବିରକ୍ତିକର। ଯେତେବେଳେ ସେଗୁଡିକ ଏକ ପ୍ରତିଛବି ଫାଇଲରେ ଘଟେ, ଅଧିକାଂଶ ଲୋକ ସ୍ଥବିର ହୋଇଯାଆନ୍ତି — ଏକ ଚିତ୍ର ପାଇଁ କୌଣସି "diff view" ନାହିଁ, ଏବଂ GitHub ରେ ସାଧାରଣ fix-it-in-the-browser ବଟନ୍ ସେଠାରେ ନାହିଁ। ଏହି ପୋଷ୍ଟ ଠିକ୍ ସେହିପରି ଏକ ବାସ୍ତବ ଘଟଣା ଦେଇ ଗତି କରେ: କ'ଣ କାମ କଲା ନାହିଁ, ଏବଂ କ'ଣ କଲା।

ଆଜି, ଅଗଷ୍ଟ 29, 2026 ସୁଦ୍ଧା, ଏହା ବୁଝିବା ଉଚିତ୍ କାରଣ ଅଧିକ ଛୋଟ ଟିମ୍ ଗୁଡିକ Git ମାଧ୍ୟମରେ ବିଷୟବସ୍ତୁ-ଭାରୀ ୱେବସାଇଟ୍ ଗୁଡିକ ଚଳାନ୍ତି, ଅଣ-ଟେକ୍ନିକାଲ ଲୋକମାନେ ଏକ ଡେସ୍କଟପ୍ ଆପ୍ ମାଧ୍ୟମରେ ଟେକ୍ସଟ୍ ଏବଂ ଇମେଜ୍ ପରିବର୍ତ୍ତନଗୁଡିକୁ ପୁସ୍ କରନ୍ତି। ସେହି ମିଶ୍ରଣ — ସାଧାରଣ-ଭାଷା କଣ୍ଟେଣ୍ଟ ସମ୍ପାଦକ, ବାଇନାରୀ ଫାଇଲ୍ ଏବଂ ଏକ ବାସ୍ତବ ଡିପ୍ଲଏ ପାଇପଲାଇନ୍ — ଠିକ୍ ସେହି ସ୍ଥାନ ଯେଉଁଠାରେ ଏହି ସମସ୍ୟା ଦେଖାଯାଏ।

ସେଟଅପ୍: ଦୁଇଟି ବ୍ରାଞ୍ଚ୍, ଗୋଟିଏ ସେୟାର୍ ହୋଇଥିବା ପ୍ରତିଛବି

ପ୍ରୋଜେକ୍ଟ ଏକ ସରଳ ଦୁଇ-ବ୍ରାଞ୍ଚ୍ ୱର୍କଫ୍ଲୋ ବ୍ୟବହାର କରେ। staging ହେଉଛି ଯେଉଁଠାରେ ଦୈନନ୍ଦିନ କାମ ହୁଏ — ଜଣେ କଣ୍ଟେଣ୍ଟ ସମ୍ପାଦକ ସେଠାରେ ସ୍ୱାଧୀନ ଭାବରେ ପରିବର୍ତ୍ତନଗୁଡିକୁ ପୁସ୍ କରନ୍ତି, ଏବଂ ଏହା ସ୍ୱୟଂଚାଳିତ ଭାବରେ ଏକ ପ୍ରିଭ୍ୟୁ ସାଇଟ୍ ରେ ଡିପ୍ଲଏ ହୁଏ। main ହେଉଛି ପ୍ରକୃତ ଲାଇଭ୍ ସାଇଟ୍, ଯାହା କେବଳ ସେତେବେଳେ ଅପଡେଟ୍ ହୁଏ ଯେତେବେଳେ staging ରୁ ଏକ ରିଭ୍ୟୁ କରାଯାଇଥିବା Pull Request ମର୍ଜ କରାଯାଏ।

ଏହି ଟିମ୍ ନିକଟରେ ସାଇଟର ପ୍ରତିଛବିଗୁଡ଼ିକୁ WebP କୁ ମଧ୍ୟ ରୂପାନ୍ତର କରିଥିଲା, ଏକ ଆଧୁନିକ ଫର୍ମାଟ୍ ଯାହା ସମାନ ଦୃଶ୍ୟମାନ ଗୁଣବତ୍ତାରେ PNG କିମ୍ବା JPG ଠାରୁ ବହୁତ ଛୋଟ। ପ୍ରତ୍ୟେକ ପ୍ରତିଛବି ବର୍ତ୍ତମାନ ଏକ ଯୋଡି ଭାବରେ ବିଦ୍ୟମାନ: ମୂଳ .png, ଏବଂ ଏକ ମେଳ ଖାଉଥିବା .webp, ଏକ HTML <picture> ଏଲିମେଣ୍ଟ ସହିତ ଏକତ୍ର ତାର କରାଯାଇଛି ଯାହାଫଳରେ WebP-ସକ୍ଷମ ବ୍ରାଉଜର୍ ଗୁଡିକ ଛୋଟ ଫାଇଲ୍ କୁ ସ୍ୱୟଂଚାଳିତ ଭାବରେ ପାଆନ୍ତି, ଅନ୍ୟ ସମସ୍ତ ଜିନିଷ ମୂଳକୁ ଫେରିଯାଏ।

ତାପରେ ପ୍ରାୟ ଏକାସମୟରେ ଦୁଇଟି ଭିନ୍ନ ବ୍ରାଞ୍ଚ୍ ରେ ଦୁଇଟି ଜିନିଷ ଘଟିଲା: କେହି ଜଣେ mainରେ ଗୋଟିଏ ପ୍ରଡକ୍ଟ ସ୍କ୍ରିନସଟ୍ ରେ ଏକ ଛୋଟ, ସିଧାସଳଖ ଏଡିଟ୍ କଲେ, ସାଧାରଣ ରିଭ୍ୟୁ ଫ୍ଲୋ କୁ ଏଡ଼ାଇ, ଯେତେବେଳେ କଣ୍ଟେଣ୍ଟ ସମ୍ପାଦକ ପୃଥକ ଭାବରେ stagingମାଧ୍ୟମରେ ସେହି ସମାନ ସ୍କ୍ରିନସଟ୍ ର ଏକ ପ୍ରକୃତ ନୂଆ ସଂସ୍କରଣ ଅପଲୋଡ୍ କଲେ। ଉଭୟ ଏଡିଟ୍ ସମାନ ଫାଇଲ୍ ପାଥ୍ କୁ ସ୍ପର୍ଶ କଲା। ଉଭୟ ପକ୍ଷ ପରସ୍ପର ବିଷୟରେ ଜାଣି ନଥିଲେ।

GitHub ର ୱେବସାଇଟ୍ କାହିଁକି ଏହାକୁ ଠିକ୍ କରିପାରିଲା ନାହିଁ

ଯେତେବେଳେ କଣ୍ଟେଣ୍ଟ ସମ୍ପାଦକ staging ଅପଡେଟ୍ କୁ mainକୁ ଆଣିବା ପାଇଁ ଏକ Pull Request ଖୋଲିଲେ, 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

ଏହା ଦର୍ଶାଇଲା ଯେ ଶେଷ ଥର ସେୟାର ହେବା ପରଠାରୁ ଉଭୟ ବ୍ରାଞ୍ଚ୍ ଫାଇଲକୁ ସ୍ୱାଧୀନ ଭାବରେ ପରିବର୍ତ୍ତନ କରିଛନ୍ତି — ଏକ ପ୍ରକୃତ three-way divergence, କେବଳ "ଗୋଟିଏ ପକ୍ଷ ନୂଆ" ନୁହେଁ।

ପଦକ୍ଷେପ 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