جشن کریسمس در کشورهای مختلف

تیم سرگرمی پارس دان

جشن کریسمس در کشورهای مختلف

خبرآنلاین: کریسمس جشنی است که سالانه به علت میلاد مسیح میان همه کشور های مسیحی گرفته می شود و میلیارد ها نفر در آن شرکت می کنند.

به علت اینکه زمان دقیق تولد مسیح معلوم نیست، کلیساها به طور توافقی کریسمس را روز ۲۵ دسامبر اعلام کرده اند، اما این جشن در بعضی کلیسا ها ۷ یا ۸ ژانویه گرفته می شود.

اما به جز اینکه در زمان این جشن تفاوت هایی وجود دارد، در نحوه برقراری آن هم تفاوت هایی وجود دارد؛ در نحوه کادو دادن، در اندازه درخت، شام شب کریسمس و …

بابا نوئل، پدر کریسمس یا سنت نیکولاس؟

 در هر کشوری چهره‌های اسطوره ای متفاوتی هدیه کریسمس را می آورند، این فرد در اکثر کشورها بابانوئل است ولی در بعضی کشورها این فرد افسانه ای فرق دارد برای مثال در لهستان و اکراین هدیه را سنت نیکولاس می آورد. سنت نیکولاس یکی از مسیحیان ۴ قرن پس از میلاد بوده است.

به طور کلی سه فرد افسانه ای این هدیه ها را می آورند؛ بابانوئل، سنت نیکولاس و پدر کریسمس.

سلیقه در درخت کریسمس

در درخت کریسمس نیز میان کشور های اروپایی تفاوت های بسیار زیادی وجود دارد.

یک تولید کننده درخت کریسمس در دانمارک می‌گوید: فرانسوی ها درخت کوچکتر را ترجیح می دهند. اما هلندی ها و دانمارکی ها درختی دوست دارند که فضاهای کافی بین شاخه های آن باشد تا بتوانند تزئینات بیشتری را بین آنها جای دهند.

مردم روسیه هم برخلاف بیشتر کشورهای اروپایی، عموما درخت های بلند و بزرگ را می پسندند.

به طور سنتی در روز کریسمس چه چیزی خورده می شود؟

انگلیس؛ شام روز کریسمس در این کشور اغلب بوقلمون در کنار سیب زمینی کباب شده و سبزیجات است، دسر هم اغلب «پودینگ کریسمس»، پای گوشت با خامه یا کاستارد و کیک کریسمس است.

فرانسه؛ ماهی دودی، اسکالپ، صدف و حلزون از پیش غذاهای محبوب فرانسه برای روز کریسمس است. اینکه بخواهید روز کریسمس در فرانسه گیاه خوار باشید، کار بسیار سختی است، غذای اصلی معمولا از گوشت است. این گوشت یا گوشت بوقلمون و یا گوشت غاز است.

دسر هم بیشتر کیکی پر از شکلات، کره یا خامه است.

آلمان؛ آلمانی ها معمولا در روز کریسمس غذای سبکی را انتخاب می کنند، تا فعالیتشان در روز های بعدی کم نشود. آن ها اکثرا در روز کریسمس سوسیس و سالاد سیب زمینی می خورند. در دو روز بعدی که آلمان ها به بازدید خانواده شان می روند، غذاهای بهتری می خورند!

مجارستان؛ در این کشور، سوپ و مرغ غذای اصلی است. برای دسر هم مجارستانی ها دانه های خشخاش و آجیل می خورند. طبق افسانه ها این غذاها برای آنها پول، خوش شانسی و شادی می آورد.

ایتالیا؛ منوی روز ۲۴ دسامبر: سالاد اختپوس، نوعی اسپاگتی با ماهی، ماهی خاردار، ماهی سرخ شده در روغن، مارماهی سرخ شده و نوعی سالاد ایتالیایی. همچنین دسر های مختلفی در مناطق مختلف ایتالیا سرو می شود.

اسپانیا؛ در آخرین شب سال در این کشور شما مجبور هستید به ازای هر ساعت انگوری بخورید، در روزی هم که کادو ها داده می شود (۶ ژانویه) مردم اسپانیا کیک می خورند.

ترکیه؛ غذا مخصوص در شب سال نو این کشور بوقلمون است.

جشن کریسمس در کشورهای مختلف

آموزش مقدماتی کار با گیت و گیت‌هاب

گروه دانش و فناوری پارس دان

آموزش مقدماتی کار با گیت و گیت‌هاب

اگر به عنوان کاربر اندروید حداقل یک بار سراغ رام‌های کاستوم رفته باشید، محال ممکن است نام گیت‌هاب (Github) را ندیده باشید. تقریبا تمام توسعه‌دهندگان اندروید از این سرویس برای انتشار منابع پروژه‌های خود استفاده می‌کنند؛ اما بسیاری از کاربران در مواجهه با گیت‌هاب، بخش‌ها و اصطلاحات آن سردرگم می‌شوند. در این مقاله به چیستی گیت، گیت‌هاب و نحوه‌ی کار با آن‌ها می‌پردازیم.

اسم گیت‌هاب از دو بخش گیت و هاب تشکیل شده است. در زیر هرکدام را به صورت جداگانه بررسی می‌کنیم.

گیت در گیت‌هاب

برای فهم گیت‌هاب، ابتدا باید با گیت آشنا شویم. گیت یک سیستم کنترل نسخه‌ی متن‌باز است که توسط خالق لینوکس، لینوس تروالدز (Linus Trovalds)، ساخته شد. گیت مانند سایر سیستم‌های کنترل نسخه از قبیل ساب‌ورژن، CVS و مرکوریال است؛ اما اساسا سیستم کنترل نسخه چیست؟ وقتی توسعه‌دهندگان چیز جدیدی مانند یک اپلیکیشن خلق می‌کنند، مدام تغییراتی را در کدهای آن می‌دهند تا اولین نسخه‌ی رسمی و غیربتا آماده‌ی انتشار شود. این روند در به‌روزرسانی برای نسخه‌های بعدی نیز ادامه دارد.

سیستم‌های کنترل نسخه تغییرات و بازنگری‌های توسعه‌دهندگان را در یک مخزن مرکزی ذخیره می‌کنند. با این کار همکاری بین توسعه‌دهندگان آسان می‌شود؛ به این شکل که هر توسعه‌دهنده می‌تواند نسخه‌ی جدید را دانلود کرده، تغییرات را در آن اعمال و سپس آپلود کند. کلیه‌ی توسعه‌دهندگان قادر به مشاهده‌ی تغییرات جدید، دانلود آن‌ها و مشارکت در پروژه خواهند بود.

مقاله‌های مرتبط:

همچنین، کسانی که نقشی در پروژه ندارند، می‌توانند فایل‌های آن را دانلود و استفاده کنند. کاربران حرفه‌ای لینوکس احتمالا با این روند آشنایی کامل دارند؛ چرا که استفاده از گیت، ساب‌ورژن و سرویس‌های مشابه از ملزومات کامپایل کردن یک برنامه از سورس‌کد آن است.

هاب در گیت‌هاب، سیستم کنترل نسخه‌ای است که توسط اکثر توسعه‌دهندگان ترجیح داده می‌شود؛ زیرا نسبت به سایر سیستم‌ها برتری‌هایی دارد. مثلا در ذخیره‌ی تغییرات فایل‌ها بهتر عمل می‌کند. در بخش‌های بعدی این مقاله به نحوه‌ی کار با گیت خواهیم پرداخت.

در دنیای رایانه، هاب به تجهیزات سخت‌افزاری گفته می‌شود که از آن اشتراک‌گذاری شبکه با گجت‌های مختلف استفاده می‌شود و در نتیجه هاب به نوعی شبکه را گسترش می‌دهد. هاب در گیت‌هاب نیز چنین مفهومی دارد. توسعه‌دهندگان پروژه‌های خود را در گیت‌هاب ذخیره می‌کنند و از این طریق به شبکه‌ی عظیم توسعه‌دهندگان دنیا وصل می‌شوند. در گیت‌هاب این امکان وجود دارد که پروژه‌ای را از مخزن توسعه‌دهنده به مخزن خود کپی کنید و در آن تغییرات اعمال کنید و سپس درخواست اعمال تغییرات را به صاحب پروژه بفرستید تا در پروژه‌ی اصلی اعمال کند. امکان پرسش و پاسخ نیز در این شبکه‌ی گیت فراهم است.

حالا که با مفاهیم گیت و گیت‌هاب آشنا شدیم به نحوه‌ی کار با این سرویس‌ها می‌پردازیم.

آموزش کار با گیت

نیازهای بنیادی

قبل از هرچیز لازم است مواردی را نصب کنید. برای این‌کار نسخه‌ی متناسب با سیستم‌عامل خود را از اینجا دانلود کرده و نصب کنید. اگر از لینوکس استفاده می‌کنید، از طریق پکیج منیجر نیز می‌توانید اقدام کنید.

در مرحله‌ی بعد، از آن‌جایی که در روند آموزش، یک مخزن شامل یک کد و یک README خواهیم ساخت، یک دایرکتوری برای آن در نظر بگیرید.

پس از آن، به عملیات معمولی نظیر init، کلون، کامیت و diff می‌پردازیم. البته، عملیات پیشرفته‌تری نیز وجود دارد که در مراحل اولیه نیازی به آن‌ها نخواهید داشت.

