Git کے ساتھ شروع کرنا: نئے آنے والوں کے لیے ایک جامع گائیڈ

تعارف کے بجائے

ہیلو! آج ہم ایک ورژن کنٹرول سسٹم کے بارے میں بات کرنے جا رہے ہیں، یعنی Git۔ اگر آپ Git کو نہیں جانتے/سمجھتے ہیں تو آپ کا پروگرامنگ سے کوئی لینا دینا نہیں ہے۔ لیکن خوبصورتی یہ ہے کہ آپ کو مسلسل کام کرنے کے لیے Git کے تمام کمانڈز اور فیچرز کو اپنے سر میں رکھنے کی ضرورت نہیں ہے۔ آپ کو کمانڈز کا ایک سیٹ جاننے کی ضرورت ہے جو آپ کو ہر چیز کو سمجھنے میں مدد کرے گا جو ہو رہا ہے۔

گٹ کی بنیادی باتیں

گٹ ہمارے کوڈ کے لیے تقسیم شدہ ورژن کنٹرول سسٹم ہے۔ ہمیں اس کی ضرورت کیوں ہے؟ تقسیم شدہ ٹیموں کو اپنے کام کے انتظام کے لیے کسی قسم کے نظام کی ضرورت ہوتی ہے۔ وقت کے ساتھ رونما ہونے والی تبدیلیوں کو ٹریک کرنے کی ضرورت ہے۔ یعنی، ہمیں مرحلہ وار دیکھنے کے قابل ہونے کی ضرورت ہے کہ کون سی فائلیں بدلی ہیں اور کیسے۔ یہ خاص طور پر اہم ہے جب آپ اس بات کی تحقیقات کر رہے ہوں کہ کسی ایک کام کے تناظر میں کیا تبدیلی آئی ہے، تبدیلیوں کو واپس کرنا ممکن بناتا ہے۔

Git انسٹال کرنا

آئیے آپ کے کمپیوٹر پر جاوا انسٹال کریں۔

ونڈوز پر انسٹال کرنا

ہمیشہ کی طرح، آپ کو ایک exe فائل ڈاؤن لوڈ اور چلانے کی ضرورت ہے۔ یہاں سب کچھ آسان ہے: پہلے گوگل لنک پر کلک کریں ، انسٹال کریں، اور بس۔ ایسا کرنے کے لیے، ہم ونڈوز کے ذریعے فراہم کردہ باش کنسول استعمال کریں گے۔ ونڈوز پر، آپ کو گٹ باش چلانے کی ضرورت ہے۔ یہ اسٹارٹ مینو میں کیسا لگتا ہے: اب یہ ایک کمانڈ پرامپٹ ہے جس کے ساتھ آپ کام کر سکتے ہیں۔ Git کو کھولنے کے لیے ہر بار پروجیکٹ کے ساتھ فولڈر میں جانے سے بچنے کے لیے، آپ پروجیکٹ فولڈر میں کمانڈ پرامپٹ کو دائیں ماؤس بٹن کے ساتھ کھول سکتے ہیں جس راستے کی ہمیں ضرورت ہے:

لینکس پر انسٹال کرنا

عام طور پر گٹ لینکس کی تقسیم کا حصہ ہوتا ہے اور پہلے سے انسٹال ہوتا ہے، کیونکہ یہ ایک ایسا ٹول ہے جو اصل میں لینکس کرنل کی ترقی کے لیے لکھا گیا تھا۔ لیکن ایسے حالات ہوتے ہیں جب ایسا نہیں ہوتا۔ چیک کرنے کے لیے، آپ کو ٹرمینل کھول کر لکھنا ہوگا: git --version۔ اگر آپ کو ایک قابل فہم جواب ملتا ہے، تو کچھ بھی انسٹال کرنے کی ضرورت نہیں ہے. ٹرمینل کھولیں اور Ubuntu پر Git انسٹال کریں ۔ میں Ubuntu پر کام کر رہا ہوں، اس لیے میں آپ کو بتا سکتا ہوں کہ اس کے لیے کیا لکھنا ہے: sudo apt-get install git۔

macOS پر انسٹال کرنا

یہاں بھی، آپ کو پہلے یہ چیک کرنے کی ضرورت ہے کہ آیا Git پہلے سے موجود ہے۔ اگر آپ کے پاس یہ نہیں ہے، تو اسے حاصل کرنے کا سب سے آسان طریقہ یہ ہے کہ یہاں سے تازہ ترین ورژن ڈاؤن لوڈ کریں ۔ اگر Xcode انسٹال ہے، تو Git یقینی طور پر خود بخود انسٹال ہو جائے گا۔

گٹ کی ترتیبات

