۶.Git commit

این شاید پراستفاده‌ترین دستور Git باشد. هنگامی که به یک نقطه خاص در توسعه رسیدیم، می‌خواهیم تغییرات خود را ذخیره کنیم (ممکن است پس از انجام یک وظیفه یا رفع یک مشکل خاص).

دستور Git commit مانند قرار دادن یک نقطه کنترل در فرآیند توسعه است که در صورت نیاز می‌توانید در آینده به آن بازگردید.

همچنین باید یک پیام کوتاه بنویسیم تا توضیح دهیم که چه چیزی را در کد توسعه داده یا تغییر داده‌ایم.

git commit -m "commit message"

مهم: دستور git commit تغییرات شما را فقط به صورت local ذخیره می‌کند.

۷.Git push

بعد از commit کردن تغییرات خود، چیزی که باید بعد از آن انجام دهید، ارسال تغییرات به سرور است. دستور git push، commit های شما را به مخزن میفرستد.

git push <remote> <branch-name>

با این حال، اگر شاخه شما به تازگی ایجاد شده است، شما همچنین باید شاخه را با دستور زیر آپلود کنید:

git push --set-upstream <remote> <name-of-your-branch>

یا

git push -u origin <branch_name>

مهم: دستور git push فقط تغییراتی را که commit شده‌اند، آپلود می‌کند.

۸.Git pull

دستور git pull برای دریافت به‌روزرسانی‌ها از مخزن استفاده می‌شود. این دستور ترکیبی از دستورات git fetch و git merge است، یعنی وقتی از git pull استفاده می‌کنیم، به‌روزرسانی‌ها را از مخزن دریافت می‌کند (git fetch) و به‌صورت فوری تغییرات جدید را در local شما اعمال می‌کند (git merge).

git pull <remote>

این عملیات ممکن است باعث ایجاد تداخل‌ها شود که باید به صورت دستی حل شوند.

۹.Git revert

گاهی اوقات نیاز داریم تغییراتی که اعمال کرده‌ایم را لغو کنیم. روش‌های مختلفی برای لغو تغییرات به صورت local یا remote (بسته به نیازمندی‌های ما) وجود دارد، اما باید با دقت از این دستورات استفاده کرد تا از حذف ناخواسته جلوگیری کنیم.
یک روش ایمن برای لغو کامیت‌های ما استفاده از دستور git revert است. برای مشاهده تاریخچه کامیت‌های ما، ابتدا باید از دستور git log --oneline استفاده کنیم.

سپس فقط باید کد هش را در کنار کامیتی که می‌خواهیم لغو کنیم مشخص کنیم.

git revert <hash-code>

دستور git revert تغییرات کامیت مورد نظر را لغو می‌کند، اما یک کامیت جدید بدون حذف کامیت قبلی ایجاد می‌کند.
مزیت استفاده از git revert این است که تاریخچه کامیت‌ها را تغییر نمی‌دهد. این بدان معنی است که هنوز می‌توانید تمامی کامیت‌ها را در تاریخچه خود مشاهده کنید، حتی کامیت‌هایی که لغو شده‌اند.

یک اقدام ایمن دیگر این است که همه چیز در سیستم local ما اتفاق می‌افتد مگر اینکه آنها را به مخزن remote آپلود کنیم. به همین دلیل استفاده از git revert ایمن‌تر است و روش ترجیحی برای لغو کامیت‌هاست.
۱۰. Git merge

وقتی توسعه در شاخه‌ی خود را کامل کرده‌اید و همه چیز به خوبی کار می‌کند، مرحله‌ی نهایی ادغام شاخه با شاخه‌ی اصلی (dev یا master) است. این کار با استفاده از دستور git merge انجام می‌شود.

در اصل، git merge شاخه‌ شما را همراه با تمام کامیت‌هایش به شاخه‌ی dev (یا master) ادغام می‌کند. مهم است که به یاد داشته باشید که ابتدا باید در شاخه‌ی مورد نظر که می‌خواهید با شاخه‌ی ویژگی خود ادغام کنید، حضور داشته باشید.

