در کار با Git، رعایت مجموعه‌ای از قوانین و اصول ضروری است که در ادامه به آن‌ها اشاره شده است:
کار را در برنچ feature انجام دهید
چرا
کار بر روی برنچ feature باعث می‌شود تمام تغییرات به صورت مجزا و در یک برنچ اختصاصی اعمال شوند. این روش به شما این امکان را می‌دهد که چندین Pull Request ارسال کنید بدون اینکه دچار سردرگمی شوید. همچنین، می‌توانید کد خود را مکرراً به‌روزرسانی کنید، بدون اینکه برنچ اصلی را با کدهای ناپایدار و ناتمام آلوده کنید. (توضیحات بیشتر … ↗)
از برنچ develop انشعاب بگیرید
چرا
با انشعاب از برنچ develop، می‌توانید مطمئن باشید که کد موجود در برنچ master همیشه پایدار و قابل build است و معمولاً می‌توان آن را مستقیماً برای انتشار/releases استفاده کرد (البته این رویکرد ممکن است برای برخی از پروژه‌ها بیش از حد یا فراتر از نیاز باشد).
هرگز به برنچ develop یا master مستقیماً Push نکنید، بلکه یک درخواست Pull Request ایجاد کنید.
چرا
هرگز به برنچ‌های develop یا master مستقیماً Push نکنید. به جای آن، یک Pull Request ایجاد کنید. این کار به اعضای تیم اطلاع می‌دهد که یک feature تکمیل شده است و امکان بررسی کد توسط سایرین و بحث درباره تغییرات را فراهم می‌کند.
قبل از Push کردن یک فیچر و ایجاد Pull Request، ابتدا برنچ develop محلی/local خود را به‌روزرسانی کنید و یک ری‌بیس (Rebase) تعاملی انجام دهید.
چرا
قبل از ارسال Pull Request، برنچ develop یا master محلی خود را به‌روزرسانی کرده و Rebase تعاملی انجام دهید. Rebase تغییرات محلی شما را به بالای تاریخچه انتقال می‌دهد و از ایجاد Commitهای غیرضروری جلوگیری می‌کند. این کار باعث تمیز و مرتب شدن تاریخچه Commitها می‌شود. (توضیحات بیشتر … ↗)
تعارضات احتمالی را در حین rebase برطرف کنید و سپس Pull Request ایجاد کنید. (این کار به شفافیت و کیفیت کد کمک می‌کند.)
برنچ‌های feature ایجاد شده، پس از اتمام کار و ادغام باید حذف شوند (در local و remote).
چرا
حذف برنچ‌های ادغام شده باعث می‌شود لیست برنچ‌ها شلوغ نشود و هر برنچ تنها یک بار به برنچ اصلی (master یا develop) ادغام شود. برنچ‌های feature فقط باید تا زمانی که کار هنوز در حال انجام است، وجود داشته باشند.
قبل از ایجاد Pull Request، مطمئن شوید که برنچ feature شما به درستی build می‌شود و تمامی تست‌ها (از جمله بررسی سبک و استایل کدنویسی) موفقیت‌آمیز هستند.
چرا
زمانی‌که شما تصمیم دارید کد خود را به یک برنچ stable اضافه کنید، اگر تست‌های برنچ feature محلی/local ناموفق باشند، احتمال زیادی وجود دارد که build برنچ مقصد نیز با خطا مواجه شود. علاوه بر این، قبل از ایجاد درخواست Pull Request، ضروری است که بررسی سبک و استایل کدنویسی انجام گردد. زیرا این کار باعث بهبود خوانایی و استانداردسازی کد می‌شود و از شکست احتمالی build برنچ مقصد جلوگیری می‌کند.
فایل .gitignore فایل‌ها و دایرکتوری‌هایی که نباید به مخزن remote ارسال شوند (مانند فایل‌های سیستمی و تنظیمات ویرایشگرها) را مستثنی می‌کند. این کار از ارسال فایل‌های غیرضروری جلوگیری می‌کند.
از برنچ‌های develop و master محافظت کنید.
چرا
این کار از برنچ‌های آماده برای production در برابر دریافت تغییرات غیرمنتظره و غیرقابل بازگشت محافظت می‌کند. توضیحات بیشتر را برای GitHub ↗, Bitbucket ↗ و GitLab ↗ بخوانید.
برای یک پروژه جدید، یک مخزن گیت (Git repository) را در پوشه پروژه ایجاد کنید. برای ویژگی‌ها یا تغییرات بعدی، دیگر نیازی به انجام این مرحله نیست.
cd <project directory>git init
sh
یک شاخه جدید برای توسعه یک feature یا رفع یک bug ایجاد کنید و به آن سوئیچ کنید.
git checkout -b <branchname>
sh
اعمال تغییرات در فایل‌ها و ثبت آن‌ها
git add <file1> <file2> ...git commit
sh
چرا
با دستور git add <file1> <file2> ... باید تنها فایل‌هایی را اضافه کنید که یک تغییر کوچک و منسجمی را تشکیل می‌دهند.
دستور git commit یک ویرایشگری را باز می‌کند که در آن می‌توانید متن کامیت خود را با جداسازی بخش موضوع (subject) از بدنه (body) بنویسید.
در بخش بعدی درباره‌ی آن توضیح بیشتری داده شده است.
برنچ لوکال خود را با مخزن remote همگام‌سازی کنید تا تغییرات جدید را دریافت کنید.
git checkout developgit pull
sh
چرا
این کار به شما این فرصت را می‌دهد که با conflictها در سیستم خود در حین rebasing و پیش از ارسال Pull Request مواجه شوید، به جای آنکه یک درخواست Pull Request ایجاد کنید که حاوی conflict و تضاد باشد.
برنچ feature خود را با استفاده از interactive rebase با آخرین تغییرات از برنچ develop، به‌روزرسانی کنید.
git checkout <branchname>git rebase -i --autosquash develop
sh
چرا
با گزینه‌ی --autosquash می‌توانید تمام کامیت‌های خود را در برنچ feature در یک کامیت ترکیب کنید تا تاریخچه مرتب‌تری داشته باشید. زیرا هیچ‌کس تمایل ندارد برای یک ویژگی، چندین کامیت پراکنده در برنچ develop داشته باشد. (توضیحات بیشتر … ↗)
اگر با conflictای مواجه شدید، آن را برطرف کنید ↗ و rebase را ادامه دهید، در غیر این صورت، می‌توانید این مرحله را نادیده بگیرید.
git add <file1> <file2> ...git rebase --continue
sh
برنچ خود را پس از ری‌بیس push کنید. از آنجا که rebase تاریخچه‌ی برنچ را تغییر می‌دهد، Git جلوی Push عادی را می‌گیرد؛ بنابراین باید از -f برای اعمال اجباری تغییرات استفاده کنید. اگر افراد دیگری نیز روی برنچ شما کار می‌کنند، بهتر است از گزینه کمتر مخرب --force-with-lease استفاده کنید.
git push -f
sh
چرا
وقتی که rebase انجام می‌دهید، گیت تاریخچه برنچ feature محلی را تغییر می‌دهید. در نتیجه، گیت جلوی Push عادی با استفاده از دستور git push را می‌گیرد. بنابراین باید از فلگ -f یا --force برای اعمال اجباری تغییرات استفاده کنید. (توضیحات بیشتر … ↗)
پس از Push کردن برنچ، یک Pull Request خود را ایجاد کنید.
یک نفر از اعضای تیم یا مسئول بررسی کد، درخواست Pull Request را پس از بررسی، پذیرفته و آن را ادغام (Merge) کند، درنتیجه این درخواست بسته خواهد شد.
در صورت اتمام کار،برنچ feature محلی خود را حذف کنید.
git branch -d <branchname>
sh
جهت حذف تمام برنچ‌های محلی که دیگر در مخزن remote وجود ندارند، از دستور زیر استفاده کنید. (برای تمیز نگه‌داشتن محیط توسعه و حذف برنچ‌های قدیمی)
git fetch -p && for branch in `git branch -vv --no-color | grep ': gone]' | awk '{print $1}'`; do git branch -D $branch; done
داشتن راهنمای مناسب و پایبندی به آن برای نوشتن پیام‌های کامیت، همکاری با دیگران و نگهداری پروژه را بسیار ساده‌تر می‌کند. در اینجا چند قانون کلی وجود دارد (منبع ↗):
موضوع (subject) را از بدنه (body) جدا کنید و بین این دو بخش یک خط خالی بگذارید.
چرا
گیت به اندازه کافی هوشمند است که خط اول پیام کامیت شما را به‌عنوان خلاصه تشخیص دهد. اگر به‌جای استفاده از git log از git shortlog استفاده کنید، فقط این خط اول (خلاصه) را به همراه شناسه کامیت خواهید دید.
طول خط موضوع (subject) را تا 50 کاراکتر محدود نگه دارید و بدنه‌ی پیام (body) را حداکثر در 72 کاراکتر قرار دهید.
چرا
این کار باعث می‌شود کامیت‌ها تا حد ممکن متمرکز و خوانا باشند؛ نیازی به طولانی‌نویسی نیست. (توضیحات بیشتر ↗)
حرف اول موضوع (subject) را با عبارت بزرگ (Capitalize) شروع کنید.
به جای نوشتن پیام‌هایی که فقط بیانگر یا توصیف‌کننده کاری هستند، بهتر است متن کامیت را به عنوان یک دستورالعمل در نظر بگیرید تا مشخص کنند که پس از ادغام کامیت در مخزن، چه کاری قرار است انجام شود. (توضیحات بیشتر … ↗)
از قسمت بدنه (body) برای توضیح چرایی و چیستی کار انجام‌شده استفاده کنید، نه چگونگی انجام آن.