راه‌اندازی یک مخزن (Repository)

قبل از شروع کار با گیت، باید یک مخزن پروژه راه‌اندازی کنید تا به کمک گیت آن را مدیریت کنید. ترمینال را باز کنید و در دایرکتوری پروژه‌ی خود دستور . git init را وارد کنید.

با این کار یک دایرکتوری مخفی با نام git. در دایرکتوری پروژه‌ی شما ساخته خواهد شد. این دایرکتوری همان مسیری است که گیت دیتابیس و تنظیمات خود را در آن ذخیره می‌کند تا تغییرات پروژه‌ی شما را دنبال کند.

کلون یا کپی کردن یک مخزن

راه دیگری برای دسترسی به مخزن وجود دارد که به کلونینگ مشهور است. درست مثل بررسی مخزن در سایر سیستم‌ها، اجرای کد git clone <repository URL> یک کپی کامل از مخزن مورد نظر به سیستم شما منتقل خواهد کرد. سپس، می‌توانید روی آن کار کرده و تغییرات دلخواه را در آن اعمال کنید. روند اعمال تغییرات ساخت تغییرات، اعمال موقت آن‌ها بدون وارد کردن در مخزن اصلی (staging)، اعمال تغییر در مخزن یا کامیت (commit) را شامل می‌شود.

افزودن فایل جدید

در این مرحله می‌توان از زبان‌های برنامه‌نویسی مختلف مانند پایتون، روبی، Go یا هر زبان دیگری استفاده کرد. ما در این آموزش از زبان php که معمول‌تر است استفاده می‌کنیم. فایلی به نام index.php را در دایرکتوری خود ایجاد کنید و کد زیر را در آن وارد کنید.

;?php print "Hello World";

بعد از ذخیره‌ی فایل، دستور git status را از ترمینال اجرا کنید. این دستور وضعیت حاضر مخزن کار شما را نشان می‌دهد. نتیجه‌ی به نمایش درآمده باید مشابه تصویر زیر باشد که در آن index.php به عنوان یک فایل untracked یا بررسی‌نشده فهرست شده است.

حالا طرز کار با چند فایل بدون اعمال تغییرات در مخزن را بررسی می‌کنیم. برای این‌کار یک فایل دوم به نام README.md بسازید. در این فایل جزئیاتی مثل نام پروژه، نام و نشانی ایمیل خود را وارد کنید. دستور git status را مجددا اجرا کنید. خواهید دید که این‌بار دو فایل به عنوان بررسی‌نشده فهرست شده‌اند.

حالا می‌خواهیم index.php را به اصطلاح استیج (stage) کنیم. فایلی که استیج می‌شود یعنی تغییرات آن انجام گرفته اما هنوز در مخزن اصلی اعمال نشده است. برای این‌کار دستور git add index.php را وارد کنید. حالا، دستور وضعیت گیت (git status) را مجددا اجرا کنید. خواهید دید که index.php به عنوان فایلی جدید در بخش تغییرات در انتظار اعمال (changes to be commited) فهرست شده و README.md در همان بخش Untracked files قرار دارد.

تنظیمات

در این مرحله همه‌چیز آماده‌ی اعمال تغییرات یا commit است؛ اما قبل از این‌کار باید با تنظیمات ویرایشگر که گیت هنگام نوشتن پیام‌های کامیت مورد استفاده قرار می‌دهد آشنا شوید.

اگر از لینوکس استفاده می‌کنید گیت به طور پیش‌فرض، از برنامه‌‌هایی مانند pico، vi، vim یا emacs استفاده خواهد کرد. اگر با این برنامه‌ها آشنایی ندارید، ممکن است بخواهید آن‌ها را با نرم‌افزاری مثل Notepad، TextEdit یا Gedit عوض کنید. برای این‌کار دستور زیر را از ترمینال اجرا کنید:

git config --global core.editor <your app's name

در قسمت آخر کد به جای your app’s name نام نرم‌افزار مورد نظر خود را وارد کنید.

تنظیمات دیگری مانند تغییر نام و ایمیل و چگونگی نمایش پیام کامیت نیز قابل انجام است. ما در این آموزش از vim به عنوان ادیتور استفاده می‌کنیم؛ اما شما می‌توانید انتخاب متفاوت خود را داشته باشید.

اعمال اولین تغییر

کامیت در گیت شباهت بسیار زیادی با کامیت در سایر سیستم‌های کنترل نسخه مانند ساب‌ورژن دارد. روند کار به این شکل است که کار را آغاز می‌کنید و پیامی جهت توضیح اینکه دلیل تغییر انجام گرفته چیست وارد می‌کنید و فایل تغییر می‌یابد. پس دستور git commit را اجرا کنید. با این کار ویرایشگر به صورت خودکار باز می‌شود و الگوی زیر را نمایش می‌دهد.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
#
# Initial commit
#
# Changes to be committed:
# new file: index.php
#
# Untracked files:
# README.md
#