گٹ کے پاس اس صارف کے لیے صارف کی ترتیبات ہیں جو کام جمع کرائے گا۔ یہ سمجھ میں آتا ہے اور ضروری ہے، کیونکہ جب کمٹ بنایا جاتا ہے تو گٹ مصنف فیلڈ کے لیے یہ معلومات لیتا ہے۔ درج ذیل کمانڈز چلا کر اپنے تمام پروجیکٹس کے لیے صارف نام اور پاس ورڈ ترتیب دیں۔

git config --global user.name "Ivan Ivanov"
git config --global user.email ivan.ivanov@gmail.com

اگر آپ کو کسی مخصوص پروجیکٹ کے لیے مصنف کو تبدیل کرنے کی ضرورت ہے، تو آپ "--عالمی" کو ہٹا سکتے ہیں۔ یہ ہمیں مندرجہ ذیل دے گا:

git config user.name "Ivan Ivanov"
git config user.email ivan.ivanov@gmail.com

تھوڑا سا نظریہ...

موضوع میں غوطہ لگانے کے لیے، ہمیں آپ کو چند نئے الفاظ اور افعال سے متعارف کرانا چاہیے...

• گٹ ذخیرہ
• عزم
• شاخ
• ضم
• تنازعات
• کھینچنا
• دھکا
• کچھ فائلوں کو کیسے نظر انداز کریں (.gitignore)

اور اسی طرح.

گٹ میں سٹیٹس

گٹ کے کئی مجسمے ہیں جنہیں سمجھنے اور یاد رکھنے کی ضرورت ہے:

• ٹریک نہیں کیا گیا
• ترمیم شدہ
• اسٹیج کیا
• عزم

آپ کو یہ کیسے سمجھنا چاہئے؟

یہ وہ سٹیٹس ہیں جو ہمارے کوڈ پر مشتمل فائلوں پر لاگو ہوتے ہیں:

1. ایک فائل جو بنائی گئی ہے لیکن ابھی تک ذخیرہ میں شامل نہیں ہوئی ہے اس کی حیثیت "غیر ٹریک شدہ" ہے۔
2. جب ہم ان فائلوں میں تبدیلیاں کرتے ہیں جو پہلے ہی گٹ ریپوزٹری میں شامل کی جا چکی ہیں، تو ان کی حیثیت "تبدیل" ہو جاتی ہے۔
3. ہم نے جن فائلوں کو تبدیل کیا ہے ان میں سے، ہم ان کو منتخب کرتے ہیں جن کی ہمیں ضرورت ہے، اور ان کلاسوں کو "مرحلہ" کی حیثیت میں تبدیل کر دیا گیا ہے۔
4. مرحلہ وار حالت میں تیار فائلوں سے ایک کمٹ بنایا جاتا ہے اور گٹ ریپوزٹری میں جاتا ہے۔ اس کے بعد، "مرحلے" کی حیثیت کے ساتھ کوئی فائلیں نہیں ہیں. لیکن پھر بھی ایسی فائلیں ہو سکتی ہیں جن کی حیثیت "ترمیم شدہ" ہے۔

یہ اس کی طرح دکھتا ہے:

عہد کیا ہے؟

جب ورژن کنٹرول کی بات آتی ہے تو کمٹ اہم واقعہ ہوتا ہے۔ اس میں کمٹ شروع ہونے کے بعد کی گئی تمام تبدیلیاں شامل ہیں۔ کمٹ ایک ساتھ منسلک فہرست کی طرح جڑے ہوئے ہیں۔ مزید خاص طور پر: پہلا عہد ہے۔ جب دوسرا عہد بنتا ہے، تو یہ جانتا ہے کہ پہلے کے بعد کیا آتا ہے۔ اور اس طریقے سے معلومات کو ٹریک کیا جا سکتا ہے۔ ایک کمٹ کی اپنی معلومات بھی ہوتی ہیں، نام نہاد میٹا ڈیٹا:

• کمٹ کا منفرد شناخت کنندہ، جو اسے تلاش کرنے کے لیے استعمال کیا جا سکتا ہے۔
• کمٹ کے مصنف کا نام، جس نے اسے تخلیق کیا۔
• کمٹ کی تخلیق کی تاریخ
• ایک تبصرہ جو بیان کرتا ہے کہ کمٹ کے دوران کیا کیا گیا تھا۔

یہاں یہ کیسا لگتا ہے:

شاخ کیا ہے؟

ایک شاخ کچھ کمٹمنٹ کی طرف اشارہ کرتی ہے۔ کیونکہ ایک کمٹ جانتا ہے کہ کون سا کمٹ اس سے پہلے ہے، جب کوئی برانچ کسی کمٹ کی طرف اشارہ کرتی ہے تو وہ تمام پچھلی کمٹیں بھی اس پر لاگو ہوتی ہیں۔ اس کے مطابق، ہم یہ کہہ سکتے ہیں کہ آپ کے پاس جتنی شاخیں ہیں ایک ہی عہد کی طرف اشارہ کرنا چاہتے ہیں۔ کام شاخوں میں ہوتا ہے، اس لیے جب کوئی نیا کمٹ بنایا جاتا ہے، تو برانچ اپنے پوائنٹر کو حالیہ کمٹ کی طرف لے جاتی ہے۔

Git کے ساتھ شروع کرنا

آپ اکیلے مقامی ذخیرہ کے ساتھ ساتھ ریموٹ کے ساتھ بھی کام کر سکتے ہیں۔ مطلوبہ احکامات پر عمل کرنے کے لیے، آپ اپنے آپ کو مقامی ذخیرہ تک محدود کر سکتے ہیں۔ یہ صرف پراجیکٹ کی تمام معلومات مقامی طور پر .git فولڈر میں محفوظ کرتا ہے۔ اگر ہم ریموٹ ریپوزٹری کے بارے میں بات کر رہے ہیں، تو تمام معلومات ریموٹ سرور پر کہیں محفوظ ہوتی ہیں: پروجیکٹ کی صرف ایک کاپی مقامی طور پر محفوظ کی جاتی ہے۔ آپ کی مقامی کاپی میں کی گئی تبدیلیوں کو ریموٹ ریپوزٹری میں (گٹ پش) دھکیل دیا جا سکتا ہے۔ یہاں اور نیچے ہماری بحث میں، ہم کنسول میں گٹ کے ساتھ کام کرنے کے بارے میں بات کر رہے ہیں۔ بلاشبہ، آپ کسی قسم کا GUI پر مبنی حل استعمال کر سکتے ہیں (مثال کے طور پر IntelliJ IDEA)، لیکن پہلے آپ کو یہ معلوم کرنا چاہیے کہ کون سے کمانڈز پر عمل درآمد ہو رہا ہے اور ان کا کیا مطلب ہے۔

Git کے ساتھ مقامی ذخیرہ میں کام کرنا

اس کے بعد، میرا مشورہ ہے کہ آپ اس پر عمل کریں اور ان تمام اقدامات کو انجام دیں جو میں نے مضمون کو پڑھتے ہوئے کیے تھے۔ اس سے مواد کی آپ کی سمجھ اور مہارت میں بہتری آئے گی۔ ٹھیک ہے، بھوک! :) ایک مقامی ذخیرہ بنانے کے لیے، آپ کو لکھنا ہوگا:

git init

یہ کنسول کی موجودہ ڈائرکٹری میں ایک .git فولڈر بنائے گا۔ .git فولڈر گٹ ریپوزٹری کے بارے میں تمام معلومات محفوظ کرتا ہے۔ اسے حذف نہ کریں؛) اگلا، فائلوں کو پروجیکٹ میں شامل کیا جاتا ہے، اور انہیں "غیر ٹریک شدہ" کا درجہ دیا جاتا ہے۔ اپنے کام کی موجودہ حالت چیک کرنے کے لیے یہ لکھیں:

git status

ہم ماسٹر برانچ میں ہیں، اور ہم یہیں رہیں گے جب تک کہ ہم دوسری برانچ میں تبدیل نہیں ہو جاتے۔ یہ ظاہر کرتا ہے کہ کون سی فائلیں بدل گئی ہیں لیکن ابھی تک "مرحلہ" کی حیثیت میں شامل نہیں کی گئی ہیں۔ انہیں "اسٹیجڈ" اسٹیٹس میں شامل کرنے کے لیے، آپ کو "گٹ ایڈ" لکھنا ہوگا۔ ہمارے پاس یہاں کچھ اختیارات ہیں، مثال کے طور پر:

• git add -A - تمام فائلوں کو "مرحلہ" کی حیثیت میں شامل کریں۔
• git شامل کریں. - اس فولڈر اور تمام ذیلی فولڈرز سے تمام فائلیں شامل کریں۔ بنیادی طور پر، یہ پچھلے ایک کے طور پر ایک ہی ہے
• git add <file name> - ایک مخصوص فائل شامل کرتا ہے۔ یہاں آپ کچھ پیٹرن کے مطابق فائلوں کو شامل کرنے کے لیے ریگولر ایکسپریشن استعمال کر سکتے ہیں۔ مثال کے طور پر، git add *.java: اس کا مطلب ہے کہ آپ صرف جاوا ایکسٹینشن کے ساتھ فائلیں شامل کرنا چاہتے ہیں۔

پہلے دو اختیارات واضح طور پر آسان ہیں۔ تازہ ترین اضافے کے ساتھ چیزیں مزید دلچسپ ہوجاتی ہیں، تو آئیے لکھتے ہیں:

git add *.txt

اسٹیٹس چیک کرنے کے لیے، ہم پہلے سے معلوم کمانڈ استعمال کرتے ہیں:

git status

یہاں آپ دیکھ سکتے ہیں کہ ریگولر ایکسپریشن نے صحیح طریقے سے کام کیا ہے: test_resource.txt اب "مرحلہ" کی حیثیت رکھتا ہے۔ اور آخر کار، مقامی ریپوزٹری کے ساتھ کام کرنے کا آخری مرحلہ (ریموٹ ریپوزٹری کے ساتھ کام کرتے وقت ایک اور بھی ہوتا ہے ؛)) — ایک نیا عہد بنانا:

git commit -m "all txt files were added to the project"

برانچ پر کمٹ ہسٹری کو دیکھنے کے لئے اگلا ایک زبردست کمانڈ ہے۔ آئیے اس سے استفادہ کریں:

git log

یہاں آپ دیکھ سکتے ہیں کہ ہم نے اپنا پہلا کمٹ بنایا ہے اور اس میں وہ متن شامل ہے جو ہم نے کمانڈ لائن پر فراہم کیا تھا۔ یہ سمجھنا بہت ضروری ہے کہ اس متن کو ہر ممکن حد تک درست طریقے سے بیان کرنا چاہیے کہ اس عہد کے دوران کیا کیا گیا تھا۔ یہ مستقبل میں کئی بار ہماری مدد کرے گا۔ ایک متجسس قاری جو ابھی تک سو نہیں پایا ہے وہ سوچ رہا ہوگا کہ GitTest.java فائل کا کیا ہوا؟ آئیے ابھی معلوم کرتے ہیں۔ ایسا کرنے کے لئے، ہم استعمال کرتے ہیں:

git status

جیسا کہ آپ دیکھ سکتے ہیں، یہ اب بھی "untracked" ہے اور پروں میں انتظار کر رہا ہے۔ لیکن کیا ہوگا اگر ہم اسے بالکل بھی پروجیکٹ میں شامل نہیں کرنا چاہتے؟ کبھی کبھی ایسا ہوتا ہے۔ چیزوں کو مزید دلچسپ بنانے کے لیے، آئیے اب اپنی test_resource.txt فائل کو تبدیل کرنے کی کوشش کریں۔ آئیے وہاں کچھ متن شامل کریں اور اسٹیٹس چیک کریں:

git status

یہاں آپ واضح طور پر "غیر ٹریک شدہ" اور "ترمیم شدہ" سٹیٹس کے درمیان فرق دیکھ سکتے ہیں۔ GitTest.java "untracked" ہے، جبکہ test_resource.txt "تبدیل شدہ" ہے۔ اب جب کہ ہمارے پاس فائلیں ترمیم شدہ حالت میں ہیں، ہم ان میں کی گئی تبدیلیوں کا جائزہ لے سکتے ہیں۔ یہ مندرجہ ذیل کمانڈ کا استعمال کرتے ہوئے کیا جا سکتا ہے:

git diff

یعنی، آپ یہاں واضح طور پر دیکھ سکتے ہیں کہ میں نے اپنی ٹیکسٹ فائل میں کیا شامل کیا: ہیلو ورلڈ! آئیے ٹیکسٹ فائل میں اپنی تبدیلیاں شامل کریں اور ایک کمٹ بنائیں:

git add test_resource.txt
git commit -m "added hello word! to test_resource.txt"

تمام عہدوں کو دیکھنے کے لیے لکھیں:

git log

جیسا کہ آپ دیکھ سکتے ہیں، اب ہمارے پاس دو وعدے ہیں۔ ہم اسی طرح GitTest.java کو شامل کریں گے۔ یہاں کوئی تبصرہ نہیں، صرف حکم دیتا ہے:

git add GitTest.java
git commit -m "added GitTest.java"
git status

.gitignore کے ساتھ کام کرنا

واضح طور پر، ہم صرف ماخذ کوڈ کو اکیلے رکھنا چاہتے ہیں، اور کچھ نہیں، ذخیرہ میں۔ تو اور کیا ہو سکتا ہے؟ کم از کم، مرتب شدہ کلاسز اور/یا فائلیں جو ترقیاتی ماحول سے تیار ہوتی ہیں۔ گٹ کو ان کو نظر انداز کرنے کے لیے بتانے کے لیے، ہمیں ایک خاص فائل بنانے کی ضرورت ہے۔ یہ کریں: پروجیکٹ کی جڑ میں .gitignore نامی فائل بنائیں۔ اس فائل میں ہر لائن نظر انداز کرنے کے پیٹرن کی نمائندگی کرتی ہے۔ اس مثال میں، .gitignore فائل اس طرح نظر آئے گی:

```
*.class
target/
*.iml
.idea/
```

آئیے ایک نظر ڈالتے ہیں:

• پہلی لائن یہ ہے کہ کلاس ایکسٹینشن کے ساتھ تمام فائلوں کو نظر انداز کیا جائے۔
• دوسری لائن "ٹارگٹ" فولڈر اور اس میں موجود ہر چیز کو نظر انداز کرنا ہے۔
• تیسری لائن .iml ایکسٹینشن والی تمام فائلوں کو نظر انداز کرنا ہے۔
• چوتھی لائن .idea فولڈر کو نظر انداز کرنا ہے۔

آئیے ایک مثال استعمال کرنے کی کوشش کریں۔ یہ دیکھنے کے لیے کہ یہ کیسے کام کرتا ہے، آئیے مرتب کردہ GitTest.class کو پروجیکٹ میں شامل کریں اور پروجیکٹ کی حیثیت کو چیک کریں:

git status

واضح طور پر، ہم کسی طرح اتفاقی طور پر مرتب شدہ کلاس کو پروجیکٹ میں شامل نہیں کرنا چاہتے (گٹ ایڈ -A کا استعمال کرتے ہوئے)۔ ایسا کرنے کے لیے، ایک .gitignore فائل بنائیں اور ہر وہ چیز شامل کریں جو پہلے بیان کی گئی تھی: اب آئیے پروجیکٹ میں .gitignore فائل کو شامل کرنے کے لیے کمٹ کا استعمال کریں:

git add .gitignore
git commit -m "added .gitignore file"

اور اب سچائی کا لمحہ: ہمارے پاس ایک مرتب شدہ کلاس GitTest.class ہے جو "untracked" ہے، جسے ہم Git repository میں شامل نہیں کرنا چاہتے تھے۔ اب ہمیں .gitignore فائل کے اثرات دیکھنا چاہئے:

git status

کامل! gitignore +1 :)

شاخوں وغیرہ کے ساتھ کام کرنا

قدرتی طور پر، صرف ایک برانچ میں کام کرنا تنہا ڈویلپرز کے لیے تکلیف دہ ہے، اور جب ایک ٹیم میں ایک سے زیادہ افراد ہوں تو یہ ناممکن ہے۔ یہی وجہ ہے کہ ہماری شاخیں ہیں۔ جیسا کہ میں نے پہلے کہا، ایک شاخ صرف کمٹ کرنے کے لیے ایک متحرک پوائنٹر ہے۔ اس حصے میں، ہم مختلف برانچوں میں کام کرنے کا جائزہ لیں گے: تبدیلیوں کو ایک برانچ سے دوسری میں کیسے ضم کیا جائے، کیا تنازعات پیدا ہو سکتے ہیں، اور بہت کچھ۔ ذخیرہ میں موجود تمام شاخوں کی فہرست دیکھنے اور یہ سمجھنے کے لیے کہ آپ کس میں ہیں، آپ کو لکھنا ہوگا:

git branch -a

آپ دیکھ سکتے ہیں کہ ہمارے پاس صرف ایک ماسٹر برانچ ہے۔ اس کے سامنے والا ستارہ اشارہ کرتا ہے کہ ہم اس میں ہیں۔ ویسے، آپ یہ جاننے کے لیے "git status" کمانڈ بھی استعمال کر سکتے ہیں کہ ہم کس برانچ میں ہیں۔ پھر برانچز بنانے کے لیے کئی آپشنز ہیں (اور بھی ہو سکتے ہیں — یہ وہی ہیں جو میں استعمال کرتا ہوں):

• جس میں ہم ہیں اس کی بنیاد پر ایک نئی برانچ بنائیں (99% کیسز)
• ایک مخصوص عہد کی بنیاد پر ایک برانچ بنائیں (1% مقدمات)

آئیے ایک مخصوص عہد کی بنیاد پر ایک برانچ بنائیں

ہم کمٹ کے منفرد شناخت کنندہ پر بھروسہ کریں گے۔ اسے تلاش کرنے کے لیے ہم لکھتے ہیں:

git log

میں نے تبصرے کے ساتھ کمٹ کو اجاگر کیا ہے "شامل ہیلو ورلڈ..." اس کا منفرد شناخت کنندہ 6c44e53d06228f888f2f454d3cb8c1c976dd73f8 ہے۔ میں ایک "ترقی" برانچ بنانا چاہتا ہوں جو اس عہد سے شروع ہو۔ ایسا کرنے کے لیے، میں لکھتا ہوں:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

ماسٹر برانچ سے صرف پہلے دو کمٹ کے ساتھ ایک برانچ بنائی جاتی ہے۔ اس کی توثیق کرنے کے لیے، ہم سب سے پہلے اس بات کو یقینی بناتے ہیں کہ کسی مختلف برانچ میں جائیں اور وہاں کمٹ کی تعداد دیکھیں:

git status
git log

