Оновлення: зауважте, що прийнята в даний час відповідь продовжує поширене непорозуміння щодо поведінки git push, яке не було виправлено, незважаючи на коментар, який вказував на це.
Ваше резюме, що таке віддалені файли - як прізвисько для URL-адреси сховища - правильне.
То чому URL не git: //git@github.com/peter/first_app.git, але в іншому синтаксисі - що це за синтаксис? Чому він повинен закінчуватися .git? Я намагався не використовувати .git наприкінці, і він також працює. Якщо ні .git, що ще може бути? Схоже, git у початківця є обліковим записом користувача на сервері git?
Дві вказані вами URL-адреси вказують на те, що слід використовувати два різні транспортні протоколи. Початок з git://- для протоколу git, який зазвичай використовується лише для доступу лише до читання до сховищ. Інший, git@github.com:peter/first_app.git- це один із різних способів визначення доступу до сховища через SSH - це «синтаксис стилю scp», описаний у документації . Це ім'я користувача в синтаксисі стилю scp - gitце через те, що GitHub має справу з ідентифікацією користувачів - фактично це ім'я користувача ігнорується, а користувач ідентифікується на основі пари ключів SSH, яку вони використовували для автентифікації.
Що стосується багатослівності git push origin master, ви помітили, що після першого поштовху ви можете просто робити git push. Це через низку важких для запам'ятовування, але в цілому корисних за замовчуванням :)
- Якщо не вказано пульт, використовується віддалений, налаштований для поточної гілки (
remote.master.urlу вашому випадку). Якщо це не встановлено, тоді originвикористовується.
- Якщо не вказано "refspec" (наприклад
master, master:my-experimentтощо), тоді git за замовчуванням натискає кожну локальну гілку, яка має те саме ім'я, як гілка на пульті дистанційного керування. Якщо ви просто маєте masterзагальну гілку між вашим сховищем та віддаленою схожою, це буде те саме, що підштовхувати masterдо віддаленого master.
Особисто, оскільки я, як правило, маю багато тематичних галузей (а часто і кілька віддалених), я завжди використовую форму:
git push origin master
... щоб уникнути випадкового натискання інших гілок.
У відповідь на ваші коментарі до однієї з інших відповідей, мені це здається так, ніби ви дуже ефективно дізнаєтесь про git "зверху вниз" - ви виявили, що за замовчуванням працюють, і ваше питання задається питанням, чому;) бути більш серйозним, git canвикористовувати по суті так само просто, як SVN, але трохи знати про віддалені та гілки означає, що ви можете використовувати його набагато гнучкіше, і це дійсно може змінити спосіб роботи на краще. Ваше зауваження щодо семестрового курсу змушує мене думати про те, що Скотт Чакон сказав в інтерв'ю з подкастом - студентів навчають про всі види основних інструментів в галузі інформатики та програмної інженерії, але дуже рідко контролюють версії. Розподілені системи контролю версій, такі як git та Mercurial, тепер настільки важливі та настільки гнучкі, що варто було б викладати на них курси, щоб дати людям хорошу основу.
На мій погляд git, ця крива навчання абсолютно варта того - робота з безліччю тематичних галузей, їх легко злиття та натискання та перетягування між різними сховищами є фантастично корисними, коли ви впевнені в роботі системи. Просто прикро, що:
- Первинну документацію на git настільки важко проаналізувати для новачків. (Хоча я б заперечував, що якщо ви Google майже щодо будь-якого питання про git, то сьогодні з’являються корисні матеріали підручника (або відповіді щодо переповнення стека :)).)
- У гїті є кілька дивних способів поведінки, які зараз важко змінити, оскільки багато сценаріїв можуть покладатися на них, але люди заплутані.
git@github.com:peter/first_app.gitцеscp-style синтаксис для ssh URL-адрес у git. Ще один момент полягає в тому, що за замовчуванням конфігурація вище за течієюmasterне впливає на поведінку,git pushякщо ви неpush.defaultвстановилиtracking(абоupstreamв пізніших версіях) - я зробив публікацію в блозі про це джерело плутанини: longair.net/blog/2011 /