دستورات ضروری Git

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

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

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

در این مقاله، قرار نیست همه‌ی دستورهای Git را لیست کنیم. هدف ما این است که دستورهایی را معرفی کنیم که احتمالاً در موقعیت‌های بحرانی به کمک‌تان می‌آیند چه در کار با ریپازیتوری local و چه هنگام کار با remote. این مقاله در دو بخش ارائه می‌شود: بخش اول روی دستورهای مفید در محیط local تمرکز دارد و بخش دوم به رفع اشتباهات و مدیریت commitها در remote اختصاص دارد.

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

در ادامه خواهید خواند:

• فایل‌هایی که به صورت اتفاقی در حالت staged قرار گرفته‌اند
• به طور تصادفی فایل‌ها را ردیابی می‌کنید یا دیگر نمی‌خواهید یک فایل را track کنید؟
• می‌خواهید فایل‌های un-tracked و ignore شده را حذف کنید؟
• آیا می خواهید تغییرها را به حالت un-committed برگردانید؟
• جمع بندی

فایل‌هایی که به صورت اتفاقی در حالت staged قرار گرفته‌اند

آیا تاکنون دستور زیر را اجرا کرده‌اید و می‌خواهید آن‌ها را بی‌اثر کنید؟

git add .
git add *
git add -A
git add -u

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

دستورهایی که در این زمان می‌توانند به شما کمک کنند:

• git reset <filename> یا git reset HEAD <filename>
• git rm --cached <filename>
• git restore --staged <filename> — در v2.23 (اوت 2019) به گیت اضافه‌شده است.

این سه دستور هنگام اضافه کردن فایل‌ها به حالت stage، توسط خود گیت به شما توصیه می‌شود. اگر شما از گیت ورژن 2.23 (اتصال به semantic versioning) استفاده‌کنید،

git restore --staged <filename>

بجای

git reset HEAD <filename>

به شما توصیه می‌شود.

دستور

git restore --staged <filename>

به طور شفافی کاراییش معلوم است. پس بیاید دو دستور دیگر را بررسی‌کنیم.

:git reset HEAD <filename>

این دستور برای بازنشانی INDEX یا STAGING AREA مورد استفاده قرار می‌گیرد.

git rm --cached <filename>:

این دستور کاملا فایل را از حالت INDEX یا STAGING AREA خارج می‌کند، همچنین اگر شما یک فایل موجود در ریپازیتوری را پاک کنید، با اجرای این دستور، آن‌فایل از INDEX، STAGING AREA و همچنین از commitهای دیگر پاک خواهدشد. اما هنگامی که از این‌ دستور بر روی فایل جدید استفاده کنید، فقط آن را از حالت staged بیرون می‌آورد.

چرا گیت دو دستور مختلف را برای اینکار توصیه می‌کند؟

برای اجرای موفقیت‌آمیز دستور

git reset HEAD <filename>

یا

git restore --staged <filename>

باید حداقل یک commit وجود داشته‌باشد. به این‌دلیل که دستور

git reset HEAD

فایل درون HEAD را بازگردانی می‌کند ولی قبل از انجام اولین commit هیچ‌گونه HEAD ی موجود نیست (به این‌دلیل که HEAD در زمان اولین commit ساخته می‌شود.).

راه‌حل این مشکل هم اجرای آنT به استثنای HEAD است، به مثال زیر توجه کنید:

یادداشت: من از git revert بجای git revert Head استفاده می‌کنم. دفعه بعد که از گیت استفاده می‌کنید، هنگامی که هنوز commit ی موجود نباشد، گیت دستور

git rm --cached <filename>

را به شما پیشنهاد می‌کند در غیر این‌صورت

git reset Head و git restore --staged

را مشاهده خواهیدکرد.

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

git reset

git reset HEAD <filename>:

اگر شما فرد تنبلی باشید، تمام commit‌های خود را در پایان روز انجام می‌دهید.

در تمام‌روز به اضافه‌کردن و ویرایش فایل‌هایتان مشغول بوده‌اید، حال شما می‌خواهید همگی آن‌ها با هم‌دیگر در یک commit به گیت بیفزایید و به صورت اتفاقی از دستور git add . استفاده می‌کنید.

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

با توجه به تصویر بالا، حال شما می‌توانید این‌کار را انجام دهید.

git rm –cached

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

دوباره تکرار می‌کنم، دستورهای

git rm --cached و git reset

تا زمانی یکسان عمل می‌کنند که commit ی انجام نشده‌باشد. در قدم اول خروجی دستور

git rm --cached

را هنگامی که commit انجام شده، بررسی می‌کنیم.

