ابزار های کاربردی کد نویسی- بخش اول

ابزار های مورد بررسی در این پست:

• uv

• git

مدیریت پایتون با ابزار uv

تا حالا شده کلی وقت صرف نصب پکیج‌ها کنی و آخرش هم با خطای «پکیج پیدا نشد» توی Jupyter Notebook روبرو بشی؟ یا اینکه مدیریت محیط‌های مجازی (venv) برات کلافه‌کننده شده باشه؟

اگر جوابت "بله" است، وقتشه با uv آشنا بشی. uv یک ابزار فوق‌سریع برای مدیریت پایتون و پکیج‌هاست که توسط تیم Astral ساخته شده. برخلاف ابزارهای قدیمی، uv به زبان Rust نوشته شده که باعث میشه سرعتش ۱۰ تا ۱۰۰ برابر بیشتر از ابزارهای معمولی باشه.

چطور شروع کنیم؟

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

* لینوکس/macOS:

curl -LsSf https://astral.sh/uv/install.sh | sh

* ویندوز (PowerShell):

iwr https://astral.sh/uv/install.ps1 -useb | iex

چند دستور کلیدی که کارت رو راه میندازه:

همین که این چند تا دستور رو یاد بگیری، دیگه نیازی نیست نگران پیچیدگی‌های محیط پایتون باشی:

1. شروع یک پروژه جدید:

uv init my-project

(این دستور نه تنها پوشه پروژه، بلکه فایل تنظیمات و محیط مجازی رو برات می‌سازه).

2. ساخت محیط مجازی (اگر دستی خواستی):

uv venv

3. نصب سریع پکیج‌ها:

uv add numpy pandas

(به همین سادگی! uv خودش پکیج‌ها رو نصب و توی فایل‌های پروژه‌ات ثبت می‌کنه).

4. اجرای هر چیزی در محیط مجازی (بدون دردسرِ فعال‌سازی):

فقط کافیه اول دستورت uv run بذاری:

uv run python main.py

5. مدیریت پکیج‌های توسعه (dev):

اگر می‌خوای ابزارهایی مثل pytest یا black رو فقط برای زمان کدنویسی نصب کنی:

uv add --dev pytest

چرا از uv استفاده کنیم؟

اصلی‌ترین دلیلش اینه که uv بهت آزادی می‌ده. دیگه لازم نیست نگرانِ فعال کردن محیط مجازی (venv) باشی؛ uv هوشمندانه محیط پروژه رو می‌شناسه و دستوراتت رو دقیقا در جای درست اجرا می‌کنه.

نکته برای Jupyter: اگر از VS Code استفاده می‌کنی و نوت‌بوکت پکیج‌ها رو نمی‌شناسه، کافیه با uv add ipykernel پکیج کرنل رو نصب کنی و بعد در VS Code، اینترپتر (Interpreter) خودت رو روی مسیرِ ./.venv/bin/python قرار بدی.

ورژن کنترل با git

فرض کن داری روی یک پروژه عالی کار می‌کنی، کلی کد نوشتی و ناگهان... یک جای کار می‌لنگه! یا شاید هم تیمت بزرگ شده و همه باید روی یک پروژه با هم کار کنید. اینجا جاییه که Git وارد می‌شه؛ سیستم کنترل ورژن (Version Control System) که مثل یک کپی‌بردار حرفه‌ای از کارهای تو، همیشه حواسش به تغییرات پروژه هست.

Git بهت اجازه می‌ده:

* از کارهات نسخه پشتیبان داشته باشی.

* به عقب برگردی و نسخه‌های قبلی رو ببینی.

* با تیمت به صورت هماهنگ کار کنی.

* و کلی کارهای باحال دیگه!

جاهای مهمی که در Git باید بشناسی:

فکر کن داری یک گزارش آماده می‌کنی. Git هم سه تا «مکان» اصلی داره که باید بشناسیشون:

1. Working Directory (محیط کارت): جایی که داری کد می‌زنی و فایل‌هات رو مستقیماً تغییر می‌دی. همون پوشه پروژه‌ات!