به عنوان مثال، وقتی می‌خواهید شاخه‌ی ویژگی خود را با شاخه‌ی dev ادغام کنید:

ابتدا باید به شاخه‌ی dev تغییر شاخه دهید.

git checkout dev

قبل از ادغام، باید شاخه dev خود را به‌روز کنید.

git fetch

در نهایت، می‌توانید شاخه‌ی خود را به شاخه‌ی dev ادغام کنید.

git merge <branch-name>

راهنمایی: مطمئن شوید که شاخه dev شما دارای آخرین نسخه است قبل از ادغام شاخه‌هایتان، در غیر این صورت ممکن است با تداخل‌ها یا مشکلات دیگری روبه‌رو شوید.

این ده دستور Git رایج‌ترین دستورهایی هستند که در برنامه‌نویسی روزانه با آنها روبرو می‌شویم. هنوز بسیاری از موارد دیگر درباره Git وجود دارد که در مقالات جداگانه بعدی توضیح خواهیم داد.

#Git

@Code_Crafters

وب سایت کانال https://codecrafters.ir

لیست هشتک‌ها در کانال رو در زیر براتون خواهم گذاشت و آپدیت خواهد شد


#design_patterns الگوهای طراحی

#postgresql پستگرس

#k8s کوبرنتیز

#agile اجایل
#scrum

#algorithm الگوریتم

#video

#meeting متینگ‌

#principles اصول کدنویسی

#project_managment_system مدیریت تیم

#free خارج از مبحث کامپیوتر


#app برنامه‌های کاربردی

#Git #actions مباحث مربوط به گیت و گیتلب

#conda #env کار با

#Docker مباحث مربوط به داکر

#AI #ML مباحث هوش مصنوعی

#book معرفی کتاب

#monitoring بررسی وضعیت سیستم و کد

#concurrency همزمانی کتاب grokking concurrency


#blovkchain #web3

#DDD #domain_driven_design

#BDD #behavior_driven_development

#soa #sso #microservice


@Code_Crafters

Git Hub:
https://github.com/CodeCrafters-ir/

دو‌ ویژگی کاربردی در گیتلب برای توسعه دهندگان



Merge request

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




Issuess

این ویژگی هم مانند ویژگی بالاست با چند تفاوت بیشتر ، اول اینکه مختص تیم توسعه نیست و افراد بیرون از تیم هم بهش دسترسی دارند و یا حتی می‌تونند خودشون یک مبحث رو شروع کنند، مختص به باگ نیست بلکه میتواند موضوعات مختلفی رو شامل بشه مانند: پیشنهاد ویژگی جدید در پروژه، پرسش راجب به پروژه، پیشنهاد در بهبود بخشی از کد، یا حتی گزارش یک مشکل یا باگ


در لینک زیر میتونید راجب این موضوعات بیشتر بخوانید

https://pvlearn.com/product/merge-requests-gitlab/



#Git

@code_crafters

خب بیاید راجب یک‌ موضوع دیگه خیلی سریع در چند پست باهم بررسی و یاد بگیریم


اتومیشن کردن پروژه (ما از یک پروژه جنگویی استفاده میکنیم اما جز در قسمت داکرایز کردن آن تفاوتی در سایر مراحل ندارد)در گیتهاب با استفاده از github actions


خب قبل از هرچیزی بیایم سناریویی که میخوایم انجام بدیم رو با هم بچینیم و پیاده سازیش کنیم


ما یک اپلیکیشن داریم که داخل گیتهاب در ریپوزیتوری خصوصی با نام test-action قرار دادیم


دوتا سرور داریم

یک سرور جهت تست با نام server-develope
یک سرور جهت اجرا با نام server-production

ما از رانر خودمون استفاده میکنیم که کار کردن و تنظیم کردن اون رو هم یاد بگیریم

دوستانی که سرور ندارن میتونن از environment خود گیتهاب جهت تست و تمرین استفاده کنن

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

در مبحث مربوط به cd برای سرور تست delivery و برای سرور اجرا deployment پیش خواهیم رفت

چرا از دو رویکرد برای cd استفاده میکنیم

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

خب ما یک پروژه با جنگو رو شروع میکنیم