اور جیسا کہ توقع ہے، ہمارے پاس دو وعدے ہیں۔ ویسے، یہاں ایک دلچسپ بات ہے: اس برانچ میں ابھی تک کوئی .gitignore فائل موجود نہیں ہے، اس لیے ہماری مرتب کردہ فائل (GitTest.class) اب "untracked" اسٹیٹس کے ساتھ ہائی لائٹ ہو گئی ہے۔ اب ہم یہ لکھ کر اپنی شاخوں کا دوبارہ جائزہ لے سکتے ہیں:

git branch -a

آپ دیکھ سکتے ہیں کہ دو شاخیں ہیں: "ماسٹر" اور "ترقی"۔ ہم اس وقت ترقی میں ہیں۔

آئیے موجودہ کی بنیاد پر ایک برانچ بنائیں

برانچ بنانے کا دوسرا طریقہ یہ ہے کہ اسے کسی اور سے بنایا جائے۔ میں ماسٹر برانچ پر مبنی برانچ بنانا چاہتا ہوں۔ سب سے پہلے، مجھے اس پر سوئچ کرنے کی ضرورت ہے، اور اگلا مرحلہ ایک نیا بنانا ہے۔ آئیے ایک نظر ڈالتے ہیں:

• git checkout master — ماسٹر برانچ پر جائیں۔
• git status - تصدیق کریں کہ ہم اصل میں ماسٹر برانچ میں ہیں۔

یہاں آپ دیکھ سکتے ہیں کہ ہم نے ماسٹر برانچ میں سوئچ کیا ہے، .gitignore فائل اثر میں ہے، اور مرتب شدہ کلاس کو اب "untracked" کے طور پر نمایاں نہیں کیا گیا ہے۔ اب ہم ماسٹر برانچ کی بنیاد پر ایک نئی شاخ بناتے ہیں:

git checkout -b feature/update-txt-files

اگر آپ کو یقین نہیں ہے کہ آیا یہ برانچ "ماسٹر" جیسی ہے تو آپ آسانی سے "گٹ لاگ" کو عمل میں لا کر اور تمام وعدوں کو دیکھ کر چیک کر سکتے ہیں۔ ان میں سے چار ہونے چاہئیں۔

تنازعات کے حل

اس سے پہلے کہ ہم یہ دریافت کریں کہ تنازعہ کیا ہے، ہمیں ایک شاخ کو دوسری شاخ میں ضم کرنے کے بارے میں بات کرنے کی ضرورت ہے۔ اس تصویر میں ایک شاخ کو دوسری میں ضم کرنے کے عمل کو دکھایا گیا ہے: یہاں، ہماری ایک اہم شاخ ہے۔ کسی وقت، ایک ثانوی شاخ مرکزی شاخ سے دور بنائی جاتی ہے اور پھر اس میں ترمیم کی جاتی ہے۔ کام مکمل ہونے کے بعد، ہمیں ایک شاخ کو دوسری میں ضم کرنے کی ضرورت ہے۔ میں مختلف خصوصیات کو بیان نہیں کروں گا: اس مضمون میں، میں صرف ایک عام فہم بیان کرنا چاہتا ہوں۔ اگر آپ کو تفصیلات درکار ہوں تو آپ انہیں خود دیکھ سکتے ہیں۔ ہماری مثال میں، ہم نے فیچر/update-txt-files برانچ بنائی۔ جیسا کہ برانچ کے نام سے ظاہر ہوتا ہے، ہم متن کو اپ ڈیٹ کر رہے ہیں۔ اب ہمیں اس کام کے لیے ایک نیا عہد بنانا ہوگا:

git add *.txt 
git commit -m "updated txt files"
git log

اب، اگر ہم فیچر/update-txt-files برانچ کو ماسٹر میں ضم کرنا چاہتے ہیں، تو ہمیں ماسٹر پر جا کر "git merge feature/update-txt-files" لکھنا ہوگا۔

git checkout master
git merge feature/update-txt-files
git log

نتیجے کے طور پر، ماسٹر برانچ میں اب وہ کمٹ بھی شامل ہے جو فیچر/اپ ڈیٹ-txt-فائلز میں شامل کیا گیا تھا۔ یہ فعالیت شامل کی گئی تھی، لہذا آپ فیچر برانچ کو حذف کر سکتے ہیں۔ ایسا کرنے کے لیے، ہم لکھتے ہیں:

git branch -D feature/update-txt-files

اب تک سب کچھ واضح ہے، ہاں؟ آئیے صورتحال کو پیچیدہ بناتے ہیں: اب ہم کہتے ہیں کہ آپ کو txt فائل کو دوبارہ تبدیل کرنے کی ضرورت ہے۔ لیکن اب یہ فائل ماسٹر برانچ میں بھی تبدیل کر دی جائے گی۔ دوسرے الفاظ میں، یہ متوازی طور پر تبدیل ہو جائے گا. گٹ یہ نہیں جان سکے گا کہ جب ہم اپنے نئے کوڈ کو ماسٹر برانچ میں ضم کرنا چاہتے ہیں تو کیا کرنا ہے۔ چلو! ہم ماسٹر کی بنیاد پر ایک نئی شاخ بنائیں گے، text_resource.txt میں تبدیلیاں کریں گے، اور اس کام کے لیے کمٹمنٹ بنائیں گے۔

