تصور کنید که با یکی از دوستانتان در حال فعالیت بر روی یک پروژه هستید. یعنی قسمتی از کار را شما برعهده دارید و انجام می دهید و قسمتی دیگر را دوست شما انجام می دهد. حال شما چگونه با همدیگر هماهنگ می شوید؟ یعنی چگونه دوست شما از کارهایی که شما انجام داده اید مطلع می شود و یا شما چطور به کارهایی که اوانجام داده است دسترسی خواهید داشت؟
خب راه معمول و ساده ای که الان هم انجام می شود و اولین راهی است که به فکر می رسد این است که شما کارهایی که از پروژه انجام داده اید را بر روی فلش بریزید و به دوستتان نشان دهید و او نیز فایل های پروژه خود را بر روی فلش بریزد و به شما بدهد. حال این راه حل چه مشکلاتی می تواند داشته باشد؟ خب اولین مشکل این که شما دو تا پروژه دارید یا از یک پروژه دوتا نسخه دارید حالا چطوری اینها را یکی کنید که بتوانید نتیجه کار دو نفره را نشان دهید؟ خب برای این هم یکی از شما یا هردوی شما باید یکی دو ساعت وقت بگذارد و تغییرات هر دو را اعمال کند و یک پروژه واحد را بسازد.
حالا برای این کار باید بر روی کارهایی که از دوطرف اعمال شده کاملا مسلط باشد. به شما قول می دهم که این کار بسیار خسته کننده خواهد بود. برای مثال اگر خطایی پیدا شود چه مشکلی پیش خواهد آمد؟ اگر یکی از شما مسئول UI باشید و یکی دیگر مسئول کد backend باشد چه؟ با تخصصی شدن کار ها استفاده از این روش سخت خواهد بود. مشکل دیگری که ممکن است پیش بیاید این است که تصور کنید که نام پروژه شما MyProject است.
حالا شما تغییراتی را بر روی پروژه انجام می دهید و شاید در قالب این تغییرات کدهایی را حذف کنید. ولی برای این که کد قبلی را هم داشته باشید که اگر مشکلی پیش آمد آن را دوباره برگردانید پروژه را در یک پوشه دیگر به نام MyProject2 ذخیره می کنید. بعد از یک مدت خواهید دید که چند تا پوشه MyProject دارید که پسوند عددی مختلف دارند و یا پسوند تاریخ دارند. حال ببینید که چه حجمی از فضای شما اشغال می شود. اینجاست که اگر بخواهید به دنبال کدی بگردید باید بگوییم پیدا کنید پرتقال فروش را ....
شاید شما بگویید که خب من که تنهایی بر روی یک پروژه کار می کنم و با کسی روی پروژه کار نمی کنم پس مشکلی برایم پیش نمی آید. ولی اینطور نیست. اگر شما تنها بر روی یک پروژه کار می کنید و دوست یا تیمی ندارید باز به مشکل برمی خورید. در نظر بگیرید که شما در حال کار بر روی پروژه هستید. بعد از یک مدت به این نتیجه می رسید که راهی که رفته اید اشتباه بوده و از یک مرحله از پروژه باید با یک روش دیگر پیش می رفته اید.
در این صورت باید کارهایی را که انجام داده اید را به طور دستی حذف کنید و تغییرات جدید را اعمال نمایید. که این کار هم به وقت نیاز دارد و باعث می شود که پیشرفت پروژه کم شود. و یا اگر خود شما بر روی دوعدد کامپیوتر مشغول برنامه نویسی هستید. برای مثال هم در خانه بر روی پروژه کار می کنید و هم سرکار بر روی پروژه کار می کنید مشکلاتی در کار با فلش و سی دی و .... برای شما پیش خواهد آمد. حال اگر برای هارد شما مشکلی پیش بیاید و یا لپتاپ شما دزدیده شود آن وقت است که باید فریاد از دل برآورید. برای حل این مشکلات در کار های تیمی و حتی کار های شخصی از version control و یا source control استفاده می شود.
سورس کنترل یک مکانیزمی است که امکان می دهد که یک پروژه بر روی آن قرار گیرد و تغییرات در آن مدیریت شود و همچنین سورسی که بر روی آن است مدیریت شود. به شکلی که همه ی تغییرات بر روی پروژه را به صورت بهینه ای در خود نگهداری می کند و این قابلیت را دارد که هر وقت یک مجموعه تغییرات بر روی پروژه اعمال شد آن را در یک رکورد ذخیره می کند و تغییرات فایل ها را اعمال می کند و همچنین امکان قرار دادن کامنت و توضیحات را نیز می دهد که اعضای تیم یا خود شخص متوجه بشود که در تغییری که ایجاد شده است کدام فایل های تغییر کرده اند و کدام فایل ها دست نخورده باقی مانده اند.
با استفاده از سورس کنترل شما همیشه مطمئن هستید که آخرین ورژن برنامه را دارید و اگر ویژگی هایی به برنامه اضافه شده است و توسط برنامه نویس مربوطه نهایی شده است در پروژه وجود دارد و شما لازم نیست نگران آن باشید که این تغییرات را خودتان اعمال کنید. در ضمن هر وقت که شما بخواهید که سورس را به عقب برگردانید و تغییراتی را که بر روی پروژه انجام داده اید منحل کنید به سادگی می توانید این کار را انجام دهید و لازم نیست که تغییرات را به صورت دستی خنثی نمایید.
با استفاده از سورس کنترل شما می توانید ببینید که هر تغییر در چه تاریخی و توسط کدام یک از اعضای تیم انجام شده است. سورس کنترل کل تاریخچه تغییرات برنامه را در خود نگهداری می کند ولی نه به شکلی که گفتیم که هر بار یک پروژه از اول ساخته شده باشد بلکه فقط فایل هایی را که تغییر کرده است را در تاریخچه اش اضافه می کند. به همین دلیل استفاده از فضای ذخیره سازی پروژه هم بسیار بهینه استفاده می شود.
در حال حاضر همه تیم های برنامه نویسی پروژه های خود را بر روی سورس کنترل نگهداری می کنند و مدیریت سورس خود را به آن داده اند. در حال حاضر سورس کنترل های متفاوتی وجود دارند که معروف ترین آن ها Git می باشد ولی علاوه بر آن می توان از SVN و TFS نیز نام برد. البته فقط اینها سورس کنترل های موجود نیستند ولی معروفترینشان این 3 تا می باشد. در این مطلب به معرفی سورس کنترل و لزوم استفاده از آن پرداختیم در قسمت های بعدی به بررسی سورس کنترل ها می پردازیم.
حال به ادامه بحث در مورد سورس کنترل ها می پردازیم. در کار های تیمی معمولا سورس کنترل را بر روی یک سرور راه اندازی می کنند و همه ماشین ها و برنامه نویسان به آن متصل می شوند و سورس برنامه را از آن دریافت می کنند.
سورس کنترل ها انواع مختلفی دارند. و این دسته بندی به نوع پیاده سازی سورس کنترل ها بستگی دارد. سورس کنترل ها را به دو نوع اصلی تقسیم بندی می کنیم. سورس کنترل های متمرکز و سورس کنترل های توزیع شده. این تقسیم بندی بر اساس نحوه نگهداری و مدیریت سورس می باشد.
در این نسخه که ابتدایی ترین نسخه از ورژن کنترل ها می باشد سیستم به این شکل است که بعد از که تغییراتی را در پروژه انجام دادیم آن را در یک پوشه دیگر ذخیره می کنیم. همانطور که در مقاله قبلی گفتیم این روش با این که خیلی ساده است ولی احتمال خطای زیادی دارد و از نظر فضای ذخیره سازی هم بهینه نیست.
در این نوع سورس کنترل ها یک سرور اصلی وجود دارد که داده های متادیتا و مدیریتی در مورد سورس ها در آن نگهداری می شود و هر برنامه نویسی که درخواست سورس را بدهد پروژه یا قسمتی از پروژه که برای او وجود ندارد یا ورژن آن قدیمی است برای او ارسال می شود. ولی هیچ داده مدیریتی برای او ارسال نمی شود و همه داده های مدیریتی و ورژن های قدیمی و تاریخچه بر روی سرور نگهداری می شود. برای مثال TFS یک سورس کنترل متمرکز است. این نوع سورس کنترل کمک بسیاری به برنامه نویسی می کند.
همچنین قابلیتهای ویژه ای مانند single checkout را نیز ارائه میدهد. به عمل گرفتن سورس از سرور سورس کنترل checkout میگوییم. حال single checkout به این معنی است که اجازه دهیم که در یک زمان تنها یک کاربر بر روی یک فایل کار کند. یعنی وقتی که یک کاربر در حال کار بر روی یک فایل از پروژه است آن فایل برای برنامه نویسان و کاربران دیگر در حالت قفل باشد تا وقتی که برنامه نویسی که بر روی فایل مورد نظر کار میکرد کار خود را به اتمام برساند و تغییرات را check in کند. به اعمال تغییرات انجام شده بر روی سرور check in می گوییم.
این قابلیت در TFS یا SVN وجود دارد. زیرا که آنها از نوع سورس کنترل متمرکز میباشند. یکی از مشکلاتی که این نوع version control ها دارند این است که یک نقطه مرکزی دارند. حال اگر سرور سورس کنترل به هر دلیلی از کار بیفتد عملاً سورس کنترل دیگر کارایی ندارد و نمیتوان از آن استفاده کرد و در این حالت اگر کاربر بخواهد فایلی را از سورس کنترل checkout کند یا بخواهد فایلی را check in کند نمیتواند این کار را بکند و درواقع تیم بیکار می شود.
برای حل مشکلاتی که برای سورس کنترل های متمرکز گفتیم سورس کنترل های توزیع شده به وجود آمدند. از سورس کنترل هایی که توزیع شده هستند میتوان Git , Mercurial, Bazaar ,Darcs را نام برد. دراین نوع سورس کنترل ها وقتی که برنامه نویسان عمل checkout را انجام میدهند فقط سورس پروژه را دریافت نمیکنند بلکه یک کپی آینه وار از کل فایلها دریافت میکنند هم فایلهای پروژه و هم فایلهای مدیریتی سورس کنترل و تاریخچه پروژه را دریافت می کنند.
با این کار اگر حتی سرور اصلی سورس کنترل هم از کار بیفتد و یا از بین برود باز مشکلی پیش نمیآید زیرا که همه کلاینت ها یک کپی از کل فایلها دارند و در صورت بروز مشکل یکی از این نسخه ها جایگزین نسخه سرور شوند. یکی از قابلیتهایی که در این سیستمهای سورس کنترل وجود دارد این است که کلاینت ها را میتوان در گروههای مختلف قرار داد که همزمان با هم بر روی پروژه کار کنند. معروف ترین سورس کنترل توزیع شده Git می باشد.
git یک سورس کنترل اوپن سورس است که می توان آن را به راحتی بر روی یک سیستم معمولی هم راه اندازی کرد. git با ابزار های برنامه نویسی بسیاری سازگار است برای مثال اگر شما جاوا کار می کنید نرم افزار intellij خود به صورت درونی گیت را پشتیبانی می کند و می تواند به راحتی و به طور کامل با آن ارتباط داشته باشد. و یا اگر شما با تکنولوژی دات نت کار می کنید در ویژوال استودیو 2015 به بعد به صورت درونی گیت برای کنترل پروژه قرار داده شده است. به شکلی که وقتی شما یک پروژه را می سازید خود ويژوال استودیو برای آن یک گیت محلی در نظر می گیرد.
با همه این حالات اگر شما بخواهید فایل های خود را خارج از محیط IDE در گیت قرار دهید و با یک سرور گیت ارتباط داشته باشید نیز می توانید از انواع متنوع ابزار های ویژوال و کنسولی استفاده کنید. البته رابط اصلی گیت کنسول است و شما باید دستورات را تایپ نمایید ولی می توانید از ابزار های ویژوال نیز استفاده کنید. یک سرور معروف گیت که اوپن سورس نیز می باشد و پروژه های بسیاری بر روی آن قرار دارد گیت هاب (github) می باشد که پروژه های بسیاری بر روی آن قرار دارند. در این مطلب به انواع سورس کنترل ها پرداختیم. در مطلب بعدی بیشتر وارد سورس کنترل ها خواهیم شد و آنها را شرح می دهیم
سلام به ITPROهای عزیز تا الان با توجه به دو مقاله قبلی یک دید کلی از سورس کنترل ها به دست آورده ایم. در این مطلب می خواهیم در مورد عملیات و کارهایی که می شود در سورس کنترل انجام داد نیز صبحت کنیم. در این بخش ابتدا به کارها و عملیاتی که می توان بر روی Git انجام داد صحبت می کنیم و سپس به اعمالی که می توان بر روی TFS می توان انجام داد صحبت خواهیم کرد. دقت کنید که این عملیات مربوط به کارهایی است که هنگام استفاده از این سورس کنترل ها انجام می دهیم می باشد و فقط در مورد عملیات هنگام استفاده صحبت خواهیم کرد.
بر روی سورس کنترل Git اعمال متنوعی برای کار با سورس انجام می شود که در ادامه آمده است. شما برای استفاده از گیت می توانید هم از خط فرمان آن استفاده کنید و یا هم میتوانید از ابزارهای ویژوالی که تعداد آنها هم بسیار است استفاده کنید. ما در این مطلب به معنی و مفهوم هرکدام از عملیات میپردازیم.
حالتی را در نظر بگیرید که شما در یک تیم عضو شدهاید و یا میخواهید از سایت گیت هاب یک سورس را بگیرید در حالی که هیچ فایلی از سورس مورد نظر را ندارید. در این حالت شما باید پروژه را clone کنید. به عبارت دیگر عملی که برای اولین بار انجام میشود و کل پروژه را به همراه repository های آن دریافت میکند را clone می گوییم. با clone کردن یک پروژه کل فایلهای پروژه مورد نظر به سیستم شما کپی میشود و در محلی که مشخص کردهاید ریخته می شود.
کل فایلها و تنظیمات و تاریخچه تغییر فایلها به سیستم شما کپی خواهد شد. دوستان دقت کنند که تاریخچه پروژه معمولاً در سیستم گیت در یک پوشه git نگهداری می شود.که معمولاً این پوشه مخفی می باشد.در ضمن اینطور نیست که بگوییم چون این پوشه تاریخچه و اطلاعات را نگهداری میکند حجم بسیار زیادی دارد شما اگر این پوشه را ببینید میفهمید که حجم کمی را به خود اختصاص داده است.
گفتیم که همه ی اعضای تیم پروژه را دریافت میکنند و کار های و وظایف خود را بر روی آن انجام میدهند. حال اگر بخواهند که تغییرات خود را دسته بندی نمایند ولی فعلاً آن را بر روی سرور ارسال نکنند از کامیت استفاده می کنند. یعنی کامیت برای تغییرات یک رکورد ثبت میکند و فایلهایی که تغییر کردهاند را نیز ثبت می نماید. همچنین هنگام کامیت باید یک سری توضیحات در مورد تغییرات انجام شده به عنوان کامنت برای کامیت قرار دهید. سپس این تغییرات بر روی سیستم شما ذخیره میشود دقت کنید که فقط بر روی سیستم شما ذخیره خواهد شد و هنوز بر روی سرور اصلی اعمال نشده است.
اگر شما کامیت انجام داده باشید و از انجام آن پشیمان شده باشید شما میتوانید آن کامیت را revert کنید. این کار باعث میشود که در رکوردهای کامیت یک کامیت جدید اضافه شود که تغییرات کامیت قبلی را ندارد. به عبارت دیگر revert کردن undo کردن تغییراتی است که انجام داده ایم. البته در سیستم گیت عملیات دیگری نیز برای undo کردن وجود دارند مانند reset و یا checkout که پیشنهاد میشود خود شما در مورد آنها مطالعه کنید.
وقتی که یک سری تغییرات انجام شد و شما نیز آنها را کامیت کردید تغییرات بر روی سیستم شما انجام شده است و هنوز بر روی سرور آپلود نشده است. پس بقیه اعضای تیم نمیتوانند از تغییرات شما خبردار شوند. برای اینکه تغییرات شما بر روی سرور آپلود شود شما باید کامیت های انجام شده را push کنید. دقت کنید که اول باید کامیت کنید سپس کامیت ها را push نمایید. با این کار فایلهای تغییر داده شده شما به سرور انتقال می یابند و بقیه نیز میتوانند تغییرات شما را با جزئیات مشاهده کنند.
اگر شما بخواهید تغییرات انجام شده توسط دیگر اعضای تیم را بر روی کامپیوتر خود لود کنید باید این از سرور عمل pull را انجام دهید. با این کار بررسی میشود که کدام یک از فایلهایی که دست شما است تغییر کرده است. سپس آخرین نسخه از آن فایلها از سرور گرفته و بر روی سیستم شما قرار داده می شوند. همچنین repository شما نیز آپدیت خواهد شد.
حالتی را در نظر بگیریدکه شما بر روی یک فایل کار میکنید و یکی دیگر از اعضای تیم نیز بر روی همان فایل کار می کند. حال کار شما با فایل تمام شده و آن را کامیت کرده و بر روی سرور push میکنید. حال هم تیمی شما تغییراتی که شما انجام دادهاید را ندارد. چون او هنوز pull نکرده است وهمچنین او نیز فایل مورد نظر را تغییر داده است. وقتی که هم تیمی شما می خواهد فایل را push کند سیستم گیت تشخیص میدهد که فایل قبلاً هم تغییر کرده است. بنابراین پیام میدهد که شما باید فایل را merge کنید.
یعنی تغییرات شما وخودش را در یک فایل قرار دهد و جاهایی را که با هم تداخل دارند را تشخیص بدهد و مشکل را برطرف کند. برای merge کردن باید دو فایل را مقایسه یا compare کند. ابزار های بسیاری هستند که دو صفحه کد را با هم مقایسه میکنند و جاهایی که بین دو فایل متفاوت است را به رنگ دیگری نشان میدهند و این قابلیت را دارند که هر قسمت از تغییرات را که خواستید از فایلی به فایل دیگر اعمال کنید.عملیاتی که گفته شد سادهترین عملیات مربوط به سیستم سورس کنترل گیت بود و حداقل چیزی بود که شما برای کار با گیت به آنها نیاز خواهید داشت. در قسمت بعدی در مورد TFS صحبت خواهیم کرد.
با سلام به دوستان ITPRO در مقاله قبلی در مورد سورس کنترل گیت صحبت کردیم و عملیات معمول و مهم را برای این سیستم سورس کنترل گفتیم. در این مطلب می خواهیم در مورد TFS و اعمالی که بر روی آن انجام می شود صحبت کنیم. TFS برخلاف گیت یک سورس کنترل توزیع شده نیست و یک سورس کنترل متمرکز است. بنابراین این سورس کنترل Repository محلی ندارد پس اعمالی که معادل کامیت در گیت بود وجود ندارد و همه ی کار های آن با سرور است.
دقت داشته باشید که TFS فقط یک سورس کنترل نیست و می توان از آن برای تعریف وظایف هر یک از کاربران نیز استفاده کرد. همچنین می توان از TFS برای پیاده سازی متدولوژی Agile و روش اسکرام نیز استفاده کرد. TFS مخصوص زبان های برنامه نویسی مایکروسافتی است و با ویژوال استودیو به خوبی مجتمع می شود و ویژوال استودیو به راحتی با آن ارتباط برقرار می کند. برای برپایی سرور TFS هم می توانید نرم افزار سرور آن را بر روی سرور نصب کنید و یا از حالت آنلاین این سورس کنترل اضافه کنید که البته یک سری محدودیت ها در حالت رایگان دارد. حال در ادامه عملیاتی که می توان بر روی TFS انجام داد را توضیح می دهیم.
TFS مخفف Team Foundation Server می باشد که سرور اصلی برای سورس کنترل مایکروسافت می باشد که توسعه دهندگان از آن برای کنترل ورژن پروژه های مختلف از آن استفاده می شود. از tfs می توان برای عملیاتی مانند مدیریت کاربران و کنترل دسترسی هرکدام به پروژه ها نیز استفاده می شود. عملیاتی که برای کار با پروژه می توان انجام داد کارهای زیر می باشد.
این عمل را هنگامی باید انجام داد که شما برای بار اول می خواهید پروژه را بر روی سیستم خود کپی کنید. با مپ کردن یک محل برای ذخیره سازی فایل های پروژه مشخص می شود و آن مسیر به عنوان مسیر پروژه ذخیره می شود. دقت داشته باشید که هنگام مپ کردن فایلی کپی نمی شود و فقط محل ذخیره سازی فایل ها مشخص می شود.
با این عمل فایل هایی که بر روی سیستم شما موجود است بررسی می شود. و فایل هایی که وجود ندارد و یا این که ورژن فایل ها قدیمی است آن فایل ها را بر روی سیستم شما کپی می کند. شما بعد از عمل مپ کردن نیز باید عمل Get Latest Version را انجام دهید تا کل فایل های پروژه بر روی سیستم شما دانلود شود.
اگر شما تغییراتی بر روی پروژه انجام داده باشید و بخواهید که از اعمال آن تغییرات بر روی سرور انصراف دهید باید تغییرات را undo کنید. با این کار فایل هایی را که تغییر داده بودید از سرور درخواست می شود و همه تغییراتی را که انجام داده بودید نادیده گرفته می شود و فایل موجود در سرور لود خواهد شد.
این عمل شبیه عمل push در سیستم گیت است. یعنی تغییراتی را که انجام داده اید را بر روی سرور آپلود می کند. البته قبل از آن شما می توانید یک کامنت و توضیحاتی برای این ورژن از فایل ها قرار دهید و شرح بدهید که چه تغییراتی انجام شده است. البته نوشتن توضیحات در tfs اجباری نیست ولی در گیت شما باید توضیحات را وارد کنید. هر check in یک شماره دارد.
اگر شما بخواهید ببینید که فایل شما در مقایسه با یکی از فایل های سرور چه تغییراتی داشته است از دستور compare استفاده می کنید. در این حالت تغییرات و حذف و اضافه ها را با رنگ های مختلف یه شما نشان می دهد.
برخی اوقات شما نمی خواهید که آخرین ورژن موجود بر روی tfs را دریافت کنید بلکه می خواهید یک ورژن خاص را از سرور دریافت کنید وتغییرات آن را ببینید. برای این کار از Get Specific Version استفاده می شود. با این کار پنجره ای باز می شود که به شما اجازه می دهد ورژنی از پروژه را که می خواهید انتخاب کنید و از سرور دریافت نمایید.
حالتی را در نظر بگیرید که کار شما تمام نشده است ولی باید تغییرات خود را بر روی سرور آپلود کنید ولی جزء ورژن های پروژه محصوب نشود در این صورت شما می توانید از این عمل استفاده کنید. و بعدا آن را گرفته و ادامه دهید. یکی از خواصی که tfs دارد این است که وقتی که کلاینتی یک فایل را ویرایش می کند می توان طوری پیکر بندی کرد که سایر کلاینت ها نتوانند دیگر آن فایل را ویرایش کنند و فایل مورد نظر برای آنها قفل می شود. برای این کار در سطح سرور باید single checkout را فعال کنیم.
با توجه به این که در کشور ما زبان های برنامه نویسی بر پایه دات نت کاربرد بسیار دارد به توضیح tfs پرداختیم که کاربران خود را عادت بدهند که از سورس کنترل ها استفاده کنند. زیرا که این کار باعث می شود که سورس های آنها به طور منظمی ذخیره شود و دسترسی به قسمت های مختلف پروژه برای آنها راحت تر باشد
بنیانگذار توسینسو و برنامه نویس
مهدی عادلی، بنیان گذار TOSINSO. کارشناس ارشد نرم افزار کامپیوتر از دانشگاه صنعتی امیرکبیر و #C و جاوا و اندروید کار می کنم. در زمینه های موبایل و وب و ویندوز فعالیت دارم و به طراحی نرم افزار و اصول مهندسی نرم افزار علاقه مندم.
زمان پاسخ گویی روز های شنبه الی چهارشنبه ساعت 9 الی 18
فقط به موضوعات مربوط به محصولات آموزشی و فروش پاسخ داده می شود