conda env create -n tetstaction-venv python=3.10 django gunicorn gevent

conda activate tetstaction-venv

mkdir my_project 

cd my_project

django-admin startproject config .

داکرایز کردن آن:
در همان مسیر دایرکتوری my_project

nano Dockerfile

مقدار زیر را داخل آن بزارید

FROM continuumio/miniconda3
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1
WORKDIR /code
COPY . /code/
RUN /bin/bash -c "conda env update -f requirements.yml"
EXPOSE 8000

فایل داکرکامپوز

nano docker-compose.yml

محتویات آن

ser version: '3'

services:
  conda:
    build: .
    image: conda-test
    hostname: conda
    container_name: conda
    restart: on-failure
    command: sh -c "conda run gunicorn -k gevent --workers 4 config.wsgi:application -b 0.0.0.0:8000"
    expose:
      - 8000
    ports:
      - 8000:8000

خب تا اینجای کار آماده شدیم

دوتا سرور تست و اجرا داریم

یک پروژه جنگویی داریم

اون رو داکرایز کردیم

و در یک ریپوی خصوصی گیتهاب گذاشتیم

از پست بعد بریم سراغ github action


#git
#actions


@code_crafters

خب میریم سراغ رانرهامون

اینکه رانر چیه و توضیحات مربوط به اون رو برید از Gemini گوگول بپرسید از تعاریف عبور می‌کنیم

ما دو نوع رانر داریم

رانر میزبانی شده توسط گیتهاب(اگه سرور ندارید میتونید ازین مورد استفاده کنید)
رانر خود میزبانی شده که بهش self hosted میگیم و روی سرور بالا میاریم(میتونید روی لپتاپ خودتون هم بالا بیارید)

به اکانت خود و ریپوی مدنظرتون برید و مسیر زیر رو دنبال کنید
Settings > Actions > Runners > New self-hosted runner

در کامنت‌ها تصویر اول رو ببینید

تو این صفحه دستورالعمل مربوط به اجرا کردن رانر را میبینید مطابق آن پیش بروید من از سیستم عامل لینوکس بهره میبرم

در کامنت‌ها تصویر دوم را ببینید


دستورات مربوطه در این صفحه با حفظ نکته زیر در سرور server-developer اجرا کنید

در بخش configure هنگام اجرا کردن بش اسکریپت config.sh/. موارد رو مطابق زیر پر کنید

دستور اول مربوط به ساخت دایرکتوری می باشد در هر مسیری که دوست دارید آنرا اجرا کنید و بخاطر بسپارید تمامی دستورات ما جهت پیکربندی رانر در این مسیر این دایرکتوری انجام خواهیم داد 

در مرحله اول کلید enter را بزنید تا پیش فرض بماند

در مرحله دوم هم مقدار server-developer را وارد کنید

در مرحله بعدی لیبل server-developer را وارد کنید

در مرحله بعدی کلید enter را بزنید 

رانر ما اکنون آماده کار میباشد

دستور زیر را بزنید تا رانر شروع بکار کند

./run.sh

اکنون صفحه گیتهاب خود در مسیر زیر را اگر رفرش کنید با تصویر سوم در کامنت ها روبرو میشید

Settings > Actions > Runners


یک رانر با نام و برچسب server-developer می بینید این یک self-hosted هست این نام رو فراموش نکنید


نکته قابل توجه:
دستور run.sh/. ترمینال رو مشغول نگه داشته و اگه این دستور رو خاتمه بدید و به همان صفحه رانرها برگردید میبینید که رانر به حالت offline رفته

ما باید رانر رو به یک سرویس تبدیل کنیم تا همیشه به حالت کار قرار گیرد دستورات زیر را در همان مسیر دایرکتوری که رانر در ان قرار دارد اجرایی کنید (actions-runner) اجرایی کنید

sudo ./svc.sh install

systemctl start action<کلید tab را جهت کامل کردن بزنید>

اکنون اگر بجای start در دستور دوم بالا مقدار status را بزارید میبینید که رانر ما بصورت سرویس بالا آمده و در حال اجرا قرار گرفته است

برای سرور server-deployment به همان صفحه رانرها رفته و یک رانر جدید دیگر راه بندازید

Settings > Settings > Actions > New self-hosted runner 

همان مراحل بالا را انجام بدید منتها نام و لیبل رو به server-deployment تغییر دهید

اکنون صفحه رانرها را رفرش کنید رانر server-deployment رو با server-developer  میبینید 

هر دو رانر ما آماده شدن

#git
#actions


@code_crafters

خب بریم سراغ نوشتن workflows ها

یک دایرکتوری در مسیر root پروژه خود بسازید و اسم آن را github. بزارید و داخل آن نیز یک دایرکتوری دیگر با اسم workflows بسازید هر فایلی با پسوند yml. بعنوان یک flow شناخته میشه و به رانر برای اجرا داده میشود

در سناریوی پست اول گفتیم که دو سرور خواهیم داشت server-develope با server-deployment


در این دایرکتوری دوتا فایل خواهیم ساخت 
develop.yml
deployment.yml

ابتدا میریم سراغ فایل develope.yml و ذره ذره آنرا توضیح خواهیم داد

ابتدا برای آن یک نام تعیین میکینیم تا در هنگام اجرا شدن در صفحه گیتهاب مربوط به نشان دادن بتوانیم آنرا تفکیک کنیم

name: develope application 

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


در مرحله بعد ما مشخص میکنیم این flow چه هنگامی اجرا شود

on:
     push:
          branches:
                - main

مشخص کردیم هنگامیکه پوش داشتیم و روی برنچ main این پوش صورت گرفته بود این flow اجرا گردد


در سناریوی اولی ما دو سرور داشتیم و هر سرور هم یک رانر داشت رانر مربوط به تست و توسعه رو با اسم server-develope لیبل آنرا نیز با نام server-develope گذاشتیم ما از اسم لیبل استفاده میکنیم میکنیم تا به گیتهاب بفهمونیم میخواهیم flow با اسم develope.yml را روی روی سرور و با رانر server-develope اجرا کند

env:
      TARGET_SERVER: server-developer

خب این رو هم مشخص کردیم


بریم سراغ نوشتن jobها هر flow میتونه چندین job داشته باشه که در بلاک jobs نوشته میشه هر job یک مشخصه و چندین step و env و رانر متصل و ... میتونه داشته باشه

ما سه job خواهیم داشت
Pull
Dockerize
Push

قبل از ادامه در سرور

۱-در مسیر var/www/ پروژه رو‌clone میکنیم

۲-نصب و پیکربندی داکر و داکرکامپوز

خب بریم سراغ جاب pull

pull:
        runs-on: self-hosted
        steps:
            - name: pull from github
              env:
                USERNAME: "CodeCrafters-ir"
                TOKEN: ${{ secrets.TOKEN }}
              run: |
                cd /var/www/test-action
                git config --global user.email "behzad.azadi2693@gmail.com"
                git config --global user.name "behzad azadi"
                git pull https://$USERNAME:$TOKEN@github.com/CodeCrafters-ir/test-actions.git

اسم job رو گذاشتیم ،جهت گرفتن تغییرات ریپو بر روی سرور

این جاب روی رانر خود میزبان اجرا خواهد شد و چون در ابتدا برای این flow ما مقدار TARGET_SERVER تعریف کردیم پس این جاب و گامهای اون روی سروری اجرا میشه که رانر با لیبل server-developer قرار گرفته است

در گام اول ما یک نام با عنوان pull from github گذاشتیم

درون env ما دو مقدار متغییر قرار دادیم username برای نام کاربری در گیت‌هاب و TOKEN که توکن دسترسی به ریپوی پرایویت و اکانت گیتهاب ما می باشد و چون این مقدار امنیتی می باشد آنرا داخل سکرت ریپومون در مسیر زیر گذاشته و از آنجا دریافت میکنیم
Settings > Secrets and Varibles > Secret > New repository secret

تصویر اول در کامنت‌ها

در قسمت run دستورات مربوط رو مینویسیم

ابتدا به مسیر دایرکتوری پروژه میریم معمولا در جامعه توسعه دهندگان و لینوکس مسیر آن در var/www/ می باشد

