Я вже деякий час використовую git, але мені ніколи не довелося самостійно створювати нове віддалене репо, і мені було цікаво зробити це. Я читав підручники, і я збентежений, як змусити "git push" працювати.

Якщо я просто використовую, git pushвін запитує, щоб я побачив гілку за замовчуванням (?), На яку слід вказати? Яка різниця між цими двома варіантами, якими вона мене постачає?

git config --global push.default matching
git config --global push.default simple

Збігання просто підштовхує будь-які гілки, які я маю на своєму місцевому репо, і якщо вони не відповідають, я повинен вручну сказати, щоб натиснути будь-які нові місцеві гілки, правильно? Це найкраща практика для використання чи проста просто?

git push може натиснути всі гілки або одну окрему залежно від цієї конфігурації:

Натисніть на всі гілки

git config --global push.default matching

Це підштовхне всі гілки до віддалених гілок і з’єднає їх. Якщо ви не хочете натискати всі гілки, ви можете натиснути лише поточну гілку.

Натисніть лише на поточну гілку

git config --global push.default simple

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

З документації GIT: Git Docs

Нижче наводиться повна інформація. Коротше кажучи, simpleбуде натискати тільки current working branchі навіть тоді, якщо він також має те саме ім'я на пульті. Це дуже хороша настройка для новачків і стане типовим вGIT 2.0

Тоді як на пульті matchingбудуть натискати всі гілки локально, що мають однакову назву. (Без урахування вашої поточної галузі) Це означає, що потенційно буде розігнано багато різних галузей, включаючи ті, якими ви навіть не хочете ділитися.

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

push.default
Визначає дію, яку git push має здійснити, якщо чітко не вказано жодний refspec. Різні значення добре підходять для конкретних робочих процесів; наприклад, у суто центральному робочому процесі (тобто джерело вибору дорівнює пункту призначення), напевно, те, що ви хочете. Можливі значення:

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

Поточний - натисніть поточну гілку, щоб оновити гілку з тим самим іменем на кінці прийому. Працює як в центральному, так і в не центральному робочому процесі.

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

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

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

Цей режим стане типовим у Git 2.0.

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

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

Зараз це за замовчуванням, але Git 2.0 змінить типовий на простий.

Примітки до випуску Git v2.0

Примітки про сумісність із зворотним рівнем

Коли git push [$there]не сказано, що натиснути, ми до цього часу використовували традиційну семантику "узгодження" (всі ваші гілки були відправлені на віддалений стільки, поки там уже є гілки з однойменною назвою). У Git 2.0 за замовчуванням тепер "проста" семантика, яка підштовхує:

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

• лише поточна гілка до гілки з такою ж назвою, якщо ви натискаєте на пульт, який не є там, де ви зазвичай отримуєте.

Ви можете використовувати змінну конфігурації "push.default", щоб змінити це. Якщо ви старець, який хоче продовжувати використовувати семантику "узгодження", ви можете встановити змінну на "відповідність", наприклад. Прочитайте документацію щодо інших можливостей.

Коли git add -uі git add -Aзапускаються всередині підкаталогу, не вказуючи, які шляхи додати в командному рядку, вони оперують усім деревом для узгодження з git commit -aіншими командами (ці команди використовувались лише для поточного підкаталогу). Скажіть, git add -u .або git add -A .якщо ви хочете обмежити операцію поточним каталогом.

git add <path>те саме, що git add -A <path>зараз, так що git add dir/ви помітите шляхи, які ви видалили з каталогу, і записуйте видалення. У старих версіях Git, які git add <path>використовуються для ігнорування видалень. Ви можете сказати, що git add --ignore-removal <path>потрібно додавати лише додані або модифіковані контури <path>, якщо це дійсно потрібно.