با نگاه‌کردن به عکس بالا متوجه اتفاقاتی که رخ داده‌است، می‌شوید؟ اگر متوجه نشده‌اید، نگران این موضوع نباشید در ادامه کاملا توضیح می‌دهیم.

این دستور فایل‌ها را از INDEX و STAGING AREA پاک می‌کند، ولی این فایل‌ها با تمام اطلاعاتشان هنوز در سیستم شما موجود هستند اما گیت آن‌فایل را به حالت un-tracked درآورده‌است. ساده‌تر بگوییم، با اجرای دستور git rm --cached به نظر می‌رسد شما، تازه یک فایل را در پوشه‌تان کپی کرده‌اید.

یکی دیگر از اتفاقاتی که در اجرای این‌دستور رخ می‌دهد، پاک شدن فایل از ریپازیتوری است. اگر شما دستور:

git rm --cached <file> && git push

را اجرا کنید، <file> از گیت پاک می‌شود، زیرا این فایل فقط در سیستم شما موجود است و به حالت un-tracked در آمده.

برای رویارویی با زمانی که شما تمام فایل‌هایتان را در ریموت‌سرور push کرده‌اید، مثلا شما همراه پروژه node خود پوشه node_modules را به ریمورت فرستاده‌اید، می‌توانید:

• فایلی با پسوند .gitignore در کنار فایل‌هایتان اضاف کنید و بعد از آن دستور rm -r node_modules && git add . && git commit && git push && npm start را اجرا کنید.
• یا .gitignore را بسازید سپس دستورهای git rm --cached -r node_modules && git commit && git push را اجرا کنید.

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

git rm --cached -r

استفاده می‌کنید (-r مخفف بازگشی – recursive)، این دستور پوشه node_modules را از INDEX یا STAGING AREA پاک می‌کند و همچنین آن‌پوشه به حالت un-tracked در می‌آید. ولی به این نکته توجه داشته باشید از فایل‌های سیستمی شما پاک نمی‌شود.

هنگامی که شما دستور git add . را اجرا می‌کنید، اول فایل .gitignore چک می‌شود و دیگر شما پوشه node_modules را در git status نمی‌بینید زیرا به یک پوشه un-tracked در آمده‌است.

مقایسه Git و GitHub
 Git و GitHub

خلاصه:

همیشه از دستورهای git reset <filename> برای unstage کردن یک فایل بخصوص یا از git reset . برای unstage کردن تمام فایل‌ها استفاده کنید. این دستورها حتی اگر commit هم رخ نداده باشد کار می‌کنند.

از دستور git rm --cached هم زمانی که می‌خواهید فایلی را از ریپازیتوری حذف و آن را در سیستم خود نگهدارید، استفاده کنید. کارایی این دستور را با git reset اشتباه نکنید.

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

به طور تصادفی فایل‌ها را ردیابی می‌کنید یا دیگر نمی‌خواهید یک فایل را track کنید؟

در این قسمت فایده دستور git rm --cached نمایان می‌شود. همانطور که قبلا در این مقاله خواندید این‌دستور فایل را از INDEX و STAGING AREA و همچنین ریپازیتوری پاک می‌کند. بنابراین، git push فایل را از ریپازیتوری حذف و در قدم بعد git pull آن را از فایل‌های سیستم گیت پاک می‌کند (فایل‌ها در سیستم شما باقی می‌مانند).

• برای un-track و پاک‌کردن همه چیز: git rm --cached .
• برای un-track و پاک‌کردن یک فایل بخصوص: git rm --cached <fillename>
• و در آخر برای un-track و پاک‌کردن یک پوشه: git rm --cached -r <directoryname>

توجه داشته‌باشید دستور git rm با git rm --cached متفاوت است. git rm نیز فایل را از سیستم شما، ریپازیتوری و هرجای دیگر سیستم پاک می‌کند. پس --cached را فراموش نکنید.

آموزش استفاده از Git
استفاده از Git

می‌خواهید فایل‌های un-tracked و ignore شده را حذف کنید؟ در ادامه با ما همراه باشید.

در مقابل شما دو راه‌حل وجود دارد. با دستور rm file1 file2 file3 ... این‌کار را انجام‌دهید. ولی اگر فایل‌ها زیاد باشند، این کار منطقی نیست پس یک راه دیگر پاک کردن فایل‌های درون .gitignore است. این‌کار با دستور git clean انجام می‌شود.

راهنمای (man) این‌دستور:

Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.

Normally, only files unknown to Git are removed, but if the -x option is specified, ignored files are also removed. This can, for example, be useful to
remove all build products.

همانطور که در متن بالا گفته شد، با این دستور به صورت بازگشتی (recursive) فایل‌ها از دایرکتوری فعلی که دستور در آن اجرا شده پاک می‌شوند.

• برای حذف un-tracked فایل‌ها: git clean -f
• برای حذف un-tracked و ignored فایل‌ها: git clean -xf
• برای حذف دایرکتوری‌ و un-tracked فایل‌ها: git clean -fd
• برای حذف دایرکتوری‌ و un-tracked, ignored فایل‌های : git clean -xfd

ولی چرا از ویژگی -f یا –force استفاده می‌کنیم؟ در پیکربندی گیت، متغییر clean.requireForce برابر با true قرار داده شده‌است. اگر از -f، -n، -i استفاده نکنیم دستور ما با موفقیت به پایان نمی‌رسد.

این دستور فایل و پوشه‌ها را به صورت فیزیکی حذف می‌کند. پس امیدوارم در هنگام اجرای این دستور اشتباه نکرده باشید. برای رفع این مشکل می‌توانید از دستور git clean -fi استفاده کنید.

شما می‌توانید از گزینه شماره 4 استفاده کنید و گیت قبل از حذف هر فایل، از شما می‌پرسد از فایل حذف شود یا خیر؟

راهنمای (man) این‌دستور:

آیا می خواهید تغییرها را به حالت un-committed برگردانید؟

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

راه‌حل، استفاده از دستور git checkout است. بله درست شنیدید، ولی هنگام استفاده از این دستور، مراقب باشید. استفاده نادرست این دستور باعث تخریب می‌شود. اجرای این دستور باعث حذف کارهای انجام‌شده بر روی دایرکتوری که در آن قرار دارید می‌شود و آن را به commit قبلی خود بازمی‌گرداند.

راهنمای این دستور:

git-checkout — Switch branches or restore working tree files

Updates files in the working tree to match the version in the index or the specified tree. If no paths are given, git checkout will also update HEAD to set
the specified branch as the current branch.

پی‌نوشت: شاید در تصویر بالا شما دستور git restore <filename> را ببینید (این بخاطر استفاده از ورژن 2.25.0 گیت است). با توجه به راهنما، از این دستور استفاده نکنید.

در ادامه، میبایست به این موضوع اشاره کرد با دستور git checkout . می‌توانید فقط فایل‌های تغییر داده‌شده را به stage قبل (نه commit قبل) برگردانید. در تصویر بالا staging version قبل، خالی است. پس با دستور git checkout . محتوای first message to commit، خالی می‌شود.

گیت تاریخچه INDEX و STAGING AREA را نگهداری نمی‌کند. دو چییزی که گیت به شما نشان می‌دهد:

• چه‌چیزی در INDEX است؟
• چه‌چیزی در INDEX نیست؟

با اجرای دستور git add، گیت محتوای درون INDEX را اضافه یا با مقدار جدید جایگزین می‌کند. بنابراین شما به تاریخچه INDEX مانند COMMIT دسترسی ندارید و نمی‌توانید آن را بازگردانی کنید.

از آنجا که هیچ INDEX versions دیگری باقی نمانده است، گیت کپی از commit قبلی که somedbconfigfile1 خالی است دریافت می کند.

دستور git checkout <filename> را فقط می‌توان روی فایل‌های stage نشده اجرا کرد. به همین دلیل از git reset . برای un-stage کردن فایل در تصویر بالا استفاده شده است.

نحوه نصب Git در سرور مجازی ابری اوبونتو
 نصب Git در سرور مجازی 

جمع بندی

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

آنچه در این مقاله دیدید، مجموعه‌ای از دستورهای کاربردی برای مدیریت بهتر local repository و تعامل هوشمندانه با remoteها بود؛ دستورهایی که نه فقط کدنویسی شما را نجات می‌دهند، بلکه آرامش ذهنی‌تان را هم حفظ می‌کنند.

اگرچه Git هیچ‌گاه کاملاً بی‌دردسر نمی‌شود، اما با یادگیری این ابزارها، می‌توانید با اطمینان بیشتری تغییرات‌تان را مدیریت کنید، اشتباهات‌تان را اصلاح کنید و پروژه‌های خود را به‌خوبی پیش ببرید.

فراموش نکنید: در Git، تقریباً هیچ‌چیز واقعاً از دست نمی‌رود به‌شرطی که بلد باشید کجا را بگردید.

منبع: https://medium.com/from-the-scratch/git-commands-you-need-to-know-when-you-are-messed-up-e880fbf03819