یوشا

وبگاه دست نوشته ها و تجربیات شخصی

یوشا

وبگاه دست نوشته ها و تجربیات شخصی

یوشا

دکتر مصطفی چمران: می گویند تقوا از تخصص لازمتر است، آنرا می پذیرم، اما می گویم: آنکس که تخصص ندارد و کاری را می پذیرد، بی تقواست!

بایگانی
تبلیغات
Blog.ir بلاگ، رسانه متخصصین و اهل قلم، استفاده آسان از امکانات وبلاگ نویسی حرفه‌ای، در محیطی نوین، امن و پایدار bayanbox.ir صندوق بیان - تجربه‌ای متفاوت در نشر و نگهداری فایل‌ها، ۳ گیگا بایت فضای پیشرفته رایگان Bayan.ir - بیان، پیشرو در فناوری‌های فضای مجازی ایران

 

ابتدا باید بگم استاندارد رسمی برای سبک ها و workflow ها وجود نداره، اما در این مقاله سعی می کنم از تجربیاتم، قوائد همگانی و معمولترین موارد موجود در Atlassian، Kernel و git manpage استفاده کنم...

 

مقالات مرتبط:

دانلود، نصب و راه اندازی Git در ویندوز

ساخت SSh key در ویندوز

ساخت SSh key در لینوکس

کدام پروتکل: //:git یا //:ssh یا //:https

 

فهرست مندرجات:

  • Branch / انشعاب
  • Commit
  • تنظیم / config
  • گوناگون

 

  • Branch / انشعاب

1- همیشه هنگام نامگذاری انشعاب(Branch) از عناوین کوتاه و توصیفی استفاده کنید و درصورت لزوم از خط فاصله - برای جداسازی آیتم ها کمک بگیرید.

مثال: feature-logsystem, release-2.0.4a, hotfix-3.0.2-12, stable-1.0.0

نکته: می تونید از اسلش / هم استفاده کنید اما هنگام بکار گرفتن بعضی سرویس ها(CI) و rename کردن با دردسر مواجه میشید.

 

2- اگر بیش از 1 نفر بر روی یک feature مشابه کار می کنند، برای تفکیک بهتر هر انشعاب باید از نام افراد در کنار نام feature مورد نظر استفاده بشه.

مثال: feature-logger-ahmad, feature-logger-ali, feature-logger-mina

 

3- نام انشعاب نباید حاوی کاراکترهای ^ .. ~ \ : باشه.

 

4- همیشه برای گروه بندی Branch ها از عناوین همگانی مثل develop, feature, hotfix, poc, master/mainline, junk/experimental استفاده کنید. به این صورت:

- develop: این گروه از انشعاب معمولاً محل نگهداری آخرین تغییرات هستش که توسط توسعه دهنگان/committers ثبت میشه. همه توسعه دهندگان آخرین تغییراتشوت رو از نسخه کپی/local به این انشعاب ارسال می کنن.

نامگذاری:

develop یا dev

- feature: این گروه از انشعاب مخصوص ثبت امکانات جدید و refactory های وسیع هستش. به اینصورت که از انشعاب develop گرفته میشه، کدها نوشت میشن و بعد از بازبینی/review و تایید اولیه کدها، با انشعاب develop مجدداً الحاق میشه. و نهایتاً هم حذف میشه.

قالب نامگذاری:

feature-<title>

مثال: feature-logsystem, feature-calculator, feature-playerkick

 

- stable / release: این گروه از انشعاب مخصوص انتشار نهایی و نسخه پایدار هستش که مورد استفاده مشتریان قرار میگیره. به اینصورت که بعد از انجام همه fix ها، اعمال feature ها، code review ها و تست ها، از انشعاب develop یا master گرفته میشه و یک انشعاب جدید با نام گروه release/stable بهمراه شماره version جدید ایجاد میشه. (توسط اتوماسیون build یا دستی) نهایتاً زمانی رو هم برای End Of Life ش تعیین می کنن.

قالب نامگذاری:

stable-<version>[<state>]
یا
release-<version>[<state>]

مثال: stable-1.5.0, stable-5.5.8a, release-6.0.4b, release-7.8.3

 

- master / mainline: این گروه از انشعاب استفاده های مختلفی داره و به شیوه های گوناگون توسط founder مخزن/پروژه مدیریت میشه. و هر commit ای که بر روی این انشعاب صورت بگیره مستقیماً merge میشه... همچنین معمولاً همگام با انشعاب develop جلو میره:

1- این نوع انشعاب می تونه برای production و الحاق با آخرین انشعاب release/stable باشه.

2- این نوع انشعاب می تونه فقط برای مالک پروژه باشه.

3- این نوع انشعاب می تونه جایگزین انشعاب develop باشه.

4- این نوع انشعاب می تونه deployable و منبع clone برای همه انشعابات باشه.

نامگذاری:

master یا mainline

نکته: در صورت وجود دو انشعاب master و develop، انشعاب master برای production(یا همون release) استفاده میشه و انشعاب develop برای development(یا همون alpha/beta) استفاده میشه.

 

hotfix: این گروه از انشعاب مخصوص رفع باگهای فوریتی(critical/major/blocker) هستش که بعد از انتشار stable/release پروژه کشف میشن. به اینصورت که بعد از گزارش/کشف باگ و تاییدش، یک انشعاب از گروه stable/release نسخه باگی گرفته میشه و با نام گروه hotfix بهمراه شماره version انتشار و شماره باگ ایجاد میشه. و بعد از رفع باگ مجدداً با انشعاب develop الحاق میشه. نهایتا انشعاب hotfix ش هم حذف میشه.

قالب نامگذاری:

hotfix-<version>-<issue#>

مثال: hotfix-1.3.4-77, hotfix-5.5.2-issue998, hotfix-2017-341

 

poc: یا همون Prove of Concept گروهی از انشعاب هستش که مخصوص اثبات چیزی یا پروپوزال یک تغییر هستش. به این صورت که بعد از طراحی یک PoC، انشعابی از develop گرفته میشه و با نام گروه poc بهمراه عنوان طرح ایجاد میشه.

قالب نامگذاری:

poc-<title>

 

junk/experimental: این گروه از انشعاب مخصوص آزمایش هستش و معمولاً بجز سازندش باهاش کاری ندارن.

قالب نامگذاری:

experimental-<title>

توجه: Code review بمعنی Test نیست، و Code reviewer ها Tester نیستند. وظیفه اصلی افراد Code reviewer بازبینی کدها از نظر نظم، خوانایی، رعایت اصول اولیه کدنویسی، پیروی از قواید کدنویسی گروه و... هستش. و با هر PR(یا Pull request) ای که انجام میگیره خودشون وارد کار میشن و کدها رو بررسی بعد تایید/رد می کنن.

 

5- همیشه Git رو برای push کردن انشعاب جاری/current تنظیم سراسری(default) کنید. تا به اشتباه انشعاب دیگر رو برای server ارسال نکنید:

git config --global push.default current

 

6- دلیل خطای warning: remote HEAD refers to nonexistent ref, unable to checkout، نداشتن انشعاب master در مخزنی هست که قراره checkout ش کنید... پس باید نام یک انشعاب رو دقیقاً ذکر کنید: git checkout YourBranchName

 

  • Commit

1- اصولاً هر commit باید حاوی یک تغییر منطقی باشه. نه اینکه چند تغییر در انواع مختلف انجام بگیره و همه در یک commit ثبت بشه!

 

2- هر یک fix یا add یا remove یا improve باید فقط در یک commit ثبت بشه.

 

3- یک تغییر منطقی یا یک feature جدید رو باید فقط در یک commit ثبت کنید.

 

4- طول پیامهای commit رو کوتاه و حداکثر در 50 کاراکتر در هر خط بنویسید.

 

5- در پیام commit از واژه های Remove, Update, Fix, Add استفاده کنید و نه Fixed Added Removed و...