git checkout -b feature/add-header
... we make changes to the file

git add *.txt
git commit -m "added header to txt"

ماسٹر برانچ میں جائیں اور اس ٹیکسٹ فائل کو بھی اسی لائن پر اپ ڈیٹ کریں جیسا کہ فیچر برانچ میں ہے۔

git checkout master
… we updated test_resource.txt

git add test_resource.txt
git commit -m "added master header to txt"

اور اب سب سے دلچسپ نکتہ: ہمیں فیچر/ایڈ-ہیڈر برانچ سے ماسٹر میں تبدیلیاں ضم کرنے کی ضرورت ہے۔ ہم ماسٹر برانچ میں ہیں، لہذا ہمیں صرف لکھنے کی ضرورت ہے:

git merge feature/add-header

لیکن نتیجہ test_resource.txt فائل میں تصادم کی صورت میں نکلے گا: یہاں ہم دیکھ سکتے ہیں کہ گٹ خود فیصلہ نہیں کر سکا کہ اس کوڈ کو کیسے ملایا جائے۔ یہ ہمیں بتاتا ہے کہ ہمیں پہلے تنازعات کو حل کرنے کی ضرورت ہے، اور اس کے بعد ہی عزم کو انجام دینا ہے۔ ٹھیک ہے. ہم فائل کو ایک ٹیکسٹ ایڈیٹر میں تنازعہ کے ساتھ کھولتے ہیں اور دیکھتے ہیں: یہ سمجھنے کے لیے کہ گٹ نے یہاں کیا کیا، ہمیں یہ یاد رکھنا ہوگا کہ ہم نے کون سی تبدیلیاں اور کہاں کی ہیں، اور پھر موازنہ کریں:

1. ماسٹر برانچ میں جو تبدیلیاں اس لائن پر تھیں وہ "<<<<<<< HEAD" اور "=======" کے درمیان پائی جاتی ہیں۔
2. جو تبدیلیاں فیچر/add-header برانچ میں تھیں وہ "=======" اور ">>>>>> فیچر/add-header" کے درمیان پائی جاتی ہیں۔

اس طرح گٹ ہمیں بتاتا ہے کہ وہ یہ نہیں جان سکا کہ فائل میں اس مقام پر انضمام کو کیسے انجام دیا جائے۔ اس نے اس حصے کو مختلف شاخوں سے دو حصوں میں تقسیم کیا اور ہمیں انضمام کے تنازع کو خود حل کرنے کی دعوت دی۔ بہتر ہے. میں ڈھٹائی سے ہر چیز کو ہٹانے کا فیصلہ کرتا ہوں، صرف لفظ "ہیڈر" کو چھوڑ کر: آئیے تبدیلیوں کی حیثیت کو دیکھتے ہیں۔ تفصیل قدرے مختلف ہو گی۔ ایک "تبدیل شدہ" حیثیت کے بجائے، ہم نے "انضم" کر دیا ہے۔ تو کیا ہم پانچویں حیثیت کا ذکر کر سکتے تھے؟ مجھے نہیں لگتا کہ یہ ضروری ہے۔ چلو دیکھتے ہیں:

git status

ہم خود کو قائل کر سکتے ہیں کہ یہ ایک خاص، غیر معمولی معاملہ ہے۔ آئیے جاری رکھیں:

git add *.txt

آپ دیکھ سکتے ہیں کہ تفصیل صرف "گٹ کمٹ" لکھنے کی تجویز کرتی ہے۔ آئیے لکھنے کی کوشش کرتے ہیں:

git commit

اور بالکل اسی طرح، ہم نے یہ کیا - ہم نے کنسول میں تنازعہ کو حل کیا۔ بلاشبہ، مربوط ترقیاتی ماحول میں یہ قدرے آسانی سے کیا جا سکتا ہے۔ مثال کے طور پر، IntelliJ IDEA میں، ہر چیز اتنی اچھی طرح سے ترتیب دی گئی ہے کہ آپ اس کے اندر ہی تمام ضروری کارروائیاں کر سکتے ہیں۔ لیکن IDEs بہت ساری چیزیں "ہڈ کے نیچے" کرتے ہیں، اور ہم اکثر یہ نہیں سمجھتے کہ وہاں واقعی کیا ہو رہا ہے۔ اور جب سمجھ نہ ہو تو مسائل پیدا ہو سکتے ہیں۔