2. Staging Area (منطقه آماده‌سازی): قبل از اینکه تغییرات رو «ذخیره» کنی، یک مرحله داری که انتخاب می‌کنی دقیقاً کدام تغییرات رو می‌خوای در «نسخه بعدی» ثبت کنی.

3. Local Repository (مخزن محلی): اینجا جاییه که «نسخه‌های ذخیره شده» (Commits) کارهات نگهداری می‌شه. هر بار که مراحل رو کامل کنی، یک نسخه جدید اینجا اضافه می‌شه.

دستورات کلیدی که باید یاد بگیری (با مثال‌های ساده):

1. git add - آماده‌سازی برای ذخیره:

فرض کن یک فایل جدید ساختی new_feature.py و یک فایل قبلی رو ویرایش کردی main.py. برای اینکه این تغییرات رو برای ذخیره بعدی آماده کنی، از git add استفاده می‌کنی:

* برای آماده کردن یک فایل خاص:

git add main.py

* برای آماده کردن همه فایل‌هایی که تغییر دادی:

git add .

2. git commit - ثبت نسخه جدید:

بعد از اینکه تغییرات رو با git add آماده کردی، وقتشه که یک «نسخه» ازشون بسازی و در مخزن محلی (Local Repository) ذخیره کنی:

git commit -m "describe the commit"

Example:
git commit -m "Add new features to main.py"

3. git status - ببین اوضاع چطوره؟

این دستور خیلی مهمه! بهت نشون می‌ده کدام فایل‌ها تغییر کردن، کدام‌ها آماده ذخیره (Staged) هستن و کدام‌ها هنوز اصلاً Git نمی‌شناسه:

git status

4. git diff - ببین چه تغییراتی دادی؟

می‌خوای بدونی دقیقا در فایلی که add کردی چه چیزهایی عوض شده؟ یا حتی قبل از add کردن؟

برای دیدن تغییرات آماده شده (Staged):

git diff --staged

برای دیدن تغییرات در Working Directory که هنوز add نکردی:

git diff

5. git push - فرستادن تغییرات به دنیای بیرون (مخزن راه دور):

فرض کن داری روی کامپیوتر خودت کار می‌کنی. ولی پروژه‌ات روی یک سرور دیگه (مثل GitHub, GitLab) هم هست (که بهش می‌گن Remote Repository). وقتی می‌خوای تغییرات ذخیره شده در کامپیوترت (Local Repository) رو بفرستی به اون سرور، از git push استفاده می‌کنی:

git push origin main

(یعنی: تغییرات رو از شاخه main کامپیوتر من، بفرست به شاخه main در مخزن راه دور با نام origin)

6. git pull - گرفتن آخرین تغییرات از دنیای بیرون:

برعکس push؛ وقتی هم‌تیمی‌هات تغییراتی رو به مخزن راه دور فرستادن، تو با git pull آخرین نسخه رو می‌گیری و روی کامپیوتر خودت اعمال می‌کنی (ادغام با working directory):

git pull origin main

7. git fetch - فقط نگاه کردن به تغییرات راه دور:

این دستور هم مثل pull هست، ولی با یک فرق مهم: تغییرات رو دانلود می‌کنه ولی روی کد فعلی تو اعمال نمی‌کنه. این بهت فرصت می‌ده که اول ببینی چه خبره، بعد تصمیم بگیری که آیا می‌خوای اون تغییرات رو با merge با کدت ترکیب کنی یا نه.

git fetch origin

8. git merge - ترکیب کردن تغییرات:

وقتی چند نفر روی یک پروژه کار می‌کنن، ممکنه شاخه‌های کاری (Branches) جداگانه‌ای داشته باشن. git merge بهت اجازه می‌ده تغییرات یک شاخه رو با شاخه دیگه ترکیب کنی. مثلاً بعد از اینکه از fetch استفاده کردی و خواستی تغییرات شاخه main رو با شاخه کاری خودت my-branch ترکیب کنی:

مثال:

فرض کن شما دو شاخه (Branch) داری:

• main: شاخه اصلی پروژه شما.

• my-feature: شاخه‌ای که داری روش یک قابلیت جدید کار می‌کنی.

شما در my-feature کدهایی اضافه کردی و حالا می‌خوای اون‌ها رو به main اضافه کنی. مراحل کار به صورت محلی (روی کامپیوتر خودت) این شکلیه:

1. برو به شاخه اصلی:

git checkout main

2. تغییرات شاخه قابلیت رو با main ترکیب کن:

git merge my-feature

نتیجه: اگر همه چیز خوب پیش بره، تغییرات my-feature به main اضافه می‌شه. اما اگر در همان قسمت از فایل‌ها، هم در main و هم در my-feature تغییری داده باشی، Git نمی‌دونه کدام رو نگه داره و با Conflict (تداخل) روبرو می‌شی که باید دستی حلش کنی.

git merge یک فرآیند محلی و مستقیم است. شما مستقیماً تغییرات را با هم ترکیب می‌کنید

9. git clone - برداشتن یک پروژه از راه دور:

اولین قدم برای کار روی یک پروژه که در GitHub یا جاهای مشابه هست، اینه که اون رو به کامپیوتر خودت بیاری:

git clone [آدرس مخزن]

# Example: 
git clone https://github.com/user/repo.git

10. git rm - حذف فایل‌ها (و آماده‌سازی برای ثبت حذف):

اگر یک فایل رو از Working Directory پاک کردی و می‌خوای این حذف رو هم Git ثبت کنه، باید از git rm استفاده کنی:

git rm old_file.txt

بعد مثل بقیه تغییرات، با git commit ثبتش می‌کنی.

Pull Request (PR) .11 در GitHub - یک درخواست برای ترکیب کردن (با بازبینی!)

Pull Request (که در پلتفرم‌هایی مثل GitHub، GitLab و Bitbucket وجود داره) یک ابزار مبتنی بر پلتفرم هست، نه فقط یک دستور Git.

PR زمانی استفاده می‌شه که شما می‌خواید تغییراتی رو که در یک شاخه (معمولاً در یک Remote Repository) ایجاد کردید، به شاخه دیگری (معمولاً شاخه اصلی) در همان مخزن اضافه کنید.

فرایند PR اینطوریه:

1. توسعه در شاخه جداگانه: شما یک شاخه جدید (مثلاً feature-x) در مخزن GitHub خودتون ایجاد می‌کنید و تغییراتتون رو در اون شاخه انجام می‌دید و commit می‌کنید.

2. Push کردن شاخه به GitHub:

git push origin feature-x

3. ایجاد Pull Request در GitHub: حالا به وب‌سایت GitHub می‌رید، به مخزن پروژه خودتون سر می‌زنید و گزینه‌ی “New Pull Request” رو می‌زنید. در اینجا:

• شاخه مبدأ (Base Branch) رو main انتخاب می‌کنید (شاخه مقصدی که می‌خواید تغییرات به اون اضافه بشه).

• شاخه مقصد (Compare Branch) رو feature-x انتخاب می‌کنید (شاخه‌ای که تغییرات شما در اون هست).

  4.بازبینی (Review) کد: این مهم‌ترین بخش PR هست! هم‌تیمی‌های شما یا خودتون می‌تونید کد اضافه شده رو بررسی کنید. نظراتشون رو بگن، پیشنهاد بدن، و شما می‌تونید بر اساس بازخوردها، تغییراتی اعمال کنید (با commit زدن و push کردن مجدد به همون شاخه feature-x).

  
  5. تأیید و Merge: وقتی همه از کد راضی بودن، کسی که دسترسی لازم رو داره (یا خود شما)، PR رو با شاخه main Merge می‌کنه. این Merge هم می‌تونه به صورت خودکار توسط GitHub انجام بشه.

نتیجه: تغییرات شما پس از بازبینی و تأیید، با merge (که در پشت صحنه توسط GitHub انجام می‌شه) به شاخه main اضافه می‌شه.

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