گٹ کے ساتھ شروعات کرنا: ابتدائیوں کے لیے ایک تفصیلی گائیڈ

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

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

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

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

Git انسٹال کرنا

آئیے آپ کے کمپیوٹر پر Git انسٹال کریں۔ میں سمجھتا ہوں کہ ہر ایک کے پاس مختلف OS ہوتے ہیں، اس لیے میں کئی معاملات کے لیے بیان کرنے کی کوشش کروں گا۔

ونڈوز کے لیے انسٹالیشن

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

لینکس کے لیے انسٹالیشن

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

میک او ایس پر انسٹالیشن

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

گٹ سیٹ اپ

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

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

اگر کسی مخصوص پروجیکٹ کے لیے مصنف کو تبدیل کرنے کی ضرورت ہو (مثال کے طور پر ذاتی پروجیکٹ کے لیے)، تو آپ --global کو ہٹا سکتے ہیں، اور یہ کام کرے گا:

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

ایک چھوٹا سا نظریہ...

موضوع پر رہنے کے لیے اپنے پیغام میں چند نئے الفاظ اور اعمال شامل کرنے کا مشورہ دیا جاتا ہے... ورنہ بات کرنے کے لیے کچھ نہیں رہے گا۔ بلاشبہ، یہ کچھ لفظی اور انگریزی کی نقل ہے، لہذا میں انگریزی میں معنی شامل کروں گا۔ کیا قول اور فعل؟

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

اور اسی طرح.

Git میں ریاستیں۔

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

• ٹریک نہیں کیا گیا
• ترمیم شدہ
• تیار (مرحلہ)؛
• عزم

اس کا کیا مطلب ہے؟

یہ وہ ریاستیں ہیں جن میں ہمارے کوڈ کی فائلیں واقع ہیں۔ یعنی، ان کی زندگی کا راستہ عام طور پر اس طرح لگتا ہے:

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

ایسا لگتا ہے (سرکاری دستاویز سے تصویر، لہذا آپ اس پر بھروسہ کر سکتے ہیں)):

ایک عہد کیا ہے

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

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

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

شاخ کیا ہے؟

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

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

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

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

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

git init

یہ اس جگہ پر ایک .git فولڈر بنائے گا جہاں کنسول واقع ہے۔ .git ایک فولڈر ہے جو Git ذخیرہ کے بارے میں تمام معلومات کو محفوظ کرتا ہے۔ اسے حذف کرنے کی ضرورت نہیں ہے؛) اس کے بعد، اس پروجیکٹ میں فائلیں شامل کی جاتی ہیں، اور ان کی حیثیت Untracked ہوجاتی ہے۔ یہ دیکھنے کے لیے کہ کام کی موجودہ حیثیت کیا ہے، لکھیں:

git status

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

• git add -A - اسٹیج شدہ حالت سے تمام فائلیں شامل کریں۔
• git شامل کریں. - اس فولڈر سے تمام فائلیں اور تمام اندرونی فائلیں شامل کریں۔ بنیادی طور پر پچھلے جیسا ہی؛
• git add <filename> - صرف ایک مخصوص فائل کو شامل کرتا ہے۔ یہاں آپ کچھ پیٹرن کے مطابق شامل کرنے کے لیے ریگولر ایکسپریشن استعمال کر سکتے ہیں۔ مثال کے طور پر، 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

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

git status

یہاں آپ واضح طور پر دونوں ریاستوں کے درمیان فرق دیکھ سکتے ہیں - untracked اور modified۔ GitTest.java غیر ٹریک شدہ حالت میں ہے اور 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 کہتے ہیں، اور اس فائل میں ہر لائن کو نظر انداز کرنے کا نمونہ ہوگا۔ اس مثال میں، git ignore اس طرح نظر آئے گا:

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

آئیے اب دیکھتے ہیں:

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

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

git status

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

git add .gitignore
git commit -m “added .gitignore file”

اور اب سچائی کا لمحہ: ہمارے پاس ایک مرتب شدہ GitTest.class کلاس ہے جس کا سراغ نہیں لگایا گیا ہے، جسے ہم Git ذخیرہ میں شامل نہیں کرنا چاہتے تھے۔ یہ وہ جگہ ہے جہاں git ignore کو کام کرنا چاہئے:

git status

سب کچھ واضح ہے) Git ignore +1)

شاخوں اور اس طرح کے ساتھ کام کرنا

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

git branch -a

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

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

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

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

git log

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

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

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

git status
git log

اور یہ سچ ہے: یہ پتہ چلا کہ ہمارے پاس دو وعدے ہیں۔ ویسے، ایک دلچسپ بات: اس برانچ میں ابھی تک کوئی .gitignore فائل موجود نہیں ہے، اس لیے ہماری مرتب کردہ فائل (GitTest.class) اب غیر ٹریک شدہ حالت میں نمایاں ہے۔ اب ہم اپنی شاخوں کو دوبارہ لکھ کر نظر ثانی کر سکتے ہیں:

git branch -a

یہ دیکھا جا سکتا ہے کہ دو شاخیں ہیں - ماسٹر اور ترقی - اور اب ہم ترقی پر ہیں.

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

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

• git checkout master - ماسٹر برانچ میں جائیں؛
• گٹ اسٹیٹس - چیک کریں کہ آیا یہ ماسٹر پر ہے۔

یہاں آپ دیکھ سکتے ہیں کہ ہم ماسٹر برانچ میں چلے گئے ہیں، git ignore پہلے سے ہی یہاں کام کر رہا ہے، اور مرتب شدہ کلاس اب غیر ٹریک شدہ کے طور پر ظاہر نہیں ہوتی ہے۔ اب ہم ماسٹر برانچ کی بنیاد پر ایک نئی شاخ بناتے ہیں:

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 فائل کو دوبارہ تبدیل کرنے کی ضرورت ہے۔ لیکن اب یہ فائل بھی وزرڈ میں تبدیل ہو جائے گی۔ یعنی، یہ متوازی طور پر تبدیل ہو جائے گا، اور Git یہ نہیں سمجھ سکے گا کہ ایسی صورت حال میں کیا کرنے کی ضرورت ہے جب ہم نئے کوڈ کو ماسٹر برانچ میں ضم کرنا چاہتے ہیں۔ جاؤ! ہم ماسٹر کی بنیاد پر ایک نئی برانچ بناتے ہیں، text_resource.txt میں تبدیلیاں کرتے ہیں اور اس معاملے کے لیے ایک عہد بناتے ہیں:

git checkout -b feature/add-header
... делаем изменения в файле

git add *.txt
git commit -m “added header to txt”

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

git checkout master
… обновor test_resource.txt

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

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

git merge feature/add-header

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

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

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

git status

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

git add *.txt

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

git commit

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

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

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

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

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

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

• اور اسی طرح…

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

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

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

git pull

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

git add test_resource.txt
git commit -m “prepated txt for pushing”

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

git push

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

مفید لنکس

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