Git را از طریق Gamification بیاموزید – یک راهنمای بصری برای مفاهیم کنترل نسخه کلیدی

GIT مفاهیم و دستورات بسیاری دارد که باید قبل از استفاده از آن اطمینان داشته باشید. برخی از این مفاهیم ممکن است بی اهمیت به نظر برسد ، به خصوص برای کسی که قبلاً با GIT کار کرده است. اما مانند اکثر مفاهیم گیت و برنامه نویسی ، حتی “ساده” تمایل به انتزاعی دارند.

سه مفهوم که برای من به عنوان اساسی ترین برای توانایی کار مؤثر با GIT در سطح اساسی برای من برجسته است عبارتند از:

1. در فهرست کار

2. در قسمت صحنه

3. در تاریخ

در این مقاله ، ما رویکرد جدیدی برای نمایندگی این سه مفهوم خواهیم داشت: توسط تجسم آنها در دنیای بازی همهجانبه و سه بعدی!

من یک نمایش بصری ملموس و از این مفاهیم اصلی GIT ارائه می دهم که تقریباً همیشه به روشی انتزاعی و گیج کننده شرح داده شده است. امیدوارم که این امر باعث شود آنها درک شما بسیار شهودی تر شوند.

فهرست مطالب

1. فهرست کار خود را تجسم کنید

2. منطقه مرحله بندی خود را تغییر دهید

3. به معنای واقعی کلمه در تاریخ تعهد خود قدم بزنید

4. خلاصه

5. خودتان آن را امتحان کنید

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

وقتی به “فهرست کار” فکر می کنید ، مغز شما چه چیزی را نشان می دهد؟ من تصور می کنم این چیزی شبیه به ساختار پوشه است که از پروژه شروع می شود root، حاوی پرونده های کد و زیر پوشه هایی که پروژه را تشکیل می دهند.

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

GIT با دستور وضعیت GIT ، تغییر در فهرست کار را تشخیص داده و گزارش می دهد ، که خروجی مانند این را نشان می دهد:

Jack@RAPTOR ~/my-project (main)> git status
روی branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   main.py
        modified:   settings.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        one.py
        three.py
        two.py

no changes added to commit (use "git add" and/or "git commit -a")

دو بخش مربوطه در اینجا عبارتند از:

1. تغییراتی که برای تعهد انجام نشده است: لیست پرونده های موجود توسط GIT که در حال حاضر حاوی تغییرات کد هستند ، لیست می کند. در مثال بالا ، ما دو “پرونده اصلاح شده” را مشاهده می کنیم: main.py وت settings.pyبشر

2. پرونده های بدون ردیابی: پرونده های جدید را در پروژه خود لیست می کند که هنوز از آن خبر ندارد. در مثال بالا ، ما سه پرونده جدید و بدون پرده را مشاهده می کنیم: one.pyبا two.pyوت three.pyبشر

وقتی صحبت از درک GIT می شود ، فکر کردن به فهرست کار به عنوان تغییرات Git در این دو بخش – پرونده های بدون ردیابی وت پرونده های اصلاح شده – کاملاً مفید است.

اما git status فرمان این جزئیات را در terminal به روشی کاملاً مبتنی بر متن ، که در هنگام پیچیدن سر خود در اطراف Git ، کاربران جدیدتر را به هیچ وجه طرفداری نمی کند.

برخی از GIT GUI با این کار بهتر کار می کنند (آنها یک رابط کاربری ایمن تر و کلیک را ارائه می دهند) ، اما در تجربه من ، هیچ یک از آنها چیزهایی را نمی سازند با یک نگاه واضح استبشر

در عوض ، تصور کنید که به عنوان یک کاربر جدید GIT ، این را دیدید:

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

به طور خاص ، بلوک های نشان دهنده پرونده ها one.pyبا two.pyوت three.py همه به طور مرتب در پرونده های بدون ردیابی بخش ، و بلوک های نمایانگر پرونده ها main.py وت settings.py در پرونده های اصلاح شده بخش

این امر باعث می شود تا حتی یک تازه کار که GIT در حال تفسیر این پرونده ها متفاوت است و آنها را به روشی منطقی طبقه بندی می کند ، کاملاً واضح است. این مفهوم انتزاعی “فهرست کار” را می گیرد و آن را به شکلی تبدیل می کند که تقریباً هر کسی می تواند با یک نگاه سر خود را بپیچاند.