دور دراز کے ذخیروں کے ساتھ کام کرنا

آخری مرحلہ کچھ اور کمانڈز کا پتہ لگانا ہے جو ریموٹ ریپوزٹری کے ساتھ کام کرنے کے لیے درکار ہیں۔ جیسا کہ میں نے کہا، ریموٹ ریپوزٹری وہ جگہ ہوتی ہے جہاں ریپوزٹری کو محفوظ کیا جاتا ہے اور جہاں سے آپ اسے کلون کرسکتے ہیں۔ دور دراز کے ذخیرے کس قسم کے ہیں؟ مثالیں:

• GitHub ذخیرہ اندوزی اور تعاون پر مبنی ترقی کے لیے سب سے بڑا سٹوریج پلیٹ فارم ہے۔ میں نے پہلے ہی پچھلے مضامین میں اس کی وضاحت کی ہے۔
  مجھے GitHub پر فالو کریں ۔ میں اکثر ان علاقوں میں اپنا کام دکھاتا ہوں جہاں میں کام کے لیے پڑھ رہا ہوں۔

• GitLab اوپن سورس کے ساتھ DevOps لائف سائیکل کے لیے ایک ویب پر مبنی ٹول ہے ۔ یہ اپنے ویکی، بگ ٹریکنگ سسٹم ، CI/CD پائپ لائن، اور دیگر فنکشنز کے ساتھ کوڈ ریپوزٹری کے انتظام کے لیے گٹ پر مبنی نظام ہے۔ اس خبر کے بعد کہ مائیکروسافٹ نے گٹ ہب خریدا، کچھ ڈویلپرز نے اپنے پروجیکٹس کو گٹ لیب میں نقل کیا۔
  

• BitBucket مرکیوریل اور گٹ ورژن کنٹرول سسٹمز پر مبنی پروجیکٹ کی میزبانی اور باہمی تعاون کے لیے ایک ویب سروس ہے۔ ایک وقت میں اسے GitHub پر ایک بڑا فائدہ تھا کہ اس نے مفت نجی ذخیروں کی پیشکش کی تھی۔ پچھلے سال، GitHub نے بھی یہ صلاحیت سب کے لیے مفت میں متعارف کرائی تھی۔

• اور اسی طرح…

ریموٹ ریپوزٹری کے ساتھ کام کرتے وقت، سب سے پہلے پروجیکٹ کو اپنے مقامی ریپوزٹری میں کلون کرنا ہے۔ اس کے لیے میں نے اس پروجیکٹ کو ایکسپورٹ کیا جو ہم نے مقامی طور پر بنایا تھا، اور اب ہر کوئی اسے لکھ کر اپنے لیے کلون کر سکتا ہے:

git clone https://github.com/romankh3/git-demo

اب اس منصوبے کی مکمل مقامی کاپی موجود ہے۔ اس بات کا یقین کرنے کے لیے کہ پروجیکٹ کی مقامی کاپی تازہ ترین ہے، آپ کو لکھ کر پروجیکٹ کو کھینچنا ہوگا:

git pull

ہمارے معاملے میں، ریموٹ ریپوزٹری میں فی الحال کچھ بھی تبدیل نہیں ہوا ہے، لہذا جواب یہ ہے: پہلے سے ہی تازہ ترین۔ لیکن اگر میں ریموٹ ریپوزٹری میں کوئی تبدیلی کرتا ہوں، تو ہم ان کو کھینچنے کے بعد مقامی کو اپ ڈیٹ کر دیا جاتا ہے۔ اور آخر کار، آخری کمانڈ ڈیٹا کو ریموٹ ریپوزٹری میں دھکیلنا ہے۔ جب ہم نے مقامی طور پر کچھ کیا ہے اور اسے ریموٹ ریپوزٹری میں بھیجنا چاہتے ہیں، تو ہمیں پہلے مقامی طور پر ایک نیا عہد بنانا ہوگا۔ اس کو ظاہر کرنے کے لیے، آئیے اپنی ٹیکسٹ فائل میں کچھ اور شامل کریں: اب ہمارے لیے ایک عام چیز - ہم اس کام کے لیے ایک عہد بناتے ہیں:

git add test_resource.txt
git commit -m "prepared txt for pushing"

اسے ریموٹ ریپوزٹری میں دھکیلنے کا حکم ہے:

git push

ٹھیک ہے، میں صرف یہ کہنا چاہتا تھا. آپ کی توجہ کے لئے شکریہ. مجھے GitHub پر فالو کریں ، جہاں میں اپنے ذاتی مطالعہ اور کام سے متعلق مختلف عمدہ مثال کے پروجیکٹ پوسٹ کرتا ہوں۔

مفید لنک

• سرکاری گٹ دستاویزات ۔ میں اسے بطور حوالہ تجویز کرتا ہوں۔