Коли мені потрібно зробити “git pull”, до або після “git add, git commit”?


93

Який правильний шлях?

git add foo.js
git commit foo.js -m "commit"
git pull
git push

Або

git pull
git add foo.js
git commit foo.js -m "commit"
git push

Або

git add foo.js
git pull
git commit foo.js -m "commit"
git push

UPD:

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


Пов'язаний питання: stackoverflow.com/questions/813822 / ...
leo9r

Відповіді:


95

Я думаю, що найкращий спосіб зробити це:

Зберігайте свої місцеві зміни:

git stash

Оновіть гілку до останнього коду

git pull

Об’єднайте свої локальні зміни в останній код:

git stash apply

Додавайте, фіксуйте та просувайте свої зміни

git add
git commit
git push

З мого досвіду, це шлях до найменшого опору з Git (у командному рядку в будь-якому випадку).


4
Чи можете ви пояснити, чому це краще? Яких проблем це уникає? Зокрема, чому це краще, ніж простий коміт> тягнути> натиснути? (Я відчуваю, що це може бути найкращою відповіддю, але зараз у нього недостатньо інформації, щоб навіть вважатись гарною відповіддю.)
Даллін,

7
Можливо, це було занадто анекдотично, але мені завжди набагато легше був такий підхід (у командному рядку, а не в чомусь на зразок sourcetree). Роблячи коміт, а потім тягнучи, працюючи у великій команді, завжди призводить до великих конфліктів злиття, оскільки git не дуже добре поєднував мої зміни у файлі з вхідними. Зберігаючи, це дозволило мені внести нові зміни, а потім використовувати оновлений код як основу для додавання змін. Справлятися з конфліктами було простіше, оскільки вони були мені зрозумілішими (оскільки мої зміни тепер були конфліктами). Оглянувшись назад, можливо, це було просто простіше для моєї ситуації.
johnjo

1
Тож це звучить як щось на кшталт "Як ти їси слона? По одному укусу". тобто розбиття процесу на ще кілька кроків для спрощення злиття, щоб мати менше і, можливо, більш чітких змін. Має сенс.
Даллін

Чи потрібен тут git add? Якщо всі файли вже додані до індексації!
Sharp Edge

Що робити, якщо ви не використовуєте git stash?
Аарон Франке,

76

витягнути = отримати + злити.

Вам потрібно зробити те, що ви зробили перед об’єднанням.

Тож тягніть після коміту.


8
Чи означає це, що ви в кінцевому підсумку робите додатковий коміт для кожного зробленого коміту і робите репо недбалим? Крім того, ваше початкове повідомлення про фіксацію закінчується, за яким слідує коментар злиття кожного разу. Якщо так, я був би схильний використовувати метод сховання, згаданий нижче @johnjo.
Понеділок Папір

3
@DanielM Так, є додатковий коміт для злиття (з явним повідомленням про коміт за замовчуванням). Хоча це цілком гарна річ, оскільки вона дозволяє перевірити ваш останній коміт, останній коміт вашого колеги або коміт об’єднання. Якщо ви хочете цього уникнути і якщо ви хочете розміщувати свої комітети після комітетів вашого колеги, можете rebaseзамість цього merge. Ви можете зробити це за допомогою будь-якого git commit && git rebaseабо git pull --rebase.
Arnaud Denoyelle

Дякуємо за підказку, @Arnaud. Після прочитання багатьох різних питань SO, цей коментар зробив це. Мені найкращий варіант, коли колеги працюють над різними файлами, - це git pullпісля інсценування моїх змін, оскільки я вважаю це найбільш природним. Хоча я усвідомлюю, що працює багато різних робочих процесів (схованка теж приємна), тому це, мабуть, справа смаку.
nephewtom

51

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

Сказавши це, я піду з першим варіантом:

git add foo.js
git commit foo.js -m "commit"
git pull
git push

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

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


1
Не могли б ви побачити моє оновлення питання? Я забув пояснити, що git addсаме використовується у моєму прикладі.
Зелений

1
Не має значення, чи це був новий файл, чи файл, що відстежується / модифікується. Все-таки вчинити, а потім потягнути.
Jasarien

7

Я думаю, що git pull --rebaseце найчистіший спосіб встановити нещодавно зроблені місцеві коміти поверх віддалених комітів, яких у вас немає в певний момент.

Таким чином, вам не потрібно тягнути кожен раз, коли ви хочете почати вносити зміни.


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

3

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

"Брудні" локальні файли не є проблемою, якщо не виникає конфліктів із віддаленою гілкою. Однак, якщо виникають конфлікти, злиття не вдасться, тому немає жодних ризиків або небезпек при витягуванні до здійснення локальних змін.


1
Це не спрацює, як згадував Арно, для витягування потрібно спочатку внести свої зміни.
Jasarien

Мій git, схоже, радий взяти багато локальних змін. Звичайно, якщо ті самі файли змінюються на віддаленій гілці, частина об'єднання витягування не вдається. Щоб створити належний конфлікт злиття, я мав би зробити перший, звичайно. Отже, якщо набір локально та віддалено змінених файлів є неперервним, витягування та коммітування - це нормально. Інакше git не тягне. Жодної шкоди, яка не може бути завдана спробою.
AlexE

Це мій найкращий варіант, коли люди працюють над різними файлами, і я вважаю це найбільш природним.
nephewtom
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.