اما چیزی در اینجا از دست رفته است. بیایید بگوییم شما دستور را اجرا می کنید git add one.pyبشر این پرونده پرونده غیرقابل انکار است one.py در تعهد بعدی گنجانده شود. چه اتفاقی برای بلوک برچسب زده می شود one.py روی دیوار؟

منطقه مرحله بندی خود را تغییر دهید

برای پاسخ به آن ، بیایید حرکت کنیم روی به “منطقه صحنه سازی” مرموز. اما اول ، منطقه صحنه دقیقاً کجاست؟

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

در اینجا آمده است که چگونه GIT این را در terminal:

Jack@RAPTOR ~/D/git-worlds (main)> git status
روی branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   one.py

همانطور که از خروجی Git می بینید ، اکنون این بخش را شامل می شود تغییراتی که انجام شود، که شامل پرونده است one.py که با git add فرمان

اما این هنوز کمی نامشخص است. آیا تغییر پرونده مرحله در one.py هنوز بخشی از فهرست کار است؟ یا Git آنها را در جای دیگر ذخیره می کند؟

خوب ، جواب این است … هر دو:

در اینجا می بینید که ما کمی از تصویر قبلی بزرگنمایی کردیم تا بخش سوم دیوار دارای برچسب را فاش کنیم پرونده های مرحله ایبشر

از آنجا که ما فرمان را اجرا کردیم git add one.py، می بینید که بلوک مربوطه نمایانگر one.py پرونده از ستون پرونده های غیرقابل انتخاب به ستون Files Staged منتقل شد.

این کاملاً واضح است که پرونده ای که در منطقه صحنه نشسته است هنوز بخشی از فهرست کار است (زیرا بخشی از دیوار کلی است) ، در حالی که در فضای مشخص شده خود نیز تقسیم می شود.

از دیدگاه فنی ، منطقه مرحله بندی Git فقط پرونده ای است فهرست که در .git/ پوشه GIT تغییرات کد مشخص شده توسط git add فرمان در این پرونده ، که به عنوان منبع برای آن تغییرات دفعه بعد استفاده می شود git commit فرمان اجرا می شود.

اما از منظر گردش کار ، نماینده منطقه مرحله بندی به عنوان یک بخش روی “دیوار دایرکتوری کار” همانطور که در تصویر بالا باعث می شود همه چیز بصری را درک کند.

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

به معنای واقعی کلمه در تاریخ تعهد خود قدم بزنید

وقتی به “تاریخ متعهد” Git فکر می کنید ، ذهن شما چه می بیند؟

خوب ، زیباترین راه git این کار را در terminal با استفاده از دستور git log ، مانند git log --graph --all، که خروجی مانند:

* commit 88085cff3e2d7657f26eb6479b308526df7d2bba (HEAD -> dev, origin/dev)
| Author: Jacob Stopak <jacob@initialcommit.io>
| Date:   Tue Apr 23 20:31:24 1403 -0700
|
|     Fix command as title clip, ellipses and arrow length in rebase subcommand
|
|     Signed-off-by: Jacob Stopak <jacob@initialcommit.io>
|
*   commit e264605ea26a808c34d4dc2fbc6dad65a8e28c5f
|\  Merge: cb3fa5f b8c071c
| | Author: Jacob Stopak <jacob@initialcommit.io>
| | Date:   Wed Mar 20 19:51:06 1403 -0700
| |
| |     Merge branch 'main' into dev
| |
* | commit cb3fa5f3bdbdcff3d9a8c844cda99d46bf64e337
| | Author: Jacob Stopak <jacob@initialcommit.io>
| | Date:   Sat Mar 9 22:00:49 1403 -0800
| |
| |     Add --staged flag to git restore subcommand
| |
| |     Signed-off-by: Jacob Stopak <jacob@initialcommit.io>
| |
| * commit b8c071cb9a1653748525aa01c2b6bafe06ed9100
|/  Author: Jacob Stopak <jacob@initialcommit.io>
|   Date:   Wed Mar 20 19:50:53 1403 -0700
|
|       Correct license specified in pyproject.toml from MIT to GNU GPLv2
|
|       Signed-off-by: Jacob Stopak <jacob@initialcommit.io>
|
* commit 32a3a3fca583f6c68225b974716e74b557a1a094
| Author: Jacob Stopak <49353917+initialcommit-io@users.noreply.github.com>
| Date:   Tue Aug 22 11:31:38 1402 -0700
|
|     Update README.md

