آموزش کار با Git و GitHub
در درس گذشته، با بهترین روش‌ها برای ساختن کامیت‌های خوب آشنا شدیم. اکنون زمان آن است که یک قدم به عقب برگردیم و به تصویر بزرگتر، یعنی جریان کاری کلی در گیت، نگاه کنیم. یک جریان کاری سالم فراتر از کامیت‌های تمیز است و شامل نحوه مدیریت برنچ‌ها، تعامل با همکاران و حفظ سلامت کلی مخزن می‌شود.
این درس مجموعه‌ای از مهم‌ترین «بایدها» و «نبایدها» را ارائه می‌دهد که به شما کمک می‌کند از اشتباهات رایج دوری کرده و به شیوه‌ای موثر و حرفه‌ای، به خصوص در محیط‌های تیمی، از گیت استفاده کنید.
رعایت این نکات به شما کمک می‌کند تا یک مخزن تمیز و قابل مدیریت داشته باشید.
هرگز، تحت هیچ شرایطی، مستقیماً روی برنچ اصلی (مانند main یا master) کار نکنید. برنچ اصلی شما باید همیشه نماینده یک نسخه پایدار و قابل استقرار از پروژه باشد. برای هر قابلیت جدید، هر رفع باگ، یا حتی هر آزمون و خطای کوچکی، یک برنچ جدید با نام توصیفی بسازید (مثلاً feature/user-login یا fix/header-bug). این کار تغییرات شما را ایزوله کرده، از شکستن کد اصلی جلوگیری می‌کند و فرآیند بازبینی کد (Code Review) را از طریق Pull Request ها بسیار ساده‌تر می‌سازد.
قبل از اینکه تغییرات محلی خود را به یک برنچ اشتراکی push کنید، همیشه ابتدا آخرین تغییرات را از سرور دریافت (pull) کنید. این کار به شما اجازه می‌دهد تا هرگونه تداخل (conflict) احتمالی را روی سیستم خودتان حل کنید، نه روی مخزن عمومی. بهترین روش برای این کار، استفاده از دستور git pull --rebase است که تاریخچه را خطی و تمیز نگه می‌دارد و از ایجاد کامیت‌های ادغام (merge commit) غیرضروری جلوگیری می‌کند.
این نکته به قدری مهم است که ارزش تکرار دارد. یکی از اولین کارهایی که در یک پروژه جدید انجام می‌دهید، باید ساختن یک فایل .gitignore جامع باشد. این کار از ورود فایل‌های ناخواسته (مانند لاگ‌ها، پوشه node_modules، فایل‌های سیستم‌عامل و...) به تاریخچه مخزن برای همیشه جلوگیری می‌کند و حجم مخزن شما را پایین نگه می‌دارد.
اجتناب از این اشتباهات شما را از مشکلات بزرگ در آینده نجات می‌دهد.
این اولین و بزرگترین گناه در کار با گیت است. از دستوراتی که تاریخچه را بازنویسی می‌کنند (مانند git rebase و git reset) هرگز روی برنچ‌های اشتراکی و عمومی (مانند main یا develop) استفاده نکنید. این کار باعث ایجاد نسخه‌های متناقض از تاریخچه برای همکاران شما شده و منجر به تداخل‌های پیچیده و سردرگمی شدید در تیم می‌شود. این ابزارها فقط برای تمیز کردن تاریخچه محلی و خصوصی شما قبل از اشتراک‌گذاری آن هستند.
گیت برای مدیریت فایل‌های متنی (مانند سورس‌کد) طراحی شده و در این کار فوق‌العاده بهینه عمل می‌کند. اما در مدیریت فایل‌های باینری بزرگ (مانند ویدیو، تصاویر حجیم، فایل‌های نصبی، خروجی دیتابیس) بسیار ضعیف است. گیت با هر تغییر، یک کپی کامل از فایل باینری را ذخیره می‌کند که این کار به سرعت حجم مخزن را به شدت افزایش داده و فرآیند clone کردن را برای همه اعضای تیم عذاب‌آور می‌کند. برای مدیریت این نوع فایل‌ها، از ابزارهای تخصصی مانند Git LFS (Large File Storage) یا سرویس‌های ذخیره‌سازی ابری استفاده کنید.
هرگز کلیدهای API، رمزهای عبور، توکن‌ها، گواهی‌های خصوصی یا هر نوع اطلاعات حساس دیگری را مستقیماً در مخزن خود کامیت نکنید. به یاد داشته باشید که تاریخچه گیت دائمی است و حتی اگر شما فایلی را در یک کامیت بعدی «حذف» کنید، آن فایل همچنان در تاریخچه قبلی قابل دسترسی است. برای مدیریت اطلاعات حساس، از فایل‌های .env (که باید همیشه در .gitignore باشند) یا سرویس‌های مدیریت اسرار (Secrets Management) استفاده کنید.