همچنین برای تشخص بهتر patch و فعال شدن trigger های موجود در سیستم(مثل بسته شدن خودکار یک issue) می تونید از شماره bug/issue در داخل پیام commit استفاده کنید.

مثال: Fix bug #2, Add README, Remove pom.xml, Fix #23, Fix #552

 

6- هنگام نوشتن پیامهای طولانی برای commit، باید عنوان پیام رو از بدنه پیام با یک پاراگراف خالی جدا کنید.

 

7- اگر commit B به commit A وابستگی داره، باید در پیام commit اینرو صراحتاً اعلام کنید... (می تونید از SHA1 کامیت هدف استفاده کنید)

برای نمونه اگر commit B یک باگ رو در commit A رفع میکنه، باید در پیام commit B اعلام کنید که رفع باگ commit A رو انجام میده.

 

8- همیشه برای پیامهای commit از فعل حال استفاده کنید.

Fix issue #343
Remove unused variables
#21 - Fix login bug.
Add README.txt

 

9- برای فهرست بندی پیام commit با bullet می تونید از کاراکتر ستاره * استفاده کنید.

 

  • تنظیم / config

1- مطمعن بشید که name و email شما در فایل gitconfig موجود در دایرکتوری USER یا HOME درج شده باشه.

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

git config --global user.name "YOUR FULL NAME"
git config --global user.email "YOUR-EMAIL-ADDRESS"

 

2- برای حذف انشعاب های local که دیگر در remote موجود نیستند، یکی از روش های زیر رو دنبال کنید:

- یکبار دستور git config --global fetch.prune true رو در کنسول بزنید تا همیشه بصورت خودکار انجام بشه.

نکته: این قابلیت با هربار انجام fetch یا pull فعال می شه.

- یا هر زمان که لازم بود دستور git remote prune origin رو بزنید.

 

3- برای جلوگیر از commit شدن پیام "Merge branch 'master' of domain:username/Project" هنگام merge، دستور زیر رو بزنید و بصورت Global تنظیمش کنید:

git config --global branch.autosetuprebase always

یا هنگام pull از پارامتر --rebase استفاده کنید:

git pull --rebase

 

4- تنظیم Git مختص حوزه system, global یا project:

حوزه project: تنظیمات این حوزه فقط مختص هر پروژه هستش. فایل این حوزه داخل پوشه پروژه در مسیر .git/config قرار داره و توسط دستور زیر هم میتونه اعمال بشه:

git config user.name "Yousha Aleayoub"

حوزه global: تنظیمات این حوزه مختص همه پروژه های کاربر جاری هستش. فایل این حوزه داخل پوشه USER یا HOME در مسیر ~/.gitconfig. یا X:\Users\<USERNAME>\ قرار داره و توسط دستور زیر هم میتونه اعمال بشه:

git config --global user.name "Yousha Aleayoub"

حوزه system: تنظیمات این حوزه فقط مختص همه پروژه ها و همه کاربران هستش. فایل این حوزه داخل پوشه برنامه Git در مسیر /etc/gitconfig قرار داره و توسط دستور زیر هم میتونه اعمال بشه:

git config --system user.name "Yousha Aleayoub"

 

  • گوناگون

1- هنگام merge انشعاب، اگر در اون انشعاب بیشتر از یک commit وجود داره، اون رو توسط پارامتر --no-ff الحاق/merge کنید. با اینکار history انشعاب و ساختارش هم حفظ میشه:

git merge --no-ff <branch-name>

یا برای همیشه سراسری تنظیمش کنید:

git config --add merge.ff false

 

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

 

3- یادتون باشه که از ابزار مفید Annotated Tag گیت حتماً استفاده کنید:

git tag -a <version>
یا
git tag -a <version> <commit Id>

 

4- برای راه اندازی Git در IDE/ویرایشگر:

- اگر از Eclipse استفاده می کنید، باید پلاگین eGit رو دانلود کنید.

