آموزش Git و git-flow

git init
git config --global user.name "username"
git config --global user.email "email"
git status
git status -s
git add .
git add -A
git commit -m "first commit"
git push
git pull
git commit --amend -m "new commit message"
gi checkout develop
git merge --squash
git merge --abort
git checkout -m <filename>
git diff
git diff –staged
git log
git log --oneline --reverse
git clean
git revert
git reset HEAD <filename>
git branch
git restore


git rm --cached <filename>
git restore --staged <filename>
git ls-files

Gitflow در واقع فقط یک ایده ی انتزاعی از گردش کار درGit است. این گردش کار مشخص می کند که چه نوع شاخه هایی ساخته شود و چگونه این شاخه ها را با هم merge کنیم. ما در این مقاله اهداف این شاخه ها را شرح خواهیم داد. مجموعه ابزار git-flow یک ابزار خط فرمان واقعی است که به نصب نیاز دارد.

Gitflow یکی از چند گردش کاری است که تیم شما می تواند از آن تبعیت کند. این گردش کار برای تیم هایی که برنامه ریزی توسعه محصول را بر اساس انتشار آن انجام می دهند بسیار مناسب است. همچنین این گردش کار، روندهایی مخصوص رفع نقص محصول منتشر شده تعریف می کند و این روند را شفاف می کند.

شاخه master : که کدهای پروژه (در حال اجرا) قرار دارند و ممکنه همه بهش دسترسی نداشته باشند و طبق قرارداد هم کسی اجازه کامیت و پوش کردن بهش رو نداره !
شاخه develop :‌ کار بر روی پروژه از اینجا شروع میشه و توسعه دهنده ها میتونن کدهاشون رو به این قسمت پوش کنند اما این همه ماجرا نیست. اگه قرار باشه ۵ نفر همزمان روی این شاخه کار کنند ممکنه conflict به وجود بیاد پس شاخه دیگه ای هم لازم داریم:
شاخه feature: فرض کنید نیما قراره رو login کار کنه و هادی روی home پس به راحتی میتونن هر کدوم شاخه های خودشون رو داشته باشند به این شکل که feature/login و feature/home . در نهایت وقتی کار تموم شد این شاخه با شاخه develop مرج میشه و در صورتی که لازم باشه بعدا با شاخه master هم merge میشه!
شاخه hotfix:‌ فرض کنید هادی و نیما دارن روی فیچرهایی که گفته شده کار میکنن که مدیر پروژه یهو متوجه یه مشکلی تو پروژه در حال اجرا ( که طبیعاتا روی شاخه master هست) میشه و میخواد سریعا این مشکل حل بشه. پس به یه توسعه دهنده دیگه میگه این موضوع رو به سرعت حل کن!‌
این جا شاخه hotfix به وجود میاد و بدون اینکه با فیچر ها دخالتی داشته باشه از مستر و یا دولوپ یه شاخه میگیره و شروع میکنه به رفع مشکل! بعد از اینکه مشکل حل شد با master و یا develop مرج میشه. هادی و نیما هم بدون مشکل به کار خودشون ادامه میدن !
شاخه release: هم که از اسمش مشخصه! مربوط به کنترل تگ های برنامه است و مثلا وقتی پروژه به جایی رسید که قراره release بشه یک تگ بهش میخوره مثلا 2.4.1 و ...

یک نمونه از گردش کار
یک مثال کامل از گردش کار Feature Branch به صورت زیر است. فرض می کنیم یک مخزن با شاخه ی master ساخته شده است.

git checkout master
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout master
git merge develop
git branch -d feature_branch

علاوه بر روند feature و انتشار، یک مثال hotfix به صورت زیر است:

git checkout master
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout master
git merge hotfix_branch

روند کلی گردش کار Gitflow به صورت زیر است:
1. شاخه ی develop از شاخه ی master گرفته می شود.
2. شاخه ی انتشار از شاخه ی develop گرفته می شود.
3. شاخه های feature از شاخه ی develop گرفته می شوند.
4. وقتی که کار روی یک شاخه ی feature تمام می شود، این شاخه در شاخه ی merge ،develop می شود.

5. وقتی که کار روی شاخه ی انتشار تمام می شود، این شاخه در هر دو شاخه ی develop وmaster با هم merge می شود.
6. اگر نقص در شاخه ی master شناسایی شود، یک شاخه ی hotfix از شاخه ی master گرفته می شود.
7. وقتی که نقص در شاخه ی hotfix رفع شد، این شاخه در هر دو شاخه ی develop و master ادغام می شود.

منابع:
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow