خوب دوستان من می خواستم (و همچنین میخواهم) یک پروژه استارتاپی شروع کنم قبل کلی تحقیق کردم (و می کنم) یکی از مواردی در توسعه برنامه مهمه این هست که برنامه (حتی در حالت توسعه)نسخه بندی داسته باشه اینکار مزیت های زیادی دارد مثلا اگر در توسعه برنامه در یک مرحله اشتباهی رخ دهد خیلی راحت می توانیم نسخه قبلی برگردانیم و دوباره توسعه دهیم یا در کار های گروهی (که من تجربه اش را ندارم) git و tfs خیلی به کار میاد همانطور هم که میدونید هم git و هم tfs هر دو برای شرکت ماکروسافت هستند.
حالا از مقدمه و مزایا بگذریم میرسیم به بحث آموزش خوب git بر اساس خط فرمان هست که باید دستورات به صورت command line در git bash بزنید ولی در ویژوال استودیو بیشتر کار ها توسط Team explorer انجام میشود (ولی گویند که بعضی دستورات باید به صورت cl نوشته شود). شما می توانید هم از سرور های github استفاده کنید و هم tfs (یا همون vsts که شده Azure DevOps) هر دو رایگان هستند (با محدودیت تعداد نفراتی که روی پروژه کار میکنند) و در هر دو هم امکان ساخت پروژه به صورت خصوصی هم وجود دارد ولی با توجه به تحقیقاتی که کردم ظاهرا امکانات ADO بیشتر از github هست (بخصوص برای .net کار ها) ولی خوب بعضی ها هم عقیده دارند که فرقی نداره که هیچ github بهتر هم است !
حالا من با Azure DevOps کار میکنم ولی در Team Explorer زیاد فرقی با گیت هاب نداره و تمامی مفاهیم اصلی مثل branche و ... مثل هم هستند.اگر دنبال آموزش های گیت هستید خیلی آموزش های خوب و رایگان در سطح اینترنت هست این از آقای جادی (https://virgool.io/@jadijadi)و این از آقای سهیل علیزاده (خودش شد مقدمه 2 !)
کنترل نسخه دارای یک جریان کلی است که اکثر توسعه دهندگان هنگام نوشتن کد و به اشتراک گذاری آن با تیم از آن استفاده میکند.
این مراحل عبارتند از:
(توضیحات اضافه: موقعی Conflict یا merge conflict رخ میدهد روی branch یا بطور کلی که شما تغییر دادین/یا ایجاد کردین، شخص دیگری آن کد ها را دستکاری کرده است مثلا کدی اضافه یا حذف کرده conflict رخ میدهد. تقریبا معنایی مثل concurrency/همزمانی در ef core دارد. و شما باید مشخص کنید که کد شما انتخاب کنه یا آن کد دیگر )
مقدمه کوچیک : ما یک مخزن راه دور(Remote Repository) داریم و یک مخزن محلی (Local Repository) کار های ما توسط LR انجام میشه و بعد با دستورات مثل push آن تغییرات را به RR میفرستیم و برعکس با دستوراتی مانند Pull ما اطلاعات (کد ها و فایل ها و ...) از RR به LR میفرستیم
برای دریافت یک کپی از سورس کد باید git repository را clone کنیم.
1- در پنجره Team Explorer روی دوشاخه (!) زده و به صفحه Connect بروید
2- در زبانه Manage Connections روی Connect to project کلیک کنید. در پنجره باز شده مخزنی که میخواهید سورس کد را روی آن clone کنید انتخاب کنید. (برای ساخت مخزن اینجا را ببنید و یا مستقیما در این سایت ثبت نام و مخزن ایجاد کنید)
سپس روی دکمه clone کلیک کنید.
شاخه های گیت(Git branches)، تغییرات شما را از کارهای دیگر که انجام می دهید جدا میکند(ایزوله میکند isolate). همانطور که در گردش کار Git توصیه شده از یک شاخه جدید برای اضافه کردن هر ویژگی یا رفع باگ استفاده کنید.شما در مخزن گیت محلی (Local Git Repository) (تلفظ:کٌمیت) commit ها را برای ذخیره تغییرات خود در آن شاخه (Branch) می سازید.(توضیح اضافه: برای ذخیره تغییرات در Branch باید تغییرات را Commit کنیم. commit کردن باعث میشود که حالت تغییرات به stage تغییر کند "روی صحنه می روند برای پرتاب شدن به Remote Repository". اگر با این اصطلاحات آشنایی ندارید فیلم هایی که معرفی کردم حتما ببینید).
1- درون Team Explorer ابتدا وارد Home شوید و روی branches کلیک کنید:
2- روی Master branch (که شاخه اصلی هست) کلیک راست کرده و گزینه New Local Branch From... انتخاب کنید
3- یک نام شاخه توصیفی را برای کار خود انتخاب کنید تا به شما و دیگران یادآوری کند که چه نوع کاری در شاخه است، و Create Branch را انتخاب کنید.
4- تغییرات در فایل های خود را در repo کلون شده انجام دهید.از نمای Home Explorer Team Explorer می توانید solution های ویژوال استودیو را در repo باز کنید یا محتویات repo را با استفاده از لینک Show Folder View مرور کنید. Git پیگیری هایی از تغییرات انجام شده در کد خود را در داخل و خارج از ویژوال استودیو را دنبال می کند.
5-هنگامی که از تغییرات راضی هستید، آنها را در Git با استفاده از commit ذخیره کنید.با انتخاب آیکون Home و انتخاب Changes، نمای تغییرات(Change View) را از Team Explorer باز کنید.
6- پیامی را برای توصیف Commit وارد کنید و Commit All را انتخاب کنید.
توجه: اگر شما چندین فایل داشتید و نمی خواهید از Commit All استفاده کنید . روی فایل دلخواه راست کلیک کرده و گزینه Stage را انتخاب کنید . وقتی تمام فایل های دلخواه را stage کردین و خواستید commit کنید روی Commit stage کلیک کنید (بجای commit all دکمه به commit stage تغییر میکند زمانی که قبل از commit به طور دستی تغییرات stage کنید)
وقتی آماده باشید که تغییرات خود را با تیم به اشتراک بگذارید، شما می توانید این تغییرات را push دهید تا دیگران بتوانند به آنها برسند. پس از اضافه شدن commit به branch، می توانید تغییرات را push دهید.
هنگامی که تغییرات را push می دهید، می توانید request pull ایجاد کنید تا دیگران بدانند که می خواهید دیگران تغییرات را بررسی کنند و به شاخه اصلی (Master Branch) کد اضافه کنند.
1- نمای Synchronization در TeamExplorer بازکنید برای اینکار در بخش Home روی Sync کلیک کنید :
همچنین شما میتوانید از نمای changes به نمای Synchronization بلافاصله بعد از ایجاد commit و انتخاب Sync دسترسی داشته باشید .
2- انتخاب Push برای به اشتراک گذاشتن commit خود با مخزن از راه دور (remote repository).
اگر برای اولین بار به مخزن push میکنید، پیام زیر را به جای لیست commit ها خروجی مشاهده خواهید کرد:
The current branch does not track a remote branch. Push your changes to a new branch on the origin remote and set the upstream branch.
(توضیح اضافه: origin remote نام محلی remote repository در کامپیوتر ماست به عبارت ساده origin remote همون remote repository هست) Push برای تغییرات خود را به یک شاخه جدید در مخزن از راه دور push کنید و شعبه بالادست ( upstream branch ) را set کنید. دفعه بعد که شما تغییرات را push می دهید لیستی از commit ها را مشاهده خواهید کرد.
3- یک Pull request ایجاد کنید تا دیگران بتوانند تغییرات شما را بررسی کنند.برای باز کردن نما pull requests در Team Explorer و بخش Home روی Pull Requests بزنید:
4- از نمای Pull Requests می توانید تمام pull request های که باز شده توسط خود را مشاهده کنید. New Pull Request انتخاب کنید تا مرورگر وب باز شود و از طریق سرویس Azure DevOps Services web portal بتوانید یک Pull Request جدید ایجاد کنید (این بخش از طریق وب انجام میشود).
5- شاخه های خود را تأیید کنید (در این مثال ما می خواهیم commit های از شاخه ReadMeFix را به شاخه Master ادغام/ merge کنیم)، یک عنوان و توضیحات اختیاری را وارد کنید، هر بررسی کننده را مشخص کنید، هر گونه آیتم های کاری مرتبط را انتخاب کنید (اختیاری) و Create را انتخاب کنید.
برای آموزش بیشتر Pull request ببینید
برای به دست آوردن تغییرات از دیگران و به روز نگه داشتن کد خود، می توانید commit های انجام شده توسط دیگران را pull و آنها را در شاخه خود ادغام/merge کنید. Git در مورد ادغام چندین تغییر حتی در یک فایل بسیار خوب است، اما گاهی اوقات شما ممکن است مجبور شوید که یک تضاد (conflict)ادغام را حل کنید. ایده خوبی است که به طور مرتب شاخه های خود را pull کنید تا آنها را با تغییرات دیگران حفظ کنید/بروز نگهدارید. این باعث می شود که شاخه های ویژگی شما از شاخه اصلی شما از آخرین نسخه کد استفاده کنند.
1- در home دکمه sync را انتخاب کنید
2- شما می توانید آخرین تغییرات مربوط به شاخه ای که در حال استفاده از آن هستید را توسط pull link دانلود کنید. لینک pull در 2 جا مشاهده میکنید هر دو یکی هستند و یک کار انجام میدهند
برای مشاهده Command Line ها از منبع استفاده کنید
مخزن Git، یا repo، یک پوشه است که به Git گفته اید تا به شما در ردیابی تغییرات فایل در آن کمک کنید. شما می توانید هر تعداد repo برای کامپیوتر خود داشته باشید، هر کدام در پوشه خود ذخیره می شود. هر GET repo در سیستم شما مستقل است، بنابراین تغییرات ذخیره شده در یک repos Git بر محتوای دیگر تاثیر نمی گذارد.
یک Git repo حاوی هر نسخه از هر فایل ذخیره شده در repo است. Git موجب صرفه جویی در این فایل ها بسیار موثر است، بنابراین داشتن تعداد زیادی از نسخه ها به این معنی نیست که از فضای دیسک زیادی استفاده می کند. ذخیره هر نسخه از فایل های خود را به Git ادغام بهتر کد کمک می کند و کار با نسخه های متعدد از کد خود را سریع و آسان است. (ساخت یک local repository می باشد)
هر پوشه با source code (کد منبع) یا solution ویژوال استودیو را در Git با ایجاد یک repo برای آنها مدیریت کنید. بعدا می توانید این مخزن Git را به یک remote Git repo وصل کنید تا کار خود را با دیگران به اشتراک بگذارید.
مشاهده آموزش ها
برای solution جدید (این بخش در vs 2019 کمی متفاوت است)
وقتی در حال ساخت solution جدید در vs هستید گزینه Create new Git repository انتخاب کنید
برای solution موجود
برای ایجاد repo از یک solution موجود و نه در کنترل نسخه(یعنی repo نداشته باشد)، دکمه Publish را در پایین سمت راست نوار وضعیت پایین انتخاب کنید. این یک repo جدید Git در همان دایرکتوری به عنوان solution شما ایجاد می کند و نمای Publish را در Team Explorer باز می کند تا بتوانید کد خود را به Azure Repos یا دیگر مخزن Git راه دور push کنید.
در یک پوشه خالی
1- نمای Connect در Team explorerرا باز کنید Projects انتخاب کنید و بعد در منوی زمینه Manage Connections انتخاب کنید.
2- زیر Local Git Repositories ، جدید/New را انتخاب کنید و پوشه ای که repo ایجاد می شود را وارد کنید. این directory باید خالی باشد.
3- ایجاد Create انتخاب کنید تا مخزن ایجاد شود
اتصال مخزن محلی به یک مخزن راه دور
برای اتصال یک مخزن محلی به مخزن Git راه دور میزبان برای به اشتراک گذاشتن کار خود، به صفحه Settings در Team Explorer بروید. Repository Settings انتخاب کنید.زیر Remotes ، اضافه/Add انتخاب کنید.
منشا/origin را در قسمت Name وارد کنید و clone URL را برای repo خود در قسمت Fetch وارد کنید.
منبع و مشاهده فیلم CommandLine
توضیحات:کلون/clone در لغت به معنای شبیه بودن و در اینجا به معنی کپی کردن میباشد. کلون کردن یک مخزن git موجود هم منظور remote repository هست. مخزنی که روی سرور آنلاین ما قرار دارد. به عبارت ساده یعنی کپی کردن فایل ها و اطلاعات یک مخزن راه دور به مخزن محلی ما.
با استفاده از کلون کردن یک نسخه کامل Git repository موجود یک کپی محلی ایجاد کنید.کلون کردن یک مخزن همه commit ها و branch ها ی مخزن را دریافت میکند و یک رابطه را با مخزن موجود که کلون کرده اید ایجاد می کند.با استفاده از این رابطه برای تعامل با مخزن موجود، pushing و pulling تغییرات برای به اشتراک گذاشتن کد با تیم خود.
توجه:بطور پیشفرض Git به remote repo که از آن کلون کردید origin اختصاص خواهد داد .اکثر کاربران به بیش از یکremote نیاز ندارند، بنابراین آموزش از مراحل اولیه استفاده می کند، بنابراین در مراحل آموزش از origin استفاده شده است.
قبل از اینکه بتوانید repo موجود (remote repo) را کلون کنید، به URL نیاز دارید که به repo موجود اشاره دارد. این URL نشان دهنده منبع مخزن می باشد که در طی کلون کپی می کنید.
اگر شما از Azure DevOps Services یا Team Foundation Server 2017 استفاده میکنید، شما می توانید این آدرس کلون را در پورتال وب پیدا کنید.
1- در مرورگر وب خود ، درون Azure DevOps organization پروژه تیم را باز کنید و Repos, Files انتخاب کنید.
2- کلون/Clone را در سمت راست بالا انتخاب کنید.
اگر شما نیاز به clone کردن یک repo GitHub دارید، شما باید URL کلون را از دکمه کلون یا دانلود (دکمه Clone or download) در هنگام مشاهده مخزن در وب GitHub دریافت کنید.
سایر ارائه دهندگان Git دارای دکمه های مشابه در رابط کاربری خود برای دریافت URL کلون هستند.
این نشانی اینترنتی را به کلیپ بورد کپی کنید یا آن را در جایی ذخیره کنید که بتوانید آن را به آسانی پیدا کنید. شما نمیتوانید یک repo را بدون یک URL کلون ،کلون کنید.
کلون از سرویس Azure DevOps / Team Foundation Server
1- در Team Explorer روی آیکون Connect زده و صفحه Connect را باز کنید.
2- در کادر گفتگوی Connect to a Project ، مخزنی را که میخواهید از لیست انتخاب کنید، انتخاب کنید و Clone را انتخاب کنید. اگر مخزن خود را در لیست ذکر شده مشاهده نکنید، می توانید لیست را برای یافتن آن فیلتر کنید یا یک سرور Team Foundation را که در آن مخزن با انتخاب لینک Add TFS Server میزبانی می شود اضافه کنید.
نکته: URL های پروژه با انتشار آزمایشی DevOps Services تغییر کرده اند و در حال حاضر فرمت dev.azure.com/{your your organization} / {your project} هستند، اما هنوز می توانید از فرمت visualstudio.com موجود استفاده کنید.برای اطالاعات بیشتر VSTS is now Azure DevOps Services مشاهده کنید.
3- محل مخزن کلون شده را بر روی کامپیوتر خود تأیید کنید (محل ایجاد مخزن محلی) و Clone کلون را انتخاب کنید.
کلون از یکی دیگر از ارائه دهندگان Git
اگر از Azure Repos استفاده نمی کنید، شما هنوز هم می توانید REPO خود را در Team Explorer امتحان وارد کنید و با کد خود در ویژوال استودیو کار کنید.
1- نمای Connect در Team Explorer بازکنید.
2- کلون/Clone را در زیر Local Git Repositories انتخاب کنید و URL مخزن خود وارد کنید - این توسط تیم یا Git ارائه دهنده میزبانی شما ارائه می شود.
3- یک پوشه ای را انتخاب کنید که در آن شما باید مخزن کلون شده را نگه دارید.
4- کلون/Clone را انتخاب کنید تا مخزن را کلون کنید.
یک solution در ویژوال استودیو را از یک مخزن کلون شده باز کنید
1-
یک Solution در مخزن کلون شده (مخزن محلی میباشد) در ویژوال استودیو را با کلیک راست بر روی مخزن در نمای Team Explorer>Connect و انتخاب Open باز کنید.
2- شما در Team Explorer به صفحه Home منتقل خواهید شد. فایل Solution پروژه خود را در محل Solutions دوبار کلیک کنید تا Solution در Solution Explorer باز شود.
منبع و مشاهده ویدیو CommandLine این بخش
گیت/Git به صورت خودکار از کد های شما snapshot (ذخیره کردن محلی/موقت) نمی کند مانند فایل هایی که در مخزن (مخزن محلی) ویرایش می کنید. با stage کردن تغییرات شما باید دقیقا مشخص کنید Git کدام تغییراتی که می خواهید به snapshot بعدی اضافه کنید. بعد از stage کردن تغییرات خود، یک Commit برای ذخیره کردن snapshot به مخزن خود ایجادکنید.
گیت/ Git در زمان کار شما تغییرات فایل در repo را ردیابی میکند و فایل ها را در repo به سه دسته تقسیم می کند:
هنگامی که یک Commit ایجاد می کنید، فقط تغییرات Stage شده و فایل های بدون تغییر (unmodified) برای snapshot مورد استفاده قرار می گیرد.تغییرات به فایل های stage نشده (unstaged) اما تغییر کرده (modified) نگهداری می شوند، اما Commit استفاده از نسخه بدون تغییر (unmodified) از Commit قبلی در snapshot آن است.
کٌمیت/Commit ها در مخزن Git محلی شما ایجاد می شود،بنابراین لازم نیست نگران تغییرات کامل خود باشید. به ایجاد Commitهای برای کار خود ادامه دهید، زمانی که آماده اشتراک گذاری هستید، تغییرات خود را به تیم Push دهید.
کمیت/Commit ها شامل اطلاعات زیر هستند:
گیت/Git با مراجع بین Commitها همراه با فایل snapshots یک رکورد کامل از توسعه در مخزن شما حفظ میکند.
درباره Git history و نحوه review history برای بررسی تغییرات انجام شده در کد خود اطلاعات بیشتری کسب کنید.
گیت/ Git خودکار فایل های تغییر یافته را به snapshot اضافه نمی کند زمانی که شما یک Commit ایجاد میکنید.ابتدا باید تغییرات خود را stage کنید تا Git بتواند بداند کدام یک از بهروزرسانیهایی را میخواهید به Commit بعدی اضافه کنید. Staging (استیج کردن) به شما اجازه می دهد تا به طور انتخابی فایل های خود را به Commit اضافه کنید، در حالی که صرف نظر از تغییراتی که در سایر فایل ها انجام شده است.(توضیحات: به صورت دستی فایلها را Commit کنیم- با stage کردن فایل های دلخواه)
نادیده گرفتن فایلهای temp، لاگها، و سایر فایلهایی که ممکن است در دستگاه محلی شما تغییر کند(مختص دستگاه شما باشد)، اما شما نمی خواهید به کنترل نسخه اضافه کنید.توسط فایل Ignore انجام میشود.
ویژوال استودیو 2015 (به روز رسانی 2) و 2017
ویژوال استودیو/Visual Studio همانطور که کار خود را انجام می دهید، پیگیری تغییرات فایل را به پروژه شما انجام می دهد . هنگامی که شما آماده اید تغییرات ایجاد کنید، نمای Changes را در Team Explorer باز کنید.
تغییر فایل Stage با کلیک راست بر روی یک فایل در نمای Change و انتخاب Stage. استیج/Stage کردن/Staging یک تغییر یک بخش تغییرات Stage شده/ Staged در تیم Team Explorer ایجاد می کند.فقط تغییرات در بخش تغییرات stage شده/ Staged Changes به commit بعدی اضافه می شود.
نکته: نمای Changes/تغییرات Team Explorer شامل Included Files و Excluded Files قبل از ویژوال استودیو 2015 به روز رسانی 2 بوده است. نمایش تغییرات در ویژوال استودیو 2015 به روز رسانی 2 برای سازگاری بهتر با دیگر ابزار Git به روز شد.
استیج/stage کردن چند فایل یا folderبا راست کلیک روی آن و انتخاب Stage یا به وسیله dragging و dropping کردن فایل ها از Changes به لیست Staged Changes .
نادیده گرفتن فایل ها با راست کلیک کردن و انتخاب نادیده گرفتن این مورد محلی/ Ignore this local item یا نادیده گرفتن این افزونه/ Ignore this extension . این یک ورودی به فایل .gitignore در مخزن محلی شما می افزاید. اگر فایل ignored در مخزن شما در commit قبلی اضافه شده باشد، نادیده گرفتن فایل آن را از لیست Changes حذف نخواهد کرد. برای اطلاعات بیشتر درباره نحوه نادیده گرفتن فایلهایی که قبلا توسط Git ردیابی شده است excluding and ignoring files section را مشاهده کنید.
1- نمای Changes در TeamExplorer را باز کنید.
یک پیام commit وارد کنید و تغییرات خود را توصیف کنید و برای ایجاد Commit جدید که شامل تغییرات ذکر شده در بخش Staged Changes است ، Commit Staged انتخاب کنید.
اگر شما می خواهید تمام تغییرات ذکر شده را با وارد کردن یک پیغام Commit کنید stage کردن فایل ها را رها کنید و Commit All را انتخاب کنید.
هنگامی که شما در ویژوال استودیو commit میکنید، می توانید commit را push کنید و شاخه را با یک مخزن از راه دور هماهنگ/ sync کنید. این گزینه ها در لیست کشویی دکمه Commit موجود است.(توضیحات همزمان که هم به سرور راه دور و هم به سرور محلی تغییرات را اعمال کنید)
اصلاح آخرین commit خود را برای اصلاح خطاهای کوچک بدون ایجاد commit جدید.
اخطار: commit های push شده را اصلاح نکنید.اگر نیاز به بروزرسانی کد های Push شده داشتید،ازطریق undo the changes with revert یا ایجاد و push کردن Commit دیگر انجام دهید.(در مخزن راه دور یا revert کنید یا commit جدید push کنید)
1- نمای Changes در TeamExplorer باز کنید و تغییرات به روز شده را Stage کنید. درصورتی که staged changes خالی باشد شما میتوانید پیغام Commit اصلاح کنید.
2- پیام Commit بروزرسانی شده را وارد کنید و از منوی کشویی Action بخش Amend Previous Commit انتخاب کنید.
شاخه های Git چیزی جز یک ارجاع کوچک که یک تاریخ دقیق Commit را نگه می دارد نیستند ،بنابراین ایجاد کردن آنها بسیار ارزان است. Commit کردن تغییرات در یک شاخه ،دیگر شاخه ها را تحت تاثیر قرار نمی دهد و شما می توانید شاخه ها را با دیگران به اشتراک بگذارید بدون اینکه این تغییرات را به پروژه اصلی ادغام/merge کنید. ایجاد شاخه های جدید برای جدا کردن تغییرات برای افزودن یک ویژگی یا رفع bug ها ، از شاخه اصلی/Master Branch و دیگر کارها.(توضیحات : برای تفکیک کار ها از یکدیگر و جداسازی آن از master branch ، شاخه های جدید میسازیم)
از آنجا که شاخه ها سبک هستند، تعویض بین شاخه ها سریع و آسان است. هنگام کار با شاخه ها، Git چندین کپی از منبع شما را ایجاد نمی کند---شاخه با استفاده از اطلاعات history ذخیره شده در commitها برای ایجاد دوباره فایل ها بر روی شاخه زمانی که شما شروع به کار بر روی آن هستید. (توضیحات: شاخه با توجه به اطلاعات history که در commitهای این شاخه است فایل ها رو دوباره ایجاد میکند). گردش کار Git شما باید از شاخه ها برای مدیریت ویژگی ها و رفع اشکالات/bugs استفاده کند.بقیه گردش کار Git، مانند به اشتراک گذاری کد و بررسی کد با pull request ها همه از طریق شاخه ها کار می کنند.جداسازی کارها در شاخه ها باعث می شود که کارهایتان را به راحتی تغییر دهید،به سادگی تغییر دادن شاخه فعلی.
شاخه ها با استفاده از دستور branch ایجاد میشوند.Branch یک مرجع/ارجاع را در Git برای شاخه جدید ایجاد می کند و نشانگر/pointer را به parent اعطا می کند، بنابراین Git می تواند تاریخچه تغییرات را در هنگام اضافه کردن commit به شاخه حفظ کند. هنگامی که شما با یک شاخه ای که شخص دیگری به اشتراک می گذاشته کار می کنید، Git روابط ردیابی بالادست را حفظ می کند تا شاخه مربوط به repo محلی را با شاخه مربوط به repo remote ارتباط دهد. این باعث می شود که تغییرات را با دیگران با push و pull همگام سازی کنید.
در این تصویر یک شاخه جدید از شاخه اصلی ایجاد شده است. کار در هر دو شاخه ادامه می یابد و Commitها به هر دو شاخه اضافه می شوند.
گیت/Git همیشه Commit جدید را به شاخه فعلی محلی اضافه می کند. قبل از اینکه Commit کنید شاخه ای را که در آن کار می کنید بررسی کنید تا تغییرات در شاخه اشتباه انجام نشود. مبادله بین شاخه های محلی با استفاده از فرمان checkout صورت میگیرد. Git فایل های خود را بر روی رایانه شما تغییر می دهد تا مطابق با آخرین Commit در شاخه مورد نظر باشند.هنگامی که کار شما در شاخه آماده اشتراک گذاری با بقیه تیم است، شما تغییرات را برای به روز رسانی شاخه راه/remote branch دور Push میکنید.
اشتباه رایج این است که برخی تغییرات انجام دهید و آنها را commit میکنید،بعد متوجه شوید که در یک شاخه نادرست هستند و سپس به شاخه صحیح checkout می کنید.(توضیحات: از دستور checkout ،تعویض شاخه است CL: checkout branchName این دستور باعث تعویض شاخه فعلی به branchName میشود.-البته در vs نیازی با این دستورات نیست).آخرین تغییرات شما دیگر در filesystem نخواهد بود، زیرا هر شاخه دارای کد خاص خود است. Git حالت فایل ها را به آخرین commit در شاخه ای که به آن مبادله شده اند، باز می گرداند، نه شاخه قبلی که در آن تغییرات را انجام دادید.(توضیحات: اگر اشتباهی در شاخه a بودی و کد تغییر دادی و commit کردی بعدا متوجه این اشتباه شدی و رفتی در شاخه درست که b باشه، نمی تونه commit که برای a زدی روی شاخه b اجرا کنی. چون هر شاخه فقط به commit های خودش دسترسی دارد).شما نیاز به یا cherry-pick کردن Commit ها از شاخه و یا ادغام/ merge تغییرات به شاخه درست است.
1- پنجره TeamExplorer بازکنید و به نمای Branches بروید.
2- روی شاخه Parent (که معمولا master است) راست کلیک کنید و New Local Branch From... انتخاب کنید
3- یک نام شاخه را در فیلد اجباری پر کنید و روی Create Branch کلیک کنید. ویژوال استودیو به صورت خودکار به شاخه تازه ایجاد شده checkout/تعویض میشود.
نکته: حذف شاخه/شعبه در مخزن محلی شما، شاخه در مخزن راه دور را حذف نمی کند.
1- پنجره TeamExplorer بازکنید و به نمای Branches بروید.
2- محل شاخه ای که می خواهید حذف کنید. اطمینان حاصل کنید که شما در آن شاخه نیستید، زیرا نمی توانید شاخه ای را که در حال حاضر در آن کار می کنید حذف کنید.(پیشنهاد میشه اول به شاخه master بروید و بعد اقدام به پاک کردن شاخه مرد نظر کنید)
3- روی نام شاخه کلیک راست کرده و گزینه Delete را انتخاب کنید. اگر تغییرات منتشر نکرده باشیدن/unpublished ، ویژوال استودیو از شما خواهش می کند و اطمینان حاصل کنید که می خواهید شاخه را حذف کنید تا احتمالا کار را از دست ندهید.
p
شما می توانید یک شاخه از راه دور را با استفاده از همان روش حذف کنید - محل شاخه راه دور در درختواره پنجره TeamExplorer در نمای Branches (مانند remotes/origin)، راست کلیک کرده و Delete انتخاب کنید.
توضحات : پس ار شاخه محلی پاک کردین و خواستید روی مخرن راه دور هم نباشید باید آن را نیز ار مخزن راه دور پاک کنید.
گیت/Git پیگیری می کند که در کدام شاخه آن کار می کنید و اطمینان حاصل می کند که زمانی که یک شاخه را checkout می کنید فایل های خود را مطابق آخرین commit در شاخه قرار می دهید.(مثلا اگر در یک شاخه فایل x را ایجاد کردید، فایل x فقط در همان شاخه قابل مشاهده است مگر اینکه آن شاخه را به شاخه master یا شاخه دیگر ادغام/merge کنید). شاخه ها به شما امکان می دهند چندین نسخه از کد منبع را در همان مخزن Git محلی بطور همزمان کار کنید. به Git با checkout بگویید که کدام شاخه را شما می خواهید، و Git مراقب تنظیم نسخه های فایل مناسب برای آن شاخه است.
هنگامی که از شاخه ها برای جدا کردن کار خود استفاده می کنید نباید نیاز به بیشتر از یک مخزن در سیستم خود داشته باشید. یک بار پس از اینکه شما کلون را ایجاد کردید محیط توسعه خود را تنظیم کنید و سپس از شاخه های Git برای مبادله بین اضافه کردن امکانات و اصلاح bug ها استفاده کنید.
تغییرات ساخته شده در commit ها و branch ها با استفاده از دستور push به اشتراک بگذارید. شاخه های خود را به مخزن از راه push کنید، جایی که Git/گیت commit ها را میگیرد و آنها را به یک شاخه موجود در راه دور اضافه می کند یا شاخه جدیدی را با همان commit در شاخه محلی خود ایجاد می کند.
گیت/ Git اطمینان می دهد که تغییرات push شده با شاخه های راه دور سازگار است، به طوری که دیگران می توانند commit های شما را pull کنند و آنها را به کپی محلی شاخه خود merge کنند. شاخه های push شده که کارشان را به پایان رسانده اند بررسی و با شاخه اصلی مخزن شما را از طریق pull request ادغام شده اند.
1-نمای Synchronization در پنجره TeamExplorer از طریق گزینه Home و انتخاب Sync ،باز کنید
همچنین شما میتوانید از نمای Changes به نمای Synchronization بلافاصله بعد از Commit کردن با انتخاب گزینه Sync حرکت کنید.
2- برای به اشتراک گذاشتن commit با مخزن راه دور، Push را انتخاب کنید.
اگر این اولین push به مخزن شما است، پیام زیر را به جای لیست commit ها خروجی مشاهده خواهید کرد:
The current branch does not track a remote branch. Push your changes to a new branch on the origin remote and set the upstream branch.
برای push کردن تغییرات خود را به یک شاخه جدید در مخزن از راه دورو تنظیم شاخه بالادست ، Push انتخاب کنید. دفعه بعد که شما تغییرات را push می کنید لیستی از commit ها را مشاهده خواهید کرد.
حل تضادها/conflicts ادغام/merge قبل از push کردن
اگر بین commitهای محلی خود و commitها در شاخه راه دور conflicts وجود داشته باشد، قبل از اینکه بتوانید تغییرات خود را push کنید، ابتدا باید این conflictها را حل کنید. شما باید ابتدا تغییرات را از دیگران pull کنید، conflicts حل و تغییرات commit کنید، سپس تلاش دوباره push کنید.
با استفاده از دستورات زیر، کد در مخزن محلی خود را با تغییرات اعضای دیگر تیم به روز کنید:
واکشی fetch ، که تغییرات از مخزن راه دور شما دریافت میکند اما آنها را به کد شما را اعمال نمی کند.(فقط دریافت و مشاهده تغییرات)
ادغام merge ، که تغییرات دریافت شده از fetch به یک شاخه در مخزن محلی شما را اعمال می میکند.(اعمل تغییرات دریافت شده از fetch بر روی شاخه در مخزن محلی)
کشیدن pull ، که یک فرمان ترکیبی است که یک fetch و سپس merge را انجام می دهد. (هر دو دستور fetch و merge باهم انجام می هد)
اگر یک merge conflict(تضاد ادغام) بین commitی که هنوز push نشده و یک commitی که در حال merge کردن (merging) یا pull کردن (pulling) وجود دارد، قبل از به روز رسانی کد خود باید این تضادها را حل کنید resolve those conflicts .
شما میتوانید تغییرات از مخزن راه دور را با fetch کردن برای مخزن محلی دانلود کنید.fetch از مخزن راه دور برای تمام commitها و branch های جدیدی که دیگران push کرده اند و شما آنهارا ندارید پرسیده و دانلود و به مخزن شما میفرستد،درصورت نیاز شاخه های جدید رای ایجاد میکند.
واکشی fetch هر گونه تغییری را در شاخه های محلی شما ادغام نمی کند، این فقط commit های جدید را برای بررسی شما می گیرد.
نکته: برای کمک به پاک و به روز نگه داشتن لیست شاخه خود را، پیکربندی Git برای هرس/prune شاخه از راه دور در واکشی/fetch. شما می توانید این تنظیم را از خط فرمان یا از داخل ویژوال استودیو پیکربندی کنید.
ویژوال استودیو از نمای Sync در ،Team Explorer برای fetch کردن تغییرات استفاده می کند. تغییرات دانلود شده توسط fetch اعمال نمی شود تا زمانی که تغییرات را Pull یا Sync کنید.
1- با انتخاب Sync در بخش Home در پنجره Team Explorer نمای هماهنگسازی/Synchronization را باز کنید:
2- برای بروزرسانی لیست ورودی ها،Fetch انتخاب کنید. (دو لینک Fetch وجود دارد، یکی در نزدیکی بالا و یکی در قسمت Incoming Commits ، شما می توانید از هر یک از آنها استفاده کنید زیرا هر دو آنها یکسان هستند.)
3- شما می توانید نتایج عملیات fetch را در قسمت incoming commits بررسی کنید.
اعمال تغییرات دانلود شده از طریق fetch با استفاده از دستور merge.ادغام/merge commit های بازیابی شده از fetch می گیرد و تلاش می کند آنها را به شاخه/branch محلی خود اضافه کند. ادغام/merge، تاریخ commit های تغییرات محلی شما را حفظ خواهد کرد، به طوری که هنگامی که شاخه خود را با push کردن به اشتراک بگذارید، Git می داند که دیگران چگونه باید تغییرات شما را ادغام کنند.
چالش با ادغام/merge زمانی است که یک commit دریافت شده از fetch در تضاد/conflicts است با commit پوش/push نشده ( unpushed) موجود در شاخه شمااست.Git عموما بسیار هوشمند است در مورد حل تضادهای ادغام به صورت خودکار، اما گاهی اوقات شما باید تضاد های ادغام را به صورت دستی حل کنید resolve merge conflicts manually . و ادغام را با ادغام commit جدید تکمیل کنید.(یعنی یک commit جدید merge کنید)
تیم اکسپلورر ادغام زمانی که شما یک Pull، و یا Sync نمای Changes انجام دهید. Sync یک کار ترکیبی از pull کردن تغییرات از راه دور و سپس push کردن اقدامات محلی، هماهنگ سازی commit ها در شاخه محلی و شاخه راه دور است.
1- با انتخاب Sync در بخش Home در پنجره Team Explorer نمای هماهنگسازی/Synchronization را باز کنید:
2- گزینه Sync انتخاب کنید
3- هنگام تکمیل عملیات همگام سازی یک پیام تایید نمایش داده می شود.
کشیدن/pull یک fetch و پس از آن merge برای دانلود commitها و به روز رسانی شاخه محلی شما در یک فرمان به جای دو فرمان.با استفاده از pull کردن به سرعت شاخه خود را از شاخه راه دور بروز کنید زمانی که شما در مورد بررسی تغییرات قبل از ادغام آنها را در شاخه خود نگران نیستید.(یعنی زمانی که نگران ادغام تغییرات از شاخه راه دور/remote در شاخه محلی/local نیستید از pull استفاده کنید در غیر اینصور از fetch و merge استفاده کنید)
نمای Sync از پنجره TeamExplorer باز کنید. سپس بر روی لینک Pull در زیر Incoming Commits کلیک کنید تا تغییرات از راه دور را pull کنید و آنها را در شاخه محلی خود ادغام کنید. pull کردن (pulling) فایل های به روز رسانی در پروژه باز شما، پس مطمئن شوید که قبل از pull کردن تغییرات خود را commit کنید.
1- با انتخاب Sync در بخش Home در پنجره Team Explorer نمای هماهنگسازی/Synchronization را باز کنید:
2- گزینه Pull انتخاب کنید تغییرات راه دور را fetch و سپس به branch محلی شما merge کند.(دو لینک Pull وجود دارد، یکی در قسمت بالا و دیگری در قسمت Incoming Commits . شما می توانید از هر یک از آنها استفاده کنید زیرا هر دو آنها یکسان هستند.)
3- هنگامی که عملیات Pull پایان می یابد پیام تایید نمایش داده می شود.
هنگام کار در یک شاخه، ممکن است بخواهید آخرین تغییرات را از شاخه اصلی/master به شاخه خود اضافه کنید. دو روش متفاوت برای انجام این کار وجود دارد: rebase یا merge.
بازسازی rebase : تغییرات ساخته شده در commit ها در شاخه فعلی شما را می گیرد و آنها را در history شاخه دیگری تکرار می کند.history/تاریخچه commit شاخه فعلی شما بازنویسی خواهد شد تا از آخرین commit در شاخه هدف از بازسازی آغاز شود.
ادغام Merge : تغییرات را از شاخه منبع به شاخه هدف با استفاده از یک merge commit، که بخشی از commit history است، ادغام می کند.
توجه: این مقاله رویکرد merge را نشان می دهد. برای کسب اطلاعات بیشتر در زمینه rebase و راهنمایی که روش مناسب برای سناریوی شماست، Apply changes with Rebase - When to rebase vs. merge و Rebase vs merge از کتاب Pro Git مشاهده کنید.
برای merge کردن آخرین تغییرات از شاخه master به شاخه خود:
1-از پنجره TeamExplorer نمای Branches باز کنید.اطمینان حاصل کنید که شاخه مورد نظر شما مورد بررسی قرار گرفته است( checked out شده است. یعنی دروشن شاخه مورد نظر هستید)، راست کلیک کنید شاخه هدف و انتخاب Merge From.
2- ادغام از شاخه/Merge from branch مشخص کنید (که در این مثال master است) و Merge را انتخاب کنید.
اگر هر گونه تضاد ادغام وجود داشته باشد شما در این مرحله مطلع خواهید شد. قبل از ادامه به مرحله بعدی، تضاد ادغام commitها حل کنید Resolve the merge commits .
3- یک پیام برای commit وارد کنید و Commit Staged را انتخاب کنید.
4- هنگامی که شما آماده push کردن commitهای محلی خود، از جمله commit جدید خود به سرور راه دور شدید، از نمای Synchronization را Push کنید.
گردش کار Git از شاخه ها برای جداسازی کار استفاده می کند تا زمانی که آماده تغییرات در شاخه پیش فرض خود هستید، مانند master. درخواست کشیدن/Pull Request، فرآیند مشارکتی است که اجازه می دهد بقیه تیم درباره تغییرات در یک شاخه بحث و موافقت کنند که پس از تایید همه، ادغام/merge انجام شود. استفاده از pull request ها برای دریافت بازخورد اولیه از دیگران در مورد کار در حال پیشرفت است، حتی اگر شما آماده نیستید که این تغییرات را به شاخه دیگری ادغام کنید.
در تصویر بالا شاخه بنفش از طریق یک pull request به شاخه آبی ادغام می شود.تغییرات توسط بازرسان/reviewers در pull request قبل از آنکه کد ادغام/merge شده باشد،مورد بحث قرار گرفته شده است. هنگامی که pull request را تکمیل می کنید، ادغام commit (که در اینجا به عنوان commit آبی رنگ دیده میشود ) وجود دارد که در آن تغییرات شاخه بنفش در شاخه آبی ادغام شده اند.
برای ایجاد یک pull request در Azure Repos:
1- شاخه محلی خود را Push کنید
2- یک pull request برای شاخه ایجاد کنید. شما می توانید این را در نمای Code در وب از زبانه Pull Requests یا برگه Files انجام دهید.
شما همچنین می توانید pull request از ویژوال استودیو را آغاز کنید. هنگامی که به پروژه خود متصل هستید، نمای نمایش Pull Requests را انتخاب کنید.
از نمای Pull Requests می توانید pull requestهایی که توسط شما باز شده و به شما اختصاص داده شده است را مشاهده کنید و می توانید pull request های جدید ایجاد کنید. New Pull Request را برای باز کردن یک مرورگر وب انتخاب کنید که در آن شما می توانید pull request جدید را در وب سایت Azure DevOps Services برای شاخه فعلی خود ایجاد کنید.
3- درخواست کشیدن/pull request را ایجاد کنید.شما باید یک عنوان/Title مشخص و بدون ابهام برای pull request که تغییرات در شاخه را توصیف کند بنویسید. در زمینه توصیف/Description توضیح روشنی از نحوه پیاده سازی تغییرات همراه با هر گونه منابع ای که ممکن است به بررسیکنندگان/ reviewers در درک تغییرات کمک کند بنویسید. شما می توانید work item های VSTS و لینک ها را در اختیار دیگران قرار دهید تا دیگران بتوانند در هنگام بررسی تغییرات خود به همان اندازه زمینه داشته باشند.هر عضو تیمی که میخواهید تغییرات را بررسی کند را اضافه کنید.
هنگامی که شما pull request ایجاد میکنید، شما می توانید دیگران که نیاز به بررسی تغییرات شما دارند را اضافه کنید.شما می توانید کاربران و گروه ها را به pull request که پس از آن ایجاد می شوند اگر دامنه این بررسی نیاز به گسترش دارد اضافه کنید.(توضیحات: یعنی بعد از ایجاد Pull Request میتوانید Reviewer ها را تغییر بدید). شما همچنین می توانید Pull Request را با یک وظیفه در Azure Boards مرتبط کنید تا اجازه دیدی دیگران با این task کار کنند، تغییرات انجام شده برای بررسی آماده هستند.
بررسیکنندگان Pull Request به روز رسانی های پیشنهادی مربوط به شاخه را در قالب تفاوت های فایل بین دو شاخه مشاهده می کنند. بررسیکنندگان می توانند comment های مربوط به هر یک از تغییرات را اضافه کنند و شامل notifications/اطلاعیه های برای دیگر اعضای تیم برای پاسخگویی به یک سؤال یا بازخورد دیگر باشند. شما می توانید تغییرات را انجام دهید و commit ها را برای حل مسائل مطرح شده در بازخورد push کنید و این تغییرات بلافاصله در pull request منعکس می شود.
اگر تغییرات نیاز به توسعه بیشتری برای تکمیل شدن داشته باشید، می توانید pull request را رها کنید(abandon). بعدا می توانید pull request جدیدی را برای بازبینی تغییرات و پیوستن به مکالمه هایی که در pull request رها شده (abandoned)، باز کنید.
شما همچنین می توانید یک pull request را در یک نسخه بسیار اولیه کد خود باز کنید تا از دیگران درخواست بازخورد داشته باشید، حتی اگر کد هنوز هم برای ادغام آماده نیست. هنگامی که بازخورد تیم را دریافت میکنید، می توانید pull request را باز نگه دارید تا گفتگو را ادامه دهید یا pull request را رها کنید تا زمانی که کد شما آماده اشتراکگذاری مجدد باشد.
درخواست کشیدن/pull request خود را پس از اینکه بررسی کنندگان تغییرات تایید کردند با انتخاب Complete در سمت راست بالا از نمای pull request ، تکمیل کنید.
پیام مورد استفاده برای merge commit و توضیح pull request را در صورت نیاز در گفتگو ، بهروز کنید.
<branch name> after merging برای حذف شاخه منبع (source branch) از pull request.پس از تکمیل pull request، گیت/Git/گیت commit history را در شاخه master حفظ می کند، بنابراین مگر اینکه شما در انجام کارهای بیشتری در شاخه برنامه ریزی کنید، حذف آن امن است.
چه اتفاقی می افتد وقتی یک pull request ادغام شود؟
شما باید هر گونه تضادهای ادغام/ merge conflicts بین شاخه pull request و شاخه هدف (target branch) را حل کنید. Git/گیت یک commit جدید (Merge commit) را به انتهای شاخه اصلی(master branch) اضافه می کند. این merge commit متصل به تاریخ قبلی هر دو شاخه اصلی و commit های شاخه ای که به عنوان بخشی از pull request ادغام شده است.
یکی از مزایای استفاده از قابلیت گردش کار شاخه گیت این است که شما به طور فعال تاریخچه کنترل نسخه خود را مدیریت نمی کند.Git این تاریخچه/history را ایجاد می کند، زیرا کد شما را در commit ها خود ذخیره می کنید و تغییرات ادغام بازگردانده می شود به شاخه master با pull request ها.این تاریخچه تولید شده می تواند پیچیده شود وقتی که شما نیاز به روز رسانی یک شاخه با تغییرات از شاخه اصلی برای گرفتن کار commit شده دیگران دارید.commit history شما از شاخه اصلی در نقاط مختلف متفاوت است، و دنبال کردن آن را سخت میکند.
با استفاده از rebase برای حل مشکل بروز رسانی شاخه خود با آخرین تغییرات main branch/شاخه اصلی.Rebase تغییرات ساخته شده در commitهای در شاخه فعلی شما را گرفته و آنها را در تاریخچه شاخه دیگری تکثیر/replays می کند.commit history شاخه فعلی شما بازنویسی خواهد شد تا از آخرین commit در target branch از rebase آغاز شود.Rebase کردن(Rebasing) تغییرات در شاخه از آخرین تغییرات در شاخه اصلی به شما اجازه می دهد تا آزمایش/تست تغییرات خود را بر روی نسخه های اخیر در شاخه اصلی داشته باشید در حالی که Git history تمیز حفظ خواهد شد.
احتیاط کن
بازسازی/Rebase کردن یک ابزار قدرتمند برای دریافت تغییرات یک شاخه اصلی(main branch) است، اما باید در مورد استفاده از آن مراقب باشید.برخی از چیزها قبل از rebase کردن شما در ذهن داشته باشید:
در طی یک rebase کردن، Git تلاش می کند تا تغییراتی را که در commitهای مربوط به شاخه شما ایجاد شده است و تغییرات commitها در شاخه هدف (target branch) را آشکار سازد.هر گونه تضاد بین commitها را به همین شیوه که حل تضاد ادغام(merge conflicts) را حل می کند، حل کنید.
با استفاده از rebase به جای ادغام شاخه ها (merging branches)، نتایج ساده تر دنبال می شود اما history/تاریخچه commitها را کمتر می کند.تیم شما باید تحت شرایطی که باید یک شاخه را rebase کنید موافقت کند.شما هنوز باید همیشه شاخه ها را به یک شاخه اصلی (main branch) از طریق یک pull request ادغام کنید.یک روش پیشنهادی این است که اجازه rebase کردن تغییرات محلی که شما ساخته اید اما با دیگران به اشتراک نگذاشته اید بدهید،اما هنگامی که شما تغییرات را با دیگران به اشتراک گذارشتید merge کنید.این باعث می شود مشکل با بازنویسی تاریخچه (rewriting history) رخ ندهد در حالی که هنوز به شما اجازه می دهد تا به راحتی با تغییرات روبرو شوید در حالی که شما کد خود را در سطح محلی توسعه میدهید.
در Team Explorer به نمای Branches رفته و روی Rebase کلیک کنید.شما یک فرمان برای REBASE تغییرات از شاخه فعلی خود را خواهید دید،و پس از آن یک منوی کشویی مشخص کنید که کدام شاخه از تغییرات در شاخه فعلی باید در بالای آن پخش شود.اگر تضادی وجود دارد،آن را درست مانند merge conflicts در ویژوال استودیو حل کنید.
اخطار: هرگز شاخه ای را که دیگران روی آن کار می کنند، Force Push نکنید.فقط شاخه هایی را Force Push کنید که تنها روی آن کار می کنید.
بعد از یک rebase موفق، شاخه محلی شما تاریخیچه متفاوت از شاخه راه دور شما
خواهد داشت.شما باید شاخه محلی خود را force push کنید تا شاخه راه دور خود را بهروز کنید.
> git push -f users/frank/myfixes
له کردن commit های محلی/Squash local commits
بازسازی/Rebase تعاملی در حال حاضر در ویژوال استودیو پشتیبانی نمی شود، اما شما می توانید از مراحل زیر خط فرمان برای یکی کردن commitهای خود استفاده کنید.
استفاده خاص از REBASE به کم حجم کردن تغییرات ایجاد شده در مجموعه ای از commitها به یک تک commit در دسترس است.این مفید است برای تمیز کردن شدن تاریخچه های commit قبل از اینکه آنها را به یک شاخه از راه دور push کنید.مزایای قابل خواندن مهم است و از آنجایی که هرگز کد مشترک را rebase نمیکنید، می توانید این تغییرات را به راحتی خلاصه کنید.
برای یکی کردن commitها،ابتدا تصمیم بگیرید که چه تعداد از commitها میخواهید به به یک commit له/squash کنید.(یعنی چندتا commit به یک commit تبدیل شود).هنگام اجرای دستور squash لازم نیست دقیقا commitها را مشخص کنید.اگر پنج commit دارید که میخواهید squash کنید، پس مطمئن شوید که تغییرات unstage شده نمی باشد و دستور زیر را اجرا کنید.
> git rebase -i HEAD~5
این یک ویرایشگر را باز می کند که در آن چیزی شبیه به آن خواهید دید:
pick 7b43f3f Updated router.js
pick 00859d9 Updated README.md
pick 9d247f7 initial commits
pick 7068b09 Updated README.md with build instructions
شما اولین تغییرات را نگه دارید ( pick رهاکنید) و سپس برای بقیه تغییرات ،pick به squash تغییر دهید.ویرایشگر را ذخیره و ببندید.Git تلاش خواهد کرد commitها را به یک commit تبدیل کند.پس از اتمام rebase، یک پنجره ویرایشگر جدید را باز شده خواهید داشت که در آن Git از شما می خواهد که یک پیغام commit برای commit با تغییرات ترکیب شده بنویسید.شما می خواهید این را به یک خط از متن متصل کنید (درست مثل اینکه شما برای commit معمولی) و ذخیره و از ویرایشگر خارج شوید.
کاربران Azure DevOps و TFS می توانند pull requestهای خود را برای squash merge/ادغام اسکواش commit ها به شاخه اصلی/master branch اضافه کنند.(یعنی از طریق pull request بخش squash merge کار های بالا را انجام دهند)
کپی کردن commit های از یک شاخه به شاخه دیگری با استفاده از cherry-pick(گیلاس چینی).بر خلاف یک merge یا rebase، چیدن گیلاس/cherry-pick فقط تغییرات را از commitهای انتخابی شما به جای همه تغییرات در یک شاخه به ارمغان می آورد.(یعنی کل شاخه را برنمیدارد بیاورد فقط تغییرات را میآورد)
چیدن گیلاس(انتخاب بین موارد دردسترس)/cherry-pick یک راه عالی برای مقابله با این مشکلات رایج است:
1- باز کردن Team Explorer و رفتن (checkout کردن) به شاخه مورد نظر که میخواهید از تغییرات cherry-pick استفاده کنید در نمای Branches
2- راست کلیک بر روی شاخه حاوی تغییراتی که می خواهید و View History... را انتخاب کنید.
3- راست کلیک بر روی commit می خواهید cherry-pick کنید و Cherry-pick انتخاب کنید.
ویژوال استودیو تغییرات ساخته شده در آن commit را به یک(commit) جدید در شاخه فعلی شما کپی می کند.
این روند را برای هر commitی که باید در شاخه فعلی خود کپی کنید، تکرار کنید.
هنگامی که شما یک شاخه را به (شاخه)دیگری ادغام می کنید، تغییرات فایل از commitها در یک شاخه می تواند با تغییرات (در شاخه) دیگری اختلاف داشته باشد. Git تلاش می کند تا این تغییرات را با استفاده از history در مخزن شما برای تعیین اینکه چه فایل های ادغام شده باید شبیه باشند، حل کند.هنگامی که چگونگی ادغام تغییرات روشن نیست، Git ادغام را متوقف میکند و به شما می گوید که کدام فایل ها در تضاد هستند.
تصویر زیر یک نمونه بسیار ساده از چگونگی تضاد تغییرات در Git را نشان می دهد.هر دو شاخه master و bugfix update خطوط مشابهی از کد منبع باز بروز می کنند.
اگر شما سعی کنید شاخه bugfix را به master ادغام کنید، Git نمی تواند تعیین کند که چه تغییری در نسخه ی ادغام شده استفاده شود.ممکن است بخواهید تغییرات در شاخه master، شاخه bugfix یا ترکیبی از این دو را نگه دارید.تضاد را با ادغام commit در master branch که و یکسانسازی تغییرات متضاد بین دو شاخه حل کند.
گیت/Git برای جلوگیری از تضادهای ادغام چه کاری انجام می دهد؟
گیت/Git یک history کامل از تمام تغییرات انجام شده در REPO/مخزن شما را نگه می دارد.Git از این history و همچنین روابط بین commitها استفاده می کند تا ببیند آیا می تواند تغییرات را مرتب کند و هم ادغام را به صورت خودکار حل کند.تضادها تنها زمانی اتفاق می افتند که از history شما مشخص نیست که چگونه تغییرات به همان خطوط در فایل های مشابه باید ادغام شوند.
جلوگیری کردن از تضادهای ادغام Preventing merge conflicts
گیت بسیار راحت در بیشتر شرایط به طور خودکار ادغام تغییرات فایل انجام میدهد ، به شرطی که محتویات فایل به طور چشمگیری بین commitها تغییر نکند.قبل از باز کردن یک pull request، شاخه های درحال rebase کردن/rebasing را بررسی کنید اگر شاخه شما خیلی دور از شاخه اصلی شما باشد.شاخه های rebase شده بدون تضاد در شاخه اصلی/main branch شما ادغام خواهند شد.
1- هنگامی که شما تغییرات را pull میکنید و یا تلاش برای ادغام دو شاخه دارید، شما از تضاد(های) ادغام مطلع خواهید شد.
2- اطلاعیه تضاد ظاهر می شود.برای شروع حل فایل دارای تضاد(ها) روی Conflicts کلیک کنید
3- این لیستی از فایل هایی با تضادها را نمایش می دهد.انتخاب یک فایل به شما امکان می دهد تغییرات شاخه منبع(source branch) با آنها ادغام کنید را با دکمه Take Source پذیرش کنید یا تغییراتی را در شاخه ای که با استفاده از Keep Target ادغام می کنید، قبول کنید.(اگر میخواهید تغییرات شاخه منبع"شاخه اصلی" به عنوان ادغام بپذیرید باید دکمه TakeSource کلیک کنید با این کار تغییرات در شاخه منبع ادغام میشود و اگر میخواهید بجای تغییرات شاخه منبع، تغیرات شاخه ای که در حال ادغام آن"به شاخه اصلی" هستید اعمال کنید KeepTarget را کلیک کنید).شما می توانید به صورت دستی تغییرات ادغام کنید با انتخاب Merge، پس از وارد کردن تغییرات به طور مستقیم به ابزار ادغام مشخص شده در Git settings/تنظیمات Git خود.
4- از گزینه های جعبه کنار خطوط اصلاح شده برای تغییر بین تغییرات راه دور و محلی استفاده کنید و یا ویرایش نتایج به طور مستقیم در ویرایشگر نتیجه/Result در زیر ویرایشگر Source/منبع و Target/هدف در نمای diff.
5- هنگامی که انجام تغییرات انجام شد، روی Accept Merge کلیک کنید. این را برای تمام فایل های متضاد تکرار کنید.
6-نمای Changes در TeamExplorer را باز و commit تغییرات برای ایجاد ادغام commit و حل تضاد کنید
مقایسه commitهای متضاد و همچنین تفاوت بین history مشترک با گزینه های در ابزار ادغام ویژوال استودیو را مقایسه کنید.
هنگام لغو تغییرات در Git ابتدا تصمیم بگیرید که چه نوع تغییراتی را که میخواهید undo کنید. این تغییرات به سه دسته تقسیم می شود:
اخطار:بازگرداندن محتویات فایل به یک نسخه خوب و شناخته شده، باعث حذف ناخواسته تغییرات میشود.اگر فکر می کنید ممکن است این تغییرات را بعدا بخواهید،به جای آنها stashing در نظر بگیرید.
ویژوال استودیو 2015 و 2017
1- نمای Changes در TeamExplorer باز کنید
2- زیر بخش Changes ،فایل را که میخواهید به نسخه قبلی بازگردانید، پیدا کنید.اگر تغییر شما stage شده باشد،با کلیک راست و انتخاب Unstage، آن را از بخش Staged Changes حذف کنید.
3- برروی فایل راست کلیک کرده و Undo Changes انتخاب کنید
از revert برای undo کردن تغییرات انجام شده در انجام commitهای push شده به شاخه های مشترک.دستور revert یک commit جدید ایجاد می کند که تغییرات را در یک commit قبلی خنثی/undoes می کند.در یک revert تاریخچه/history بازنویسی نمیشود،برای استفاده از آن در هنگام کار با دیگران، امن است.
1- نمای Changes در TeamExplorer باز کنید.
2- گزینه Actions انتخاب و از منوی کشویی View History اتخاب کنید.
3-پنجره history ظاهر میشود، روی commit که میخواهید undo کنید راست کلیک کرده و گزینه Revert از منو انتخاب کنید
از بازنشانی/reset استفاده کنید تا یک شاخه در مخزن محلی خود را به محتوای یک commit قبلی بازگردانید.شایع ترین استفاده از دستور reset این است که به راحتی تمام فایل های تغییر داده شده را از آخرین commit حذف کرده و فایل ها را به حالت ای که آنها در تازه ترین commit را بازگردانید.(یعنی اگر commit تغییر دادین و تغییرات باب میل شما نبود خواستید commit به حالت اولیه برگردانید باید از reset استفاده کنید).
اخطار: روی branch هایی که با دیگران به اشتراک گذاشتید هرگز reset استفاده نکنید،بجاش از revert استفاده کنید.
1- نمای Changes در TeamExplorer باز کنید
2- گزینه Actions انتخاب و از منوی کشویی View History اتخاب کنید.
3-پنجره history ظاهر میشود، روی commit که میخواهید مخزن را reset کنید راست کلیک کرده و گزینه Reset از منو انتخاب کنید.
4- گزینه Reset and delete changes... انتخاب کنید.
یک reset کردن روی همه فایل ها در شاخه فعلی در مخزن تاثیر می گذارد، نه فقط آنهایی که در دایرکتوری فعلی شما هستند.reset فقط تغییراتی را که هنوز commit نشده اند discards/رد می کند.
نباید هر فایل ایجاد شده یا به روز شده در کد شما به Git/گیت commit شود.فایل های موقت از محیط توسعه، خروجی های تست و لاگهای مربوط، نمونه ای از fileهایی هستند که شما ایجاد می کنید، اما بخشی از کد شما نیستند.سفارشی کردن فایل های Git از طریق ویژگی gitignore.
برای جلوگیری از راه اندازی فایل های ناخواسته Git یک فایل gitignore را در repos Git خود ایجاد کنید.به اشتراک گذاشتن فایل gitignore در شاخه پیش فرض در repo خود، بنابراین شما و تیم شما می توانید آن را به روز کنید تا تغییراتی را که برای نادیده گرفتن فایل ها است را تغییر دهید.
ایجاد یک .gitignore
ویژوال استودیو به طور خودکار یک فایل .gitignore را در repo شما ایجاد می کند زمانی که برای پروژه خود جدید repo ایجاد کنید.
گیت/Git یک فایل .gitignore را به پوشه و هر پوشه زیرین که در آن واقع شده است اعمال می کند.ما به شدت توصیه کردیم که .gitignore را در پوشه ریشه مخزن خود قرار دهد تا از سردرگمی جلوگیری شود.
سفارشی کردن .gitignore
تغییر فایل .gitignore شامل انواع فایلها، مسیرها و الگوهای فایل در مخزن شماست. Git شروع به نادیده گرفتن این فایلها در اسرع وقت و بروز رسانی .gitignore می کند، اما مطمئن شوید که این تغییرات را commit شده، اگر دیگران در تیم شما نیاز به همان مجموعه ای از فایل های نادیده گرفته شده داشته باشند.(یعنی اگر دیگران هم باید از تغییرات فایل بروزشده استفاده کنند باید فایل با تغییرات بروز شده را در شاخه موردنظر "در شاخه پیشفرض master برای جلوگیری از سردرگمی در آینده" commit کنید).
شما می توانید فایل .gitignore خود را برای repo خود را با رفتن به نمای Settings در پنجره TeamExplorer و سپس انتخاب کردن Repository Settings ویرایش کنید. لینک Edit در زیر .gitignore خود را انتخاب کنید.
هر خط در .gitignore یک فایل یا مجموعه ای از فایل ها را مطابق با یک الگو محروم می کند.دستور زبان کامل gitignore بسیار انعطاف پذیر است.در اینجا چند نمونه از رایج ترین نوشته ها آمده است:
# ignore a single file mycode.class # ignore an entire directory /mydebugdir/ # ignore a file type (ignore all of json files) *.json # add an exception (using !) to the preceding rule to track a specific file !package.json
توجه:کاربران ویندوز: تمام مسیرهای فایل در فایل .igitignore از جدا کننده اسلش/forward slash استفاده می کنند و نه یک بک سلش\backslash.
فایل.gitignore شما در بین اعضای تیم به عنوان یک فایل commit شده و push شده به مخزن به اشتراک گذاشته شده.برای حذف فایلها تنها در سیستم شما بدون push دادن تغییرات به بقیه تیم ،فایل .git/info/exclude را در مخزن/repo محلی خود ویرایش کنید.تغییرات در این فایل با دیگران به اشتراک گذاشته نخواهد شد و تنها به فایل هایی که در مخزن هستند اعمال می شود. syntax برای این فایل همان است که در .gitignore استفاده می شود.
برای استفاده در سرتاسر مخزن ها در سیستم شما، با استفاده از خط فرمان git config tool، یک global .gitignore تنظیم کنید:
> git config core.excludesfile C:\Users\frank\.gitignore_global
این به خصوص برای نادیده گرفتن انواع فایل هایی که شما نمیخواهید commit شوند، مانند باینریهای کامپایل شده مفید است.
نادیده گرفتن تغییرات به طور موقت
در طول توسعه، راحت است که ردیابی تغییرات فایل به یک فایل commit شده به مخزن گیت/repo git خود را متوقف کنید.این بسیار راحت است هنگام سفارشی کردن تنظیمات یا فایل های پیکربندی که بخشی از منبع پروژه شما برای محیط کار شما است.
> git update-index --assume-unchanged <file>
ادامه ردیابی فایل ها با:
> git update-index --no-assume-unchanged <file>
نادیده گرفتن تغییرات به طور دائمی یک فایل
اگر یک فایل قبلا توسط Git ردیابی شده است، اضافه کردن آن فایل به .gitignore برای نادیده گرفتن تغییرات در فایل کافی نیست.شما همچنین باید اطلاعات مربوط به فایل را از فهرست Git (منظور Git's index) حذف کنید:
این مراحل فایل را از سیستم شما حذف نخواهد کرد. آنها فقط به Git می گویند که به روز رسانی های آینده در فایل را نادیده بگیرند.
1-فایل را در .gitignore خود اضافه کنید.
2- کد زیر را اجرا کنید
> git rm --cached <file>
3- فایل حذف شده را commit کرده و .gitignore در مخزن خود بروزرسانی کنید.
گیت/Git از اطلاعات مرجع والد/پدر ذخیره شده در هر commit برای مدیریت یک تاریخچه کامل/full history توسعه شما استفاده می کند.برای بررسی زمانی که تغییرات فایل انجام شده و تفاوت بین نسخه های کد شما را تعیین کند، این commit history را مرور می کند.استفاده Git از شاخه های ویژگی (feature branches) و ادغام از طریق pull requestها به این معنی است که commit history توسعه شما مستقیما تشکیل نمی دهد،بلکه خط زمانی است.هنگامی که از history برای مقایسه نسخه ها استفاده می کنید، به جای تغییر فایل بین دو نقطه در زمان، فکر میکنید تغییرات فایل بین دو commit می شوید.(برای مقاسه نسخه های مختلف 2 فایل شما فکر میکنید تغییرات بین 2 commit هست ولی درواقعی میان دو نقطه زمانی هست).یک تغییر اخیر در یک فایل در شاخه master ممکن است از دو هفته پیش در یک شاخه مشخص commit اش ایجاد شده باشد اما تنها دیروز ادغام شده باشند.
مقایسه تغییرات بین دو نسخه از یک فایل در مخرن Git شما.
1- روی Solution Explorer کلیک راست کرده و View History... انتخاب کنید.پنجره history ظاهر میشود که commit ID،author،description همه تغییرات فایل روی مخزن محلی در سرتاسر شاخه ها نمایش میدهد
2- پیدا کردن آخرین commit برای یک branch با دنبال کردن نام آن بر روی یک فلش در سمت راست یک commit.
3- با کلیک راست و انتخاب Compare with previous...، تغییرات از نسخه قبلی فایل را مشاهده کنید.تغییرات بین هر دو نسخه را با انتخاب هر دو commit، سپس با کلیک راست و انتخاب گزینه Compare...
4- نمای diff خطوط حذف شده از commit قدیمی تر و خطوط اضافه شده جدید نشان می دهد.
یک نسخه خاص از فایل را از history خود بازیابی کنید، حتی اگر فایل در آخرین نسخه کد شما حذف شده یا تغییر نام داده شده.بازیابی کردن یک نسخه قدیمی از فایل، هیچ تغییری در شاخه فعلی شما ایجاد نمی کند.یک commit جدید برای آوردن نسخه قدیمی فایل به branch شما ایجاد میکند.
برای بازیابی یک نسخه قبلی از فایل موجود در پروژه Visual Studio شما:
1- روی Solution Explorer کلیک راست کرده و View History... انتخاب کنید.نمای History ویژوال استودیو ظاهر خواهد شد، commit ها در repo/مخزن که فایل را بروز کرده اید نمایش میدهد.شما می توانیدcommitها را برای پیدا کردن commit دقیق با نسخه فایل که می خواهید بازگردانی/restore کنید فیلتر کنید.برای باز کردن آن در ویژوال استودیو بر روی نسخه دوبار کلیک کنید.
برای بازیابی/retrieve یک نسخه قبلی از یک فایل که در یک commit قبلی حذف شد:
1- از Team Explorer نمای Changes باز و از منوی کشویی Action گزینه View History انتخاب کنید
2- راست کلیک بر روی commit حاوی نسخه فایلی که می خواهید بازگردانید و View Commit Details را انتخاب کنید
راست کلیک بر روی فایل برای بازگرداندن در Commit Details درون Team Explorer و Open را انتخاب کنید.
توجه:نسخه بازیابی شده فایل به طور خودکار در پروژه شما ذخیره نمی شود.برای ذخیره نسخه بازیابی شده در پروژه خود، Save As ... را از منوی File انتخاب کنید.اگر فایل را در پروژه فعلی خود ذخیره کردید، یا به عنوان یک فایل جدید یا رونویسی یک موجودیت/overwriting an existing one (منظور overwrite کردن فایل موجود)، باید تغییرات خود را برای اضافه کردن نسخه قبلی به شاخه محلی خود commit کنید.(درکل وقتی فایل بازیابی کردین یا فایل جدید هست یا فایل overwite روی فایل موجود میشود بعد حتما باید commit کنید تا به شاخه فعلی اضافه شود).
بررسی/Review تغییرات احتمالی از یک merge یا rebase با مقایسه شاخه ها به طور مستقیم.شما می توانید هر دو شاخه محلی و راه دور/local and remote را مقایسه کنید، زمانب مفید است که برای بررسی احتمال/پتانسیل تضادهای ادغام/merge conflicts یا ببینید که چگونه تغییرات انجام شده دیگران را بر کار شما تاثیر می گذارد.
1- مقایسه شاخه ها را می توان در پورتال وب انجام داد که می توانید با انتخاب Web Portal از Team explorer و نمای Home در ویژوال استودیو دسترسی پیدا کنید.
2- شاخه ها/Branches را از منوی زیر Code انتخاب کنید.محل شاخه خود را پیدا کرده و نماد ... را انتخاب کنید تا گزینه های شاخه را مشاهده کنید.Compare branches انتخاب کنید
3- از منوی کشویی در بالای صفحه شاخه ای را انتخاب کنید تا مقایسه شود.این نمای کلیه تغییرات بین شاخه ها را نمایش می دهد.
خوب دیگه تمام شد اگر جاییش بنظر شما اشتباه ترجمه شده ابتدا منبع اصلی را چکنید بعد که مطمئن شدید به من هم اطلاعاع بدید تا درستش کنم