- اگر از IntelliJ استفاده می کنید، بصورت native این قابلیت رو داراست.

- اگر از NetBeans 7.1 و جدیدتر استفاده می کنید، بصورت native این قابلیت رو داراست.

- اگر از NetBeans 7 و قدیمی تر استفاده می کنید، باید پلاگین Git Versioning System Support یا پلاگین nbGit رو دانلود کنید.

- اگر از NetBeans 6.7 استفاده می کنید، باید پلاگین nbGit رو دانلود کنید.

- اگر از Vim استفاده می کنید، باید پلاگین fuGitive رو دانلود کنید. 

- اگرم از Emac استفاده می کنید، باید پکیج git.el رو نصب کنید.

 

5- برای گروه بندی اعضا و شرکت کنندگان در یک پروژه به این صورت میتونید عمل کنید:

- گروه Maintainer: معمولاً مالک و founder پروژه هستند که به کل پروژه دسترسی کامل دارن. این افراد دسترسیها، پچ ها، انشعابات، merging، کامیت ها، CI ها، Developer ها، Code reviewer ها و... رو مدیریت می کنن. (زیر مجموعه ها: core maintainer, subsystem maintainer, topic maintainer)

- گروه Developer: افرادی هستند که به بخش هایی از پروژه دسترسی کامل دارن و معمولاً Pull request ها، new feature ها، انشعابات و Commiter ها رو مدیریت می کنن. (زیر مجموعه ها: Head/Lead developer, Senior developer, Junior Developer)

- گروه Committer: افرادی هستند که فقط به سورس فایلها دسترسی دارند و معمولاً پچ، رفع باگ و کامیت ثبت می کنن و Pull request میفرستن.

- گروه Code reviewer: افرادی هستند که commit های هر Pull request رو از نظر نظم و قواید و خوانایی بررسی می کنن. و PR رو بر اساس نتیجه بررسی رد یا تایید می کنن.

- گروه Beta Tester: افرادی هستند که پروسه آزمون بتا و آزمایش های کاربری رو روی محصول اولیه(آلفا) انجام میدن تا سلامت و کارایی محصول تضمین بشه. (این آزمایش ها در یک پروسه چند مرحله ای و بصورت چرخشی انجام می گیره)

- گروه Contributor: کاربران عادی هستند که غیر مستقیم با کارمندان و تیم پروژه همکاری می کنن. مثل گزارش باگ، ارسال بازخوردهای سازنده، راهنمایی کاربران، ویرایش مستندات، بومی سازی متون و...

 

6- توجه داشته باشید که HEAD با deattached HEAD با ORIG_HEAD متفاوته!

HEAD در واقع reference ای به آخرین commit در انشعاب جاری(checkout شده) هستش. deattached HEAD یک reference ای به یک commit خاص یا Tag هستش و معمولاً هم استفاده نمیشه. و ORIG_HEAD بک آپ رفرنسی به HEAD قبل از تغییرات هستش.

 

7- هرگز از پروتکل HTTP استفاده نکنید! این پروتکل بخاطر برخی کمبود ها و ضعفهای امنیتی تقریباً منسوخ شده و هیچ سروری ازش استفاده نمی کنه و خود تیم Git هم ردش میکنه.

 

9- نکته جزیی: توسط فایل .gitignore میتونید به Git اعلام کنید که چه فایلهایی رو هنگام fetch, pull, push, commit نادیده بگیره.

 

10- همیشه یک backup از فایل gitconfig و دایرکتوری .ssh تون تهیه کنید که هنگام تعویض سیستم عامل مجبور به تنظیم مجددشون نباشید.

نکته: این فایلها در لینوکس داخل /HOME/.ssh/ و در ویندوز 7/8 داخل C:\Users\<USERNAME>\ و در ویندوز XP داخل C:\Documents and Settings\<USERNAME>\ قرار گرفتن.

 

12- همیشه مناسب ترین پروتکل رو برای کار با Git بکار بگیرید!

 

13- نکته جزیی: Fork همون Clone هستش، منتها بدلیل اینکه داخل سرور و بواسطه وب در اکانت شما انجام میگیره، تغییر واژه داده... درواقع با انجام Fork، یک Clone از پروژه با تمام دسترسی هاش در سرور در اختیار شما قرار میگیره. (و بنظرم بکار گیری واژه Fork اشتباست، وقتی خود Git واژه رسمی Clone رو براش درنظر گرفته)

 

14- هنگام ساخت SSh key برای Git، یادتون باشه فایل id_rsa.pub، فایل کلید عمومی هست. یعنی این کلید رو در سرور/remote ای که قراره بهش متصل بشید آپلود میکنید (که به شما گفته میشه کجا و چگونه). اما فایل id_rsa، فایل کلید خصوصی هست. پس این فایل باید در کامپیوتر شما بمونه!

 

15- ویندوز: در صورت بروز خطای gpg: cannot open tty 'no tty': No such file or directory هنگام استفاد از برنامه Git-GUI بهمراه GPG، بدونید که TTY سیستم توسط Git-GUI اشغال شده و GPG قادر به ارسال فرمان به TTY نیست... باید از Git-BASh استفاده کنید.

 

16- دستور git pull در واقع ترکیبی از دستور git fetch و git merge هستش. به اینصورت که ابتدا دستور git fetch اجرا میشه، سپس رفرنس FETCH_HEAD بروز میشه و نهایتاً دستور git merge FETCH_HEAD اجرا میشه.

نکته: FETCH_HEAD رفرنسی به آخرین انشعاب remote ای هست که fetch شده. MERGE_HEAD رفرنسی به commit/commit ها ای هستش که با انشعاب جاری(checkout شده) merge شده. 

 

17- درصورت بروزرسانی فایل gitignore یا عدم کارکرد صحیح این فایل، ابتدا تغییرات اعمال شده رو Commit کنید و بعد دستورات زیر رو در مخزنتون بزنید:

git rm -r --cached .
git add .
git commit -m "Fix untracked files." 

 

19- دلیل خطای You do not have write access to this repository، اغلب عدم یکسان بودن SSh key سیستم شما با هاست remote هستش یا استفاده از یک SSh key در چندین اکانت هاست remote.

 

20- درصورت بروز خطای Permission denied (publickey) هنگام pull کردن کافیه مقدار PubkeyAcceptedKeyTypes ssh-dss رو به فایل config موجود در پوشه .ssh اضافه کنید.

 

مفهوم CI یا Continuous integration در برنامه‌نویسی، یعنی مجموعه روش‌هایی که باعث حفظ انسجام کد می‌شود و از به‌هم‌ریختگی کد جلوگیری می‌کند. این روش‌ها مبتنی بر build کردن مداوم پروژه پس از هر تغییر در کد توسط برنامه‌نویسان و اجرای تست کیس‌های برنامه است. به عنوان مثال هر زمان که یک کامیت توسط توسعه‌دهنده بر روی مخزن پروژه push شود همهٔ تست‌ها اجرا می‌شود تا بتوان اطمینان حاصل نمود که همهٔ قسمت‌های پیشین کد و قسمت‌های تازه نوشته‌شده با یک‌دیگر سازگاری دارد و درست کار می‌کند.

 

سایت رسمی Git

مستندات رسمی Git

مرجع ماکروها و دستورات Git

۹۶/۱۲/۱۷

نظرات (۰)

هیچ نظری هنوز ثبت نشده است
کاربران بیان میتوانند بدون نیاز به تأیید، نظرات خود را ارسال کنند.
اگر قبلا در بیان ثبت نام کرده اید لطفا ابتدا وارد شوید، در غیر این صورت می توانید ثبت نام کنید.
شما میتوانید از این تگهای html استفاده کنید:
<b> یا <strong>، <em> یا <i>، <u>، <strike> یا <s>، <sup>، <sub>، <blockquote>، <code>، <pre>، <hr>، <br>، <p>، <a href="" title="">، <span style="">، <div align="">