مقادیر نام و ایمیل رو برای گیت تنظیم میکنیم 

و سپس جهت دریافت کدها و تغییرات pull میکنیم به نحوه جا دادن username و token دقت کنید

بریم سراغ جاب بعدی dockerize

dockerize:
        runs-on: self-hosted
        needs:
            - pull
        steps:            
            - name: Create image
              run: |
                echo $SUDO_PASSWORD | sudo -Sv
                cd /var/www/test-action
                sudo docker build . -t conda-test --no-cache

            - name: Run container
              run: |
                echo $SUDO_PASSWORD | sudo -Sv
                cd /var/www/test-action
                sudo docker compose down
                sudo docker compose up -d

در این جاب مقدار need رو میبینید که به جاب pull رفرنس داده ،ما تا زمانیکه کدهارو نگرفتیم نمیتونیم داکرایز کنیم بابت همین نیاز هست منتظر بمونیم pull تموم بشه و بعد

داخل هر گام مقدار کد 
echo $SUDO_PASSWORD | sudo -Sv
رو میبینیم چون نیاز هست در کامندها از sudo استفاده کنیم اینگونه براش پسورد رو میگذاریم 

مقدار متغییر 
$SUDO_PASSWORD 
رو هم در env گلوبال میزاریم
env:
    TARGET_SERVER: server-developer
    SUDO_PASSWORD: ${{ secrets.SUDO_PASSWORD }}
در بالاتر یاد گرفتیم چطوری متغییر امنیتی رو تنظیم کنیم

#git
#actions

@code_crafters

خب بریم سراغ جاب push


ابتدا به اکانت داکرهاب خودمون میریم یدونه ریپوزیتوری پرایویت میسازی با اسم conda-test

push-image:
        runs-on: self-hosted
        env:
          USERNAME: 'behzadazadi2693'
          DOCKER_PASSWORD: $"{{ secrets.DOCKER_PASSWORD }}"
        needs:
          - dockerize
        steps:
          - name: push image to docker account
            run: |
              echo $SUDO_PASSWORD | sudo -Sv
              sudo docker login -u $USERNAME -p $DOCKER_PASSWORD
              sudo docker tag conda-test $USERNAME/conda-test:v1
              sudo docker push $USERNAME/conda-test:v1

خب نیاز داریم اول جاب dockerize تموم بشه بعد ،پس needs رو براش مینویسیم

برای لاگین در داکر هاب نام کاربری و پسورد لازم داخل env تعریف میکنیم و پسورد رو میبریم داخل سکرت ریپومون

دستورات run:

پسورد ران برای دستور sudo تنظیم میکنیم 

ابتدا لاگین میکنیم

طبق قاعده خاص داکر ایمیج رو نام گذاری میکنیم برای ریپوزیتوری پرایویتمون در داکر هاب 
و سپس پوش میکنیم داخل داکر هاب

خب بریم سراغ flow مربوط به deployment

نکته: ابتدا در سرور server-deployment داکر و داکرکامپوز رو نصب میکنیم 

خب برگردیم سر طراحی این flow

ابتدا یک نام بهش میدیم

name: deployment application

در مرحله بعدی مشخص میکنیم چه وقتی این flow کار کنه؟؟؟

یادتون هست در تعریف سناریو گفتیم که برای سرور دیپلوی بیام بصورت دستیش کنیم؟؟؟

درسته پس این مقدار باید بشکل زیر باشه

on:
     Workflow_dispatch

حالا باید مشخص کنیم که این flow در کدوم سرور بوسیله کدوم رانر اجرا بشه(پسورد sudo رو هم بزاریم براش)

env:
    TARGET_SERVER: server-deployment
    SUDO_PASSWORD: ${{ secrets.SUDO_PASSWORD }}

در جاب اول ایمیج رو pull میکنیم

pull-image:
        runs-on: self-hosted
        steps:
            - name: pull image
              env:
                USERNAME_HUB: "behzad-azadi2693"
                PASSWORD_HUB: ${{ secrets.TOKEN }}
              run: |
                echo $SUDO_PASSWORD | sudo -Sv
                sudo docker login -u $USERNAME -p $DOCKER_PASSWORD
                sudo docker push $USERNAME/conda-test:v1

خب همه چی مشخص هست درسته؟؟؟

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


چندتا نکته:

شما میتونید روی یک سرور کار کنید 

در قسمت runs-on اگر مقدار ubuntu-latest رو قرار بدید روی رانرهای خود گیتهاب کار خواهد کرد

اگرهم تغییر ندید و به هر دلیلی رانرتون ارور بده گیتهاب بازم میبره روی رانر خودش اما بدلیل دستور sudo و پسورد بهتون خطا خواهد داد

ایا میشه از این ساده تر هم نوشت؟؟بله action های آماده وجود داره که برید بخونید راجبشون 

در قسمت on هم میتونید علاوه push و dispatch حتی cronjob ,pull request هم تنظیم کنید

پروژه و کدها رو میتونید در گیتهاب ببینید
https://github.com/CodeCrafters-ir/test-actions.git


خب سوال:
اگه بخوایم همین سناریو رو در گیتلب هم یاد بگیریم چی؟؟؟
اموزش بچه‌های دواپس هابیز رو در یوتیوب ببینید

https://youtube.com/playlist?list=PLYrn63eEqAzannVocQrddqsBK-C17e-Sm&si=F_C_OiGw6i3l4aoN


#git
#actions

@code_crafters

در ادامه مباحث مربوط به github action

تست پروژه و کدها

ما قبل از اینکه بخواهیم پروژه رو pull و داکرایز کنیم نیاز هست ابتدا تست‌هایی که توسط تیم توسعه صورت گرفته رو انجام دهیم و در صورت پایان بدون خطا اقدام به انجام جاب‌های دیگر کنیم

پس ما یک جاب test مینویسیم و دیگر جاب‌ها رو الزام میکنیم بعد از آن اجرا شوند

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

 نیاز به نصب جنگو 

و سپس اجرای دستور 
python manage.py test 
می باشیم

جاب test ما بشکل زیر خواهد بود

test:
    runs-on: self-hosted
    container:
      image: python:slim-bullseye
    steps:
      - name: Run Django tests
        run: |
          pip install django
          python manage.py test

یک نکته جالب میبینیم که از مقدار :container در جاب استفاده شده است

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

یک کانتینر از ایمیج python:slim-bullsey بالا بیار جنگو‌رو نصب کن ،کدهارو تست کن و کانتینر رو برام حذف کن
دیگر لازم نیست برای قسمت تست هم یک کانتینر نگهداریم

حالا کافیست داخل دیگر جاب‌ها با استفاده از :needs همه جاب ها رو موظف کنیم که در انتظار بمونن تا تست با موفقیت به اتمام برسد


#git
#actions


@code_crafters

در پروژه‌های نرم‌افزاری، مدیریت و نگهداری کد منبع یکی از بخش‌های مهم توسعه هستش، ما از ابزارهای متعددی برای این منظور استفاده می‌کنیم، مثه GitLab، Bitbucket و GitHub. این پلتفرم‌ها با فراهم کردن قابلیت همکاری و اشتراک‌گذاری کد، به توسعه‌دهندگان این امکان رو‌ میدن تا به راحتی تغییرات در کد رو مدیریت و دنبال کنه. اما هسته اصلی تمام این ابزارها، Git هستش که در اکثر سازمان‌ها به عنوان استاندارد مدیریت نسخه مورد استفاده قرار می‌گیره (هرچند هنوز روش‌هایی مثل زیپ کردن کد منبع هم در برخی تیم‌ها دیده می‌شود😅)

یکی از مهم‌ترین مواردی که در کار با Git باید رعایت کنیم، نگارش صحیح کامیت‌ هستش(اینکه چه تعداد کامیت زده بشه، مورد اختلاف علما هستش) اما کیفیت و شیوه نوشتن متن کامیت بسیار مهم هستش. یک کامیت خوب باید به گونه‌ای باشه که سایر اعضای تیم بتونن به راحتی متوجه بشن چه تغییری انجام شده و دلیلش چیه. به همین منظور، یک ساختار استاندارد برای نوشتن کامیت‌ پیشنهاد شده که به ما کمک می‌کنه متن‌های کامیت واضح و مفهومی باشند

دسته‌بندی کامیت‌ها
کامیت‌ها رو می‌تونیم به ۹ دسته اصلی تقسیم کرد:

1. feat: افزودن یک ویژگی جدید به کد
2. fix: رفع یک مشکل یا باگ
3. docs: تغییرات مرتبط با مستندات
4. style: تغییرات فرمت‌بندی که تأثیری بر عملکرد یا معنای کد ندارند (مانند فاصله‌گذاری یا استفاده از نقطه‌ویرگول)
5. refactor: تغییرات در ساختار کد بدون تغییر در عملکرد یا رفع باگ
6. perf: تغییراتی که به بهبود عملکرد منجر می‌شوند
7. test: اضافه یا تغییر تست‌های نرم‌افزار
8. chore: تغییرات مرتبط با ابزارها، کتابخانه‌ها یا فرایندهای پشتیبان (مثل تنظیمات build)
9. ci: تغییرات مربوط به سیستم‌های یکپارچه‌سازی مداوم و استقرار

بیایید چندتا مثال بزنیم
۱. افزودن ویژگی‌های جدید
- افزودن یک قابلیت جدید به سیستم ثبت‌نام:

feat(auth): add user registration with email verification

- اضافه کردن پنل ادمین جدید:

feat(admin): add dashboard for managing users and orders

۲. رفع باگ‌ها
- رفع مشکل ورود کاربران:

  fix(auth): fix login issue with incorrect password handling

- رفع خطای محاسبه مالیات در فاکتورها:

fix(invoice): correct tax calculation in final price

۳. مستندسازی
- اضافه کردن راهنمای نصب برای پروژه:

  docs: add installation guide for new developers

- به‌روزرسانی README:

docs: update README with new API endpoints

۴. تغییرات فرمت و سبک کد
- بهبود خوانایی کد:

style: format code according to eslint rules

- استفاده از کاما در جای درست:

style: add missing commas in product component

۵. بازسازی و بازنویسی کد
- بازنویسی یک تابع بزرگ برای ساده‌تر شدن:

refactor(cart): split calculateTotal function into smaller functions

- بهینه‌سازی ساختار پروژه:

refactor(folder-structure): reorganize components and services folders
  

۶. بهبود کارایی
- بهینه‌سازی عملکرد کوئری‌های دیتابیس:

perf(database): optimize query for retrieving large datasets
  

- کاهش زمان بارگذاری صفحات:

perf(page-load): lazy load images to improve page load time
  

۷. تست‌ها
- اضافه کردن تست‌های جدید برای تابع جستجو:

test(search): add unit tests for search functionality
  

- به‌روزرسانی تست‌های قدیمی:

test(cart): update tests to reflect changes in cart logic
  

۸. تغییرات جانبی و ابزارها
- به‌روزرسانی پکیج‌های pip:

chore(deps): update pip packages to latest versions
  

- تنظیم محیط توسعه برای استفاده از Docker:

chore(docker): add Dockerfile for local development
  

۹. یکپارچه‌سازی مداوم (CI)
- افزودن یک اسکریپت CI برای ساخت اتوماتیک پروژه:

ci: add CI script for automated builds
  

- رفع خطای پیکربندی در pipeline:

fix(ci): fix incorrect variable in CI pipeline

نکات مهم:
1. وضوح و شفافیت: پیام کامیت باید به وضوح تغییرات ایجاد شده را بیان کند. از عبارات گنگ یا نامفهوم پرهیز کنید
2. سازگاری با استانداردها: استفاده از کلمات کلیدی مانند feat، fix و... برای دسته‌بندی کامیت‌ها، کمک می‌کند تا تاریخچه تغییرات پروژه ساختاریافته و قابل پیگیری باشد
3. توضیحات کوتاه اما مفید: در پیام کامیت به‌خصوص در خط اول، تلاش کنید مختصر و مفید تغییرات را بیان کنید. در صورت نیاز، توضیحات اضافی می‌تواند در خطوط بعدی پیام کامیت اضافه شود

#git
#gitlab

@code_crafters