با بررسی مداوم وضعیت تغییرات اعمال شده توسط دستور git status از شرایط مخزن خود آگاهی پیدا خواهید کرد. با این‌کار همواره خواهید دانست که چه تغییری را اعمال کرده و چه تغییری را هنوز اعمال نکرده‌اید. در مورد پیام مرتبط با کامیت باید گفت یک پیام کامیت خوب باید شامل دو بخش باشد؛ اول این‌که کوتاه و در حد ۷۲ کاراکتر باشد و به طور خلاصه تغییر اعمال شده را اعلام کند. دیگر این‌که دارای توضیحی بلندتر باشد که به طور مجزا در سطری دیگر جزئیات تغییر اعمال‌شده را توضیح دهد. البته مورد دوم اختیاری بوده و الزامی برای نوشتن آن وجود ندارد.

ما در این مرحله نیاز به نوشتن توضیح پیچیده‌ای نداریم؛ چرا که تنها یک فایل را به مخزن اضافه کرده‌ایم؛ اما چنان‌چه تغییری که اعمال می‌کنید دارای الگوریتم‌های پیچیده‌ای باشد، لازم است توضیحاتی را در این بخش برای مطالعه‌ی سایر توسعه‌دهندگان بنویسید و آن‌ها را از چرایی اعمال این تغییر توسط شما آگاه سازید. بنابراین، پیام ساده‌ی زیر را در ویرایشگر وارد کرده، ذخیره کنید و خارج شوید.

“Adding the core script file to the repository”

حالا که تغییرات اعمال شدند. وضعیت گیت را مجددا بررسی کنید. خواهید دید که REDME.md همچنان در قسمت untracked قرار دارد.

مشاهده‌ی تغییرات

در این مرحله از آن‌جایی که چند فایل در قسمت کنترل نسخه داریم و با دستورهای پایه آشنا شده‌ایم، به بررسی تغییرات می‌پردازیم. برای بررسی تغییرات اعمال شده در یک فایل از دستور git diff استفاده می‌کنیم. این دستور مشابه دستور Linux diff دو فایل را با هم مقایسه کرده و تغییرات فایل جدیدتر را نمایش می‌دهد.

در اینجا برای مشاهده‌ی تغییرات فایل README.md دستور git diff README.md را اجرا می‌کنیم. با این‌کار تغییرات جدیدترین نسخه نسبت به اولین نسخه به نمایش در می‌آید.

به خاطر داشته باشید که به طور پیش فرض، دستور git diff تغییرات را نسبت به فایل اولیه نشان می‌دهد، نه فایل استیج شده. اگر می‌خواهید تغییرات استیج‌شده را مشاهده کنید، دستور git diff –cached README.md را اجرا کنید. این دستور چیزی شبیه کدهای زیر را به نمایش در خواهد آورد.

diff --git a/README.md b/README.md new file mode 100644 index 0000000..27c0a86 --- /dev/null +++ b/README.md @@ -0,0 +1,5 @@ +# Simple Git Project + +## Authors + +Matthew Setter <matthew@maltblue.com>

در کدهای نمایش داده شده به پنج خط آخر دقت کنید. قبل از هر سطر یک علامت + وجود دارد. این علامت نشانگر افزودن چیزی به فایل است. در اینجا ما فقط اضافه کرده‌ایم؛ اما اگر چیزی حذف کرده بودیم علامت منفی (-) نمایش داده می‌شد.

نکات مهم درباره‌ی استیجینگ یا ایندکس

اگر مبتدی هستید، یکی از گیج‌کننده‌ترین قسمت‌ها برای شما محیط استیجینگ و رابطه‌ی آن با کامیت خواهد بود.

کامیت در واقع ثبت سوابق تغییرات فایل‌ها نسبت به آخرین تغییر اعمال شده است. یعنی شما تغییری را در مخزن خود اعمال می‌کنید و به کیت می‌گویید که آن فایل‌ها را در یک کامیت ثبت سابقه کند.

کامیت‌ها ماهیت پروژه‌ی شما را در مراحل مختلف حفظ می‌کنند تا هر زمان که نیاز شد بتوانید به مرحله‌ی قبل برگردید.

اما چطور به گیت می‌گویید که کدام فایل‌ها را در کامیت قرار دهد؟ اینجا است که استیجینگ یا ایندکس ایفای نقش می‌کند. برای اضافه کردن یک فایل در کامیت، ابتدا باید آن را به محیط استیجینگ اضافه کنید. برای انجام این کار می‌توانید از دستور <git add <filename استفاده کنید. پس از اینکه که فایل‌های مورد نظر خود را با این دستور به محیط استیحینگ اضافه کردید، می‌توانید با دستور git commit آن‌ها را به عنوان کامیت در مخزن اعمال کنید.

برنچینگ یا شاخه‌بندی

تا این‌جا با نحوه‌ی شروع کار و اعمال تغییرات و بررسی آن‌ها آشنا شدیم. حالا با مفهوم پیشرفته‌تری به نام شاخه‌بندی آشنا می‌شویم. وقتی به طور تیمی روی یک نرم‌افزار کار می‌کنیم. آزمون و خطاهای هر برنامه‌نویس روی شاخه‌ی اصلی کدهای یک برنامه ممکن است دردسرساز شود. گیت این اجازه را به شما می‌دهد که شاخه‌ی اختصاصی خود را داشته باشید. در این حالت، وقتی روی ساخت یک ویژگی کار می‌کنید، آزمایش‌های شما صدمه‌ای به شاخه‌ی اصلی نمی‌زند و می‌توانید وقتی به نتیجه رسیدید، مجموعه‌ی تغییرات اعمال شده را با شاخه‌ی اصلی تلفیق یا merge کنید.

حتما متوجه شده‌اید ما تا این‌ بخش از آموزش در حال کار روی شاخه‌ی اصلی یا مستر برنچ بوده‌ایم. شاخه‌ی اصلی در واقع همان شاخه‌ای است که به صورت پیش‌فرض راه‌اندازی گیت با آن آغاز می‌شود. اکنون قصد داریم یک شاخه به نام development به معنی توسعه را راه‌اندازی کنیم. از ترمینال دستور git checkout -b develop را اجرا کنید تا شاخه‌ای به نام develop ساخته شود. اجرای این دستور علاوه بر ساخت شاخه‌ی مذکور بررسی آن را نیز اعمال می‌کند. این شاخه در ابتدا یک کپی از شاخه‌ی اصلی است. یعنی اگر دستور git status را اجرا کنید همان دو تغییر اعمال شده در README.md را مشاهده خواهید کرد. حالا فرض کنید می‌خواهیم همین دو کامیت را در شاخه‌ی اصلی تلفیق کنیم.

برای انجام این‌کار ابتدا باید مشخص کنید که قصد تلفیق تغییرات موجود در کدام شاخه را دارید.

پس، دستور git checkout master را اجرا کنید. حالا باید تغییرات را از شاخه‌ای که در حال کار روی آن بوده‌اید در این شاخه تلفیق کنید. برای این‌کار دستور git merge develop را اجرا کنید.

وقتی کار تمام شد، پیامی مبنی بر تغییر فایل‌ها و خلاصه گزارشی از آن تغییرات نشان داده خواهد شد.

به همین سادگی می‌توانید شاخه اضافه کنید و تغییرات آن را در شاخه‌ی اصلی اعمال کنید. البته برای این کار روش‌های دیگری نیز وجود دارد که با توجه به مقدماتی بودن آموزش به همین مقدار بسنده می‌کنیم.

آموزش کار با گیت‌هاب

پس از آشنایی مقدماتی با گیت وقت آن رسیده که به گیت‌هاب بپردازیم. همان‌طور که گفته شد، گیت‌هاب چیزی فراتر از یک مخزن پروژه است. این سرویس یکی از نسخه‌های گرافیکی گیت به شمار می‌رود. در واقع، اگر کار با گیت را بلد باشید به ندرت در کار با گیت‌هاب به مشکل برخواهید خورد. مسئله‌ی دیگر این است که ممکن است نخواهید پروژه‌ی خود را با دیگران به اشتراک بگذارید. در این حالت استفاده از گیت و ذخیره‌ی تغییرات به صورت لوکال بهترین گزینه است؛ همچنین در استفاده از گیت‌هاب شما ملزم به داشتن اتصال اینترنت هستید در حالی که در کار با گیت چنین الزامی وجود ندارد. با تمام این اوصاف، ممکن است بخواهید صفر تا صد پروژه‌ی خود را در گیت‌هاب انجام دهید؛ چرا که کار با گیت مرارت‌های خاص خود را دارد. برای مثال باید کل منبع را دانلود کنید، سپس وایرایش‌های خود را در قالب یک پچ تهیه کرده و به طریقی مثل ایمیل به سازنده‌ی اصلی بدهید و او این پچ را که از سازنده‌ی آن اطلاع دقیقی ندارد بررسی کرده و در صورت امکان استفاده کند. خواهید دید که در گیت‌هاب به عنوان یک شبکه‌ی برخط و متن‌باز هیچ‌یک از این مرارت‌ها وجود نخواهد داشت؛ اما قبل از شروع کار با گیت‌هاب نیاز به آشنایی با مفاهیم خاصی است که در زیر به آن‌ها می‌پردازیم.

گام اول: ساخت مخزن یا Repository

مخزن یا repository که به اختصار به آن repo نیز گفته می‌شود می‌تواند شامل فولدر، فایل، تصویر، ویدیو و هر آنچه پروژه‌ی شما به آن نیاز دارد باشد. گیت‌هاب در ابتدای ساخت پروژه امکان افزودن README و سایر موارد مانند لایسنس را در اختیار می‌گذارد.

مخزن اول شما با نام hello-world می‌تواند مکانی برای ذخیره کردن ایده‌ها، منابع یا حتی اشتراک‌گذاری و بحث در مورد چیزهای مختلف باشد.

• برای ساخت یک مخزن جدید در گوشه‌ی بالا سمت راست، نزدیک به آواتار یا نماد کاربری شما روی + کلیک کرده و سپس New repository را انتخاب کنید.


• توضیح کوتاهی بنویسید.


• در صورت تمایل به اضافه کردن README گزینه‌ی Initialize this repository with a README را انتخاب کنید.
  

  

  
  


• روی Creat repository کلیک کنید.

گام دوم: ساخت شاخه یا Branch

برنچینگ روشی برای کار همزمان روی نسخه‌های مختلف یک مخزن است.

به طور پیش‌فرض مخزن شما یک شاخه به نام master دارد که شاخه‌ی اصلی به حساب می‌آید. از شاخه‌ها برای آزمون و خطا و ویرایش کدها قبل از اعمال تغییرات در شاخه‌ی اصلی استفاده می‌شود.

وقتی یک شاخه بر پایه‌ی شاخه‌ی اصلی می‌سازید، یک کپی از آن با آخرین تغییراتی که تا آن لحظه اعمال شده در شاخه‌ی جدید ایجاد می‌شود. اگر زمانی که شما روی شاخه‌ی خود کار می‌کنید کسی کامیتی به شاخه‌ی اصلی اضافه کند می‌توانید آن را در شاخه‌ی خود اعمال کنید.

نمودار زیر روندی که یک شاخه‌ی جانبی با نام feature باید طی کند تا با شاخه‌ی اصلی تلفیق شود را نمایش می‌دهد.

• برای ساخت یک شاخه‌ی جدید به مخزن جدیدی که با نام hello-world ساخته‌اید بروید.


• روی فهرست بازشونده‌ی موجود در بالای فهرست فایل‌ها که روی آن نام شاخه نوشته شده است کلیک کنید. در تکست‌باکس باز شده نام شاخه‌ی جدید، مثلا readme-edits را وارد کنید.


• روی دکمه‌ی Create branch کلیک کرده یا دکمه‌ی Enter را در کیبورد خود بزنید.

حالا دو شاخه دارید؛ یکی master و دیگری readme-edits که کاملا شبیه به هم هستند؛ البته تا زمانی که تغییری در هیچ‌یک اعمال نکرده‌ایم.

گام سوم: ایجاد تغییرات و اعمال آن‌ها

حالا که شاخه‌ی جدیدی با محتویات یکسان با شاخه‌ی اصلی داریم، بدون ترس از خرابکاری ویرایش‌های خود را آغاز می‌کنیم.

در گیت‌هاب به تغییرات اعمال شده کامیت (commit) می‌گویند. هر کامیت یک پیام کامیت نیز به همراه دارد که توضیح کوتاهی در رابطه با دلیل اعمال آن تغییر است. پیام‌های کامیت به سایر مشارکت‌کنندگان در پروژه این امکان را می‌دهد که متوجه شوند که شما چه تغییری را به چه دلیل اعمال کرده‌اید.

• برای اعمال یک تغییر روی فایل README.md کلیک کنید.


• روی آیکون مداد در گوشه‌ی بالا سمت راست کلیک کنید تا آم را ویرایش کنید.


• در ویرایشگر، کمی درباره‌ی خود بنویسید.


• یک پیام کامیت برای توصیف تغییرات خود بنویسید.


• روی دکمه‌ی Commit changes کلیک کنید.

تغییرات ایجاد شده در فایل README تنها در شاخه‌ی readme-edits اعمال شده‌اند. حالا این شاخه دارای تغییراتی نسبت به شاخه‌ی master است.

گام چهارم: ایجاد درخواست اعمال تغییرات یا pull request

حالا برای اعمال این تغییرات در شاخه‌ی اصلی باید درخواست آن را ایجاد کنید. pull request هسته‌ی تمام همکاری‌ها در گیت‌هاب را تشکیل می‌دهد. با ارسال چنین درخواستی، شما از صاحب شاخه می‌خواهید که تغییرات انجام‌شده توسط شما را بررسی کرده و در صورت صلاحدید به شاخه‌ی اصلی اضافه کند. درخواست‌های اعمال تغییرات تغییرات بین دو شاخه را نمایش می‌دهند. تغییرات، حذف و اضافه‌ها در رنگ‌های سبز و قرمز نشان داده می‌شوند.

با استفاده از سیستم منشن در گیت‌هاب می‌توانید در سیستم پیام‌ pull request خود از سایر افراد یا تیم‌ها درخواست کنید که درباره‌ی ویرایش‌های شما نظر بدهند.

شما می‌توانید درخواست اعمال تغییرات را برای خود نیز ارسال کنید. یعنی وقتی تغییری را به طور کامل در شاخه‌ی فرعی انجام دادید، می‌توانید برای تلفیق آن در شاخه‌ی اصلی از pull request استفاده کنید.

گام پنجم: پذیرش درخواست تلفیق تغییرات اعمال شده

در این گام پایانی، نحوه‌ی تلفیق تغییرات شاخه‌ی فرعی در شاخه‌ی master را بررسی می‌کنیم.

• روی دکمه‌ی سبزرنگ Merge pull request کلیک کنید تا تغییرات شما در شاخه‌ی اصلی اعمال شوند.


• روی Confirm merge کلیک کنید.


• حالا که تغییرات را اعمال کرده‌اید، می‌توانید با استفاده از دکمه‌ی Delete branch شاخه‌ی فرعی را حذف کنید.
  

  

  
  

تعدادی از اصطلاحات رایج در گیت‌هاب

در تصویر فوق صفحه‌ی اصلی مربوط به یک پروژه را می‌بینید. در مستطیل شماره‌ی یک نام پروژه، تعداد افرادی که در حال تماشای آن هستند، تعداد افرادی که با ستاره دادن آن را ارزیابی کرده‌اند، تعداد دفعاتی که این پروژه توسط توسعه‌دهندگان دیگر برای مشارکت در پروژه آن را کپی‌برداری شده است. در مستطیل شماره‌ی ۲ تعداد کامیت‌های اعمال‌شده در شاخه‌ی فعلی، تعداد شاخه‌های موجود، تعداد نسخه‌های منتشرشده و تعداد مشارکت‌کنندگان در پروژه نشان داده شده است. در مستطیل شماره‌ی ۳ نوار انتخاب شاخه را می‌بینید که در زیر آن فایل‌های مهم پروژه به همراه زمان آخرین باری که تغییری در آن‌ها اعمال شده است قرار دارد.

در قسمت راست تصویر و در مستطیل شماره‌ی ۴ مفاهیمی کلیدی را مشاهده می‌کنید که در زیر به توضیح آن‌ها می‌پردازیم.

• کد (Code): حالت نمایشی که به صورت پیش‌فرض در آن قرار دارید و فایل‌های پروژه به شما نمایش داده می‌شوند.


• مسائل (Issues): چنان‌چه شما یا هم‌تیمی‌های شما بخواهند مشکلی را در نرم‌افزار گزارش کنند، یا درخواست افزودن قابلیت یا مسائلی این‌چنینی را مطرح کنند، از این گزینه استفاده می‌کنند.


• ویکی (Wiki): امکانی است برای ثبت جزئی‌تر پروژه نسبت به آن‌چه در README.md می‌آید.


• ضربان (Pulse): خلاصه‌ای از آمار پروژه شامل مسائل مطرح شده، حل شده و حل نشده است که نشانگر میزان فعال بودن پروژه است.


• نمودارها (Graphs): پیشرفت پروژه در طول زمان شامل روزهای پرکار و زمان‌هایی که پروژه رها شده و بی‌تغییر مانده است را نشان می‌دهد.

و نهایتا در همان سمت راست تصویر لینک دسترسی به مخزن را می‌بینید که اگر قصد داشته باشید پروژه‌ای را کلون کنید، یعنی نسخه‌ای از آن را برای خود کپی کنید، می‌توانید از طریق این آدرس اقدام کنید.

حالا با کلیک روی قسمت commits نگاهی به سوابق کامیت‌ها می‌اندازیم. در این قسمت کامیت‌ها را به ترتیب جدیدترین به قدیمی‌ترین مشاهده می‌کنید. در سمت چپ توضیح مختصری در خصوص کامیت، نام سازنده‌ی آن و تاریخی که ساخته شده است را می‌بینید. در سمت راست، نسخه‌ی کوتاه هش مربوط به کامیت و لینک ورود به این کامیت قرار دارد.

روی هش کامیت کلیک کنید تا تغییراتی که به واسطه‌ی آن اعمال می‌شود را ببینید. در مثال ما تغییرات نظیر به نظیر فایل README و فایل Version.php یک پروژه بررسی شده است. در سمت چپ مواردی که در مقایسه با نسخه‌ی قبل حذف شده‌اند را می‌بینید و در سمت راست آن‌چه در این نسخه اضافه شده را شاهد هستید. در بالای هر کامیت سمت چپ خلاصه‌ای کوتاه از تغییرات نمایش داده می‌شود.

اما قسمت جالب ماجرا این‌جا است؛ نشانگر موس را روی هر یک از قسمت‌های چپ یا راست که قرار دهید آیکونی آبی‌رنگ با علامت مثبت نمایان می‌شود. با کلیک روی آن می‌توانید نظر خود را در خصوص قسمت خاصی از تغییر اعمال شده بنویسید. این ویژگی گیت‌هاب از قابلیت‌های فوق‌العاده‌‌ای است که تجربه‌ی کار گروهی را ارتقاء می‌دهد. اگر می‌خواهید راحب کل کامیت نظر بدهید، در پایین آن قسمتی برای ای‌کار در نظر گرفته شده است.

آموزش انتقال پروژه از گیت به گیت‌هاب

حالا قصد داریم پروژه‌ی کوچکی که در گیت روی آن کار کرده بودیم را در گیت‌هاب بارگذاری کنیم. برای این‌کار ابتدا نیاز به ساخت یک حساب کاربری در گیت‌هاب دارید. توجه داشته باشید در روند ساخت حساب کاربری در گیت‌هاب پس از وارد کردن نام کاربری، ایمیل و پسورد، دو تعرفه پیش روی شما قرار می‌گیرد. در گزینه‌ی اول استفاده از گیت‌هاب رایگان خواهد بود اما نمی‌توانید پروژه‌ی محرمانه بسازید. تبعا گزینه‌ی دوم پولی و با امکان ساخت پروژه‌ی محرمانه یا خصوصی است.

پس از ورود به حساب کاربری خود برای بارگذاری پروژه روی علامت مثبت موجود در بالا گوشه‌ی راست کلیک کنید و در فهرست بازشده New repository را برای راه‌اندازی مخزن جدید انتخاب کنید. در این مرحله فرم مربوط به ساخت پروژه‌ی جدید ظاهر خواهد شد.

در قسمت Repository name یک نام برای مخزن خود وارد کنید. این نام می‌تواند first-project به معنی اولین پروژه باشد. می‌توانید توضیحی نیز در خصوص آن ذکر کنید. مثلا my first Github project به معنی اولین پروژه‌ی من در گیت‌هاب. حالت پروژه با توجه به نوع کاربری شما، public خواهد بود. نهایتا تیک inilialize this repository with a README را بزنید و دو قسمت دیگر را به همان شکل روی None رها کنید. حالا روی Create repository کلیک کنید.

در این مرحله به صفحه‌ی راه‌انداری سریع هدایت خواهید شد. این صفحه امکان بارگذاری پروژه‌ی گیت را به ما خواهد داد. برای انجام این‌کار اولین سطر زیر or push an existing repository from the command line… را کپی کرده و آن را در ترمینال یعنی همان‌جایی که تا کنون روی آن کار می‌کردیم پیست کنید.

این‌کار به ما خروجی نخواهد داد. حالا همین کار را برای سطر دوم انجام دهید. در این مرحله تغییرات ما به گیت‌هاب منتقل می‌شود و خروجی مشابه آن‌چه در تصویر زیر می‌بینید خواهد بود. حالا در مرورگر خود صفحه‌ی گیت‌هاب را ریفرش کنید. فایل‌های README.md و index.php به عنوان اولین فایل‌های پروژه نمایش داده می‌شوند و محتویات README.md در پایین صفحه نمایان می‌شود.

سخن پایانی

در این مقاله با مفاهیم بنیادی گیت، طرز کار با آن، اصطلاحات گیت‌هاب و کاربردهای هرکدام آشنا شدید. با اینکه ممکن است مفاهیم بسیار دیگری وجود داشته باشد که ما در این آموزش مقدماتی به آن‌ها نپرداخته باشیم، شما کاربر محترم زومیت با آموختن همین میزان از اطلاعات می‌توانید کار خود را آغاز کرده و مابقی مفاهیم را رفته‌رفته بیاموزید. نکته‌ی خوب در مورد گیت و گیت‌هاب این است که افرادی در آن‌ها فعالیت دارند که تشنه‌ی یادگیری و یاد دادن هستند و از این نقطه‌نظر، این سرویس‌ها شما را وارد دنیایی نامتناهی از اطلاعات می‌کنند که روز به روز به دانش برنامه‌نویسی شما خواهد افزود.

منبع : زومیت

آموزش مقدماتی کار با گیت و گیت‌هاب