متأسفانه ، این اصلاً خیلی زیبا نیست. این لیست طولانی و پرحاشیه شناسه ، نام ، تاریخ و پیام های متعهد قطعاً چیزی نیست که اکثر افراد کاربر پسند در نظر بگیرند.

در --graph گزینه ارائه شده در بالا با ترسیم خطوط کوچک اتصال هر تعهد در این زمینه ، روابط متعهد را نشان می دهد terminal، اما ماهیت کاملاً متن مبتنی بر این فقط برای اکثر مردم با یک نگاه شهودی نیست.

اکنون نمایندگی گیم شده زیر از تاریخ تعهد Git را در نظر بگیرید:

حالا ما صحبت می کنیم! در این تصویر ، هر تعهد git توسط یک بلوک سفید با شناسه تعهد 6 کاراکتر کوتاه نشان داده شده است.

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

شاید متوجه شده باشید که برخی از بلوک های متعهد سفید دارای بلوک های رنگی هستند روی بالای آنها بلوک های سبز نام شاخه ها ، بلوک های زرد برچسب های git ، بلوک آبی نشانگر سر Git است و بلوک های قرمز شاخه های ردیابی از راه دور هستند. این موارد در مجموع به عنوان Git Refs گفته می شود.

علاوه بر این که قادر به تمایز به راحتی بین آنها است ، نشان دادن انواع Ref به عنوان بلوک های رنگی مختلف ، مفهوم GIT را که اغلب درگیر است ، روشن می کند. در GIT ، شاخه ها (به همراه سایر انواع Refs) فقط “نشانگر” برای یک تعهد خاص هستند. وسوسه انگیز است که به یک شاخه به عنوان یک سری از تعهدات متصل فکر کنیم که یک تاریخ را به اشتراک می گذارد – و از نظر مفهومی این صحیح است – اما در GIT ، یک شاخه واقعاً فقط یک برچسب شکوه است که به یک تعهد خاص اشاره می کند.

در این دنیای بازی شده ، می توانید به معنای واقعی کلمه در تاریخ تعهد خود قدم بزنید برای دیدن ، تعامل و بررسی تغییرات کد در هر تعهد.

خلاصه

در این مقاله ، ما بررسی کردیم که چگونه مفاهیم اساسی Git – فهرست کار ، منطقه مرحله بندی و ارتکاب تاریخ – به دلیل ماهیت انتزاعی آنها می تواند دشوار باشد.

برای دسترسی بیشتر این مفاهیم ، ما یک رویکرد بصری و بصری را معرفی کردیم که آنها را به چیزی ملموس تبدیل می کند: دنیای بازی همهجانبه ای که در آن پرونده ها و تعهدات به عنوان بلوک های تعاملی نشان داده می شوند.

با ارائه GIT از این طریق ، رمزگذارهای مبتدی ، دانش آموزان و توسعه دهندگان در تمام سطوح تجربه می توانند به طور شهودی مفاهیم و دستورات git را بیاموزند و با اطمینان از آنها در پروژه های حرفه ای استفاده کنند.

خودتان آن را امتحان کنید

تصاویر موجود در این پست در Devlands ، اولین و تنها ضبط شد رابط و آموزش gamied git، که من در پایتون می سازم.

در Devlands ، نه تنها می توانید از طریق پایگاه کد خود قدم بزنید … شما همچنین می توانید مفاهیم و دستورات GIT را با یک آموزش با هدایت شخصیت یاد بگیرید ، دستورات GIT را به طور مستقیم در بازی شبیه سازی و اجرا کنید ، نتایج آنها را در دنیای بازی در زمان واقعی مشاهده کنید و از AI برای توضیح کد مورد نظر خود استفاده کنید.

اگر شما یا شخصی که می شناسید یک یادگیرنده بصری ، رمزگذار مبتدی یا کاربر جدیدتر GIT است ، آن را بررسی کنید!