Від TFS до Git

Я розробник .NET і багато разів використовував TFS (сервер фундаментальної команди) як програмне забезпечення управління джерелами. Хорошими особливостями TFS є:

1. Гарна інтеграція з Visual Studio (тому я роблю майже все візуально; ніяких команд консолі немає)
2. Простий процес виїзду та реєстрації
3. Легке злиття та вирішення конфліктів
4. Легка автоматизована побудова
5. Відгалуження

Тепер я хочу використовувати Git в якості основи, сховища та контролю джерел своїх проектів з відкритим кодом. Мої проекти знаходяться на мові C #, JavaScript або PHP з базою даних MySQL або SQL Server як механізмом зберігання.

Я просто використав для цього допомогу github.com і створив там профіль і завантажив графічний інтерфейс для Git. До цієї частини було так просто.

Але я майже застряг у подальшому просуванні. Я просто хочу зробити кілька простих (дійсно простих) операцій, зокрема:

1. Створення проекту на Git та відображення його у папці на моєму ноутбуці
2. Перевірка / перевірка файлів і папок
3. Вирішення конфліктів

Це все, що мені зараз потрібно зробити. Але здається, що графічний інтерфейс не такий зручний для користувачів. Я очікую, що у графічного інтерфейсу з'явиться Connect To...щось подібне, і тоді я очікую, що буде показаний список проектів, і коли я вибираю його, я очікую, що я побачу список файлів і папок цього проекту, як і вивчення вашого проекту TFS у Visual Studio. Тоді я хочу мати змогу клацнути правою кнопкою миші файл і виберіть check-in...або check-outі подібні речі.

Чи багато чекаю? Що мені робити, щоб легко використовувати Git так само, як TFS? Що я тут пропускаю?

Переваги git полягають у викиданні багатьох старих припущень щодо того, що VCS має робити. Недоліки git виникли в тому, що не можна використовувати попередній досвід і не в змозі робити речі так, як ти звик.

Якщо ви збираєтесь перейти з чогось іншого на git, спробуйте запустити tabula-rasa (хоча це по-справжньому неможливо зробити). Оцініть його на основі того, що він робить, і наскільки добре це робить, а не на те, як це робить, порівняно з тим, як ви звикли це робити. Справа не в тому, що ви очікуєте занадто багато, це те, що ваші очікування є ортогональними щодо того, що забезпечує git. Якщо ви одружені на роботі з GUI, ви будете розчаровані. У Git є інструменти для gui, але вони не дуже додають. Це не є невдачею надати їх так багато, оскільки не так багато, що може додати gui. GitK допомагає не в повсякденних операціях, а у візуалізації структури філії та вивченні чи пошуку історії.

Ось чудова аналогія того, що я маю на увазі під «ортогональним». Одна з речей, яку ви можете зробити з газетою, - загорнути в неї рибу або використовувати її для вирівнювання пташиної клітки. Але це не є важливим для функції газети, це випадкові особливості форми, в яку вона надходить. Очікуючи, що git "перевірить файли", або "дозволить вам вибрати проекти", або забезпечить "підключення до ... "схоже на те, що ви очікуєте, що зможете загорнути рибу або вирівняти свою пташину клітку на веб-сайті газети .

Чи вважали ви меркурійськими? Як і git, це DCVS і дозволяє вам робити всі акуратні речі, які можна зробити з DCVS. Як і git, є досить хороший хмарний постачальник послуг (бітбукет). Але, на відміну від git, історія з Windows досить пристойна, ви не громадянин другого класу. У вас є гарні варіанти інструментів (TortiseHG) та досить пристойна інтеграція Visual Studio (VisualHG).

Однак у візуальній студії нічого не буде, як TFS - світ просто не є таким провідником.

Я перейшов з SVN на git рік тому, і це дуже радий. Однак я не покладаюся ні на який графічний інтерфейс, і якщо ви жорстко відмовитеся від командного рядка, це може бути проблемою.

Ви, здається, розраховуєте gitпрацювати так, як звикли, але це не так. Це не важко, але слід поглянути на його принципи, перш ніж продовжувати.

Створення проекту на Git та відображення його у папці на моєму ноутбуці

Git поширюється, що означає, що ви завжди працюєте з локальним сховищем, яке може бути відображено на будь-яку кількість віддалених, включаючи нуль. Граючи з проектом інших, я використовую два пульта: їх git або SVN сховище та власний сервер.

Я завжди починаю зі створення порожнього каталогу, а потім git initабо git clone SOME-REMOTE-REPOSITORY. Це посилання може допомогти вам.

Перевірка / перевірка файлів і папок

Ви пропустили написати GUI, який ви використовуєте. І те, TortoiseGitі git-guiточно, може це зробити.

Вирішення конфліктів

Для цього я використовую git-guiабо улюблений редактор тексту.

Я очікую, що у GUI з'явиться Connect to ... або щось подібне

Підключіться до чого, коли може бути від 0 до N віддалених? Git не залишається на зв'язку з віддаленим сервером, він створює з'єднання лише тимчасово і лише для кількох команд, що працюють з віддаленим сховищем. Більшість робіт виконується на місцях.

тоді я очікую показ списку проектів

Я припускаю, projectsви маєте на увазі repositories.

Боюся, що такого немає. Git на віддаленому сервері працює суворо лише з одним сховищем. Перерахування всіх сховищ еквівалентно переліку всіх каталогів, що містять підкаталог .git. Я впевнений, що тут щось подібне GitHub.

Я вибираю одну, я очікую, що я побачу список файлів і папок цього проекту, подібно до вивчення

Знову ж таки, я боюся, що такого немає, оскільки gitпрацює локально. І знову це не принесе користі. Просто клонуйте сховище та досліджуйте його на своєму комп’ютері. Хоча клонування величезних репостів займає певний час, всі наступні операції проходять набагато швидше, і ви можете подивитися на будь-яку комісію чи відділення.

Тоді я хочу мати змогу клацнути правою кнопкою миші файл і вибрати реєстрацію ... або виїзд і подібні речі.

Знову ж таки, gitпрацює локально. Тому немає сенсу заїзд або виїзд на віддалений репо. Працювати таким чином - це марна трата часу навіть на швидкій локальній мережі. Доставте сховище до свого комп’ютера, працюйте з ним і git pushзміни на віддалений. Подумайте про це, як опублікувати зміни, а також зробити резервну копію. Ви повинні здійснювати місцеві дії дуже часто .

Перед тим, як розпочати свою роботу, git fetchабо git pullзміни з дистанційного, якщо хтось інший, можливо, працював з нею.

Чи багато чекаю?

Так і ні. Ви очікуєте чогось іншого від того, що пропонує. Ви можете отримати щось набагато краще, gitє потужним, гнучким, безпечним, швидким, як пекло, і може робити все необхідне, але це не може імітувати саме те, що робить централізований VCS.

Я зробив мандрівки від візуального джерела безпечними до tfs до svn до git.

Перехід від vss до tfs був приємним досвідом. Перехід від tfs до svn був приємним досвідом. Перехід від svn до git був свого роду внутрішньою битвою.

Часто я вважаю себе досить консервативним і намагаюся зациклюватися на тому, що працює. Гарний gui для мене кращий за командний рядок, і я знайшов собі пошук деяких gui, які дозволили б мені грати з класними дітьми, з якими я працюю. Всі вони використовували git виключно з командного рядка.

Момент еврики прийшов мені одного разу, коли я відмовився від пошуку сріблястої кулі гуї і почав спробувати git bash (я все ще вчуся).

У мене встановлено кілька guis, і вони доповнюють git з командного рядка. Розширення Git, постачальник керування джерелами Git для візуальної студії та черепаховий git. Але я кажу, знайомтесь з git bash. Команди можуть бути трохи виразними, але як тільки ви їх вивчите, вони набагато швидші, ніж гуї.

Відгалуження за допомогою git - це просто ДУЖЕ, порівняно з іншими. Створюйте гілки та перемикаючи між гілками це майже миттєво. Ви можете робити речі, які ви б не заважали робити svn, оскільки svn в основному копіює вашу робочу копію (принаймні так, як я це робив).

Я вважаю, що у Git крутіша крива навчання, ніж svn. Але як тільки ви «отримаєте це» з git, ви не хочете повертатися назад.

Геть весь шлях.

Ви звикли мати сервер, який зберігає ваші файли і є всесильним власником їх. Для редагування файлу потрібно запитати дозволу у сервера.

Гіт не такий. Подумайте про git таким чином: у вас є місцеве сховище. Git дозволяє вносити зміни, зворотні коміти, просте та швидке розгалуження тощо. Коли ви хочете створити резервну копію історії керування джерелами, ви пересунете свої зміни до іншого сховища, яке "просто трапляється" на сервері, наприклад GitHub.com.

Робочий процес:

1. Клон (Завантажити) / Створити сховище
2. Внесіть деякі зміни. Продовжуйте розвиток, не піклуючись про інших.
3. Перейдіть до іншого сховища (може бути такий сервер, як GitHub).
4. Коли ви переходите до сховища, власник іншого сховища отримує сповіщення про очікування, що очікує на розгляд, і він повинен вирішити, приймати ці зобов’язання, відхиляти їх або лише приймати їх підмножину.
5. Цикл триває.

Це все.

Що ти маєш на увазі "" git gui? Їх є газильйон, включаючи плагін для інтеграції візуальної студії, якщо я правильно пам’ятаю. Якщо один графічний інтерфейс не працює для вас, спробуйте ще трохи, поки ви не знайдете той, який робить. Я особисто використовую різні графічні інтерфейси для різних завдань (і CLI для інших).

Однак git - це скоріше структура контролю версій, ніж фіксована система. Вам все одно доведеться вивчити деякі основи, щоб отримати максимальну користь від цього.

Чи багато чекаю?

Так

Що мені робити, щоб легко використовувати Git так само, як TFS?

Нічого. Git орієнтований на CLI і не має хорошого інтерфейсу (я знаю про TortoiseGit, що не відповідає, порівняно з іншими Черепаха *). Ви можете спробувати використовувати SmartGit (остерігайтеся Java)