Навіщо мені натискати, якщо я працюю один в локальному сховищі?

Я взаємодію з Git через GitHub для Windows , що смішно, оскільки я ніколи не підштовхую своє сховище до GitHub. Я працюю над цим поодинці, і він призначений для використання лише мною. Я помітив, що мої комісії перелічені у розділі "несинхронізовані коміти", а в розділі "історія" написано "без комісій". Що підштовхує мене до питання, що я досягти, натиснувши, крім моїх зобов'язань, перелічених у розділі "Історія"?

Ви технічно правильні - не потрібно реагувати, якщо ви ні з ким не ділитесь кодом.

Потім знову ваш ноутбук має жорсткий диск, зроблений найнижчим учасником. Ваш будинок може згоріти до виходу з ладу жорсткого диска. Можливо, ви захочете переглянути свій код віддалено. Або навіть поділитися ним з кимось.

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

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

Є ще одна причина, яку ви хочете підштовхнути до репо (навіть якщо це, так чи інакше, локально): робочі станції .

Я не знаю про вас, але я працюю на 4-х різних комп’ютерах (1 ПК вдома, 1 ноутбук, 1 офісний ПК та 1 офісний ноутбук), і натискання змін на правильно налаштованому сервері Git на сервері моєї компанії робить синхронізацію швидкою і безболісний. Оскільки Git - це DVCS, саме для цього використовується ця перевага: це не тільки резервні копії, але й всі різні бази кодів, над якими я працюю, можна легко об'єднати, перевірити та проаналізувати.

Це може бути локальним, якщо, наприклад, ваш домашній ПК є "сервером" (або походженням) і у вас є домашній ноутбук - таким чином ви зможете легко підтримувати синхронізацію.

Сторона : Люди часто кажуть: "Я б скоріше скористався Dropbox (або будь-яким іншим сервісом синхронізації)". Завдяки величезній кількості об'єктів Git repo смішно використовувати Dropbox таким чином. Це варіант, але я б не сказав хорошого.

Як розподілений SCM, git розрізняє поняття "зробити знімок робочої копії" (фіксувати) та "сховища синхронізації" (push / pull / fetch).

Якщо у вас є лише один локальний клон вашого сховища, то його не має сенсу просувати. Тим НЕ менше, з GitHub, ви робите ще один клон (один на GitHub), і штовхаючи зміни там має принаймні одна перевага: резервне копіювання. Якщо ваш комп’ютер помирає, у вас все ще все штовхнулося на github.

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

Ще одна причина підштовхування - якщо ви використовуєте кілька локальних клонів. Це може бути корисно для різних речей: наприклад, ви можете одночасно працювати над двома різними гілками, або ви можете спробувати можливі руйнівні операції у вашому сховищі; якщо все працює за призначенням, ви зберігаєте модифікований клон (або відсуньте зміни назад до початкового репо), але якщо все піде на південь, ви можете просто видалити заплутаний клон і повернутися до початкового (який досі не змінився) .

Деякі люди навіть використовують git для розгортання: виробнича версія - це також git repo, а оновлення до нової версії - це питання вибору та замовлення (очевидно, це працює лише у тому випадку, якщо вам не потрібен крок збирання). Я не обов'язково рекомендував би його для серйозних речей, але для дрібних речей це просте і прагматичне рішення.