Всем добрый день!Сейчас осваиваю GIT и не могу разобраться с одним вопросом. Есть у меня 1 репозиторий. Я его клонирую. Работаю с клоном, делаю коммит и затем делаю push в оригинальный репозиторий.
Перехожу в оригинальный, делаю git status, и он мне выдает, что дескать есть изменения для коммита (как раз те изменения, что я сделал на клоне). Делаю коммит, и... ничего не меняется. Исходные тексты в рабочей директории оригинального репа не изменились.Подскажите, пожалуйста, как правильно принять изменения, которые прислали пушем?
> Перехожу в оригинальный, делаю git status, и он мне выдает, что дескать
> есть изменения для коммита (как раз те изменения, что я сделал
> на клоне).
> Делаю коммит, и... ничего не меняется. Исходные тексты в
> рабочей директории оригинального репа не изменились.В git log изменения есть? Тогда надо делать git chechout, видимо.
> Подскажите, пожалуйста, как правильно принять изменения, которые прислали пушем?
Понять разницу между "репо" и рабочей директорией (и индексом ещё), ну, или хотя бы научиться смотреть их состояния и разницу между ними.
Ну с теорию я учу сейчас, отличие репа от рабочей директории вроде усвоил.Git log смотреть уже бессмысленно, я копипастом перегнал файлы в рабочую директорию :D
Сейчас продолжаю экспериментировать. Так вот сейчас наблюдаю другую картину. Делаю пуш. Переключаюсь на оригинальный реп, и вижу рабочую директорию в соответствии с файлами, присланными пушем. Делаю reflog, а там пуш никак не обозначается, как буд-то и нет его. А вот git log показывает этот пуш как обычный коммит. При таком раскладе всё ок, и можно нормально работать. Но всё равно хотелось бы, чтобы после пуша изменения не сразу попадали в рабочую директорию. Это можно как-то сделать?
> Git log смотреть уже бессмысленно, я копипастом перегнал файлы в рабочую директорию
> :D
> Сейчас продолжаю экспериментировать. Так вот сейчас наблюдаю другую картину. Делаю пуш.
> Переключаюсь на оригинальный реп, и вижу рабочую директорию в соответствии с
> файлами, присланными пушем. Делаю reflog, а там пуш никак не обозначается,
> как буд-то и нет его. А вот git log показывает этот
> пуш как обычный коммит.Так, в отличие от pull (да, они не зеркальные близнецы), push не делает мерджа, он _копирует историю текущей ветки в удалённую ветку. То есть, если и там что-то (другое) коммитил, получится.... Даже не знаю, что получится - скорее всего те ремотные коммиты потеряются. В таком случае, если ремотная истоия важна, нужно сначала её pull (=и мердж), а потом резульат (после обычных проверок и проч.) pull туда.
> При таком раскладе всё ок, и можно нормально работать.
> Но всё равно хотелось бы, чтобы после пуша изменения
> не сразу попадали в рабочую директорию. Это можно как-то сделать?Завести отдельную ветку, например. Пушить в одну ветку, а в раб.дир-е иметь в чекауте другую. Я с таким зоопарком на мизерном тестовом проекте запутался :( -- то ли ниасили, то ли чего не так делал.
Поправка! Я писал:>> Переключаюсь на оригинальный реп, и вижу рабочую директорию в соответствии с
>> файлами, присланными пушем. Делаю reflog, а там пуш никак не обозначается,
>> как буд-то и нет его. А вот git log показывает этот
>> пуш как обычный коммит.Более подробный анализ показал, что происходит на самом деле следующее:
Когда я после пуша перехожу в оригинальный репозиторий, в нем уже есть коммит с изменениями пуша, но рабочая директория находится в состоянии до пуша! То есть, чтобы принять изменения, присланные пушем, мне нужно для каждого измененного файла сделать "git reset HEAD -- file", а затем "git checkout file". А для этого нужно знать список измененных файлов.
Но самое интересное, что если сделать тупо "git checkout 123456", где 123456 - шех этого самого коммита, то ничего не изменится! Хотя эта команда должна приводить рабочую директорию в состояние на момент указанного коммита. Итого: в истории коммит есть; через reset из него вытащить изменения можно, а просто переключиться на него нельзя. Точнее можно, и гит показывает, что всё успешно переключено, но директория не меняется. Ваше взрыв мозга!Вы пишите, что push копирует только историю. Вышеописанное поведение как раз укладывается в вашу мысль.
Насчет пуша в другую ветку не понял. Какая разница, в какую ветку пушить. Я попробовал сделать пуш в другую ветку. Поведение идентично.
> пуша! То есть, чтобы принять изменения, присланные пушем, мне нужно для
> каждого измененного файла сделать "git reset HEAD -- file", а затем
> "git checkout file". А для этого нужно знать список измененных файлов.А `git checkout -f` не помогает?
> Но самое интересное, что если сделать тупо "git checkout 123456", где 123456
> - шех этого самого коммита, то ничего не изменится! Хотя эта
> команда должна приводить рабочую директорию в состояние на момент указанного коммита.Не должна ( -f же!).
> Итого: в истории коммит есть; через reset из него вытащить изменения
> можно, а просто переключиться на него нельзя. Точнее можно, и гит
> показывает, что всё успешно переключено, но директория не меняется. Ваше взрыв
> мозга!А это он и есть -- Индекс. Пуш его не трогает и он "помнит", насколько я ничего не понимаю, какое-то из прошлых состояний.
Плюс -- изменённая раб.директория не переписывается без -f/--force.
>Насчет пуша в другую ветку не понял.
Это было по поводу "вижу рабочую директорию в соответствии с
>> файлами, присланными пушем", чего, как выснилось не %) было.
> А `git checkout -f` не помогает?
> Не должна ( -f же!).
> Плюс -- изменённая раб.директория не переписывается без -f/--force.Ну неужели в Гите такая работа через жопу и задумывалась? Это же бред.
Кстати, пуш в другую ветку проходит нормально. Если пушить в ветку, которая не в состоянии checkout, то всё отлично пушится и раб директория отображается с изменениями, пришедшими с пушем.
> Ну неужели в Гите такая работа через жопу и задумывалась? Это же бред.Может, тебе rsync нужен, не git?
...хотя с ним тоже сложно - столько ключей, и не делает "то, что я хочу, и сразу"(тм) ?Я в тупике!
>> Ну неужели в Гите такая работа через жопу и задумывалась? Это же бред.
> Может, тебе rsync нужен, не git?
> ...хотя с ним тоже сложно - столько ключей, и не делает "то,
> что я хочу, и сразу"(тм) ?
> Я в тупике!Блин, ну хотелось удобный инструмент, чтобы локально работать над проектами, а потом заливать на сервак, иметь красивую историю и возможность откатиться. Раньше я постоянно по фтп перекидывал измененный файлы и руками бекапил предвдущие версии. Если что-то не так, то руками обратно восстанавливал из бекапа. Мороки много.
Вот и начал гит осваивать, чтобы был процесс автоматизированный. И, кстати, я писал что в удаленную ветку пуш проходит нормально. НИФИГА! Посмотрел более внимательно, не проходит он.
я делаю так
1) создаю bare репозиторий на сервере
2) делаю из него clone для работы на одном или нескольких рабочих хостах (обычно 2)
3) работаю с кодом (commit, etc)
4) посылаю мои изменения на сервер с помощью push.
5) на другом компьютере беру изменения с сервера c помощью pull
6) goto 3если есть разница между локальной копией и сервером то git status сообщает об этом.
> я делаю так
> 1) создаю bare репозиторий на сервере
> 2) делаю из него clone для работы на одном или нескольких рабочих
> хостах (обычно 2)
> 3) работаю с кодом (commit, etc)
> 4) посылаю мои изменения на сервер с помощью push.
> 5) на другом компьютере беру изменения с сервера c помощью pull
> 6) goto 3
> если есть разница между локальной копией и сервером то git status сообщает
> об этом.Ну вот с bare репозиторием я не пробовал работать. Я работаю над сайтом, поэтому в рабочей директории по-любому должны быть исходники. Но можно попробовать создать третий реп и сделать его bare. В него пушить с локальной машины. А потом стягивать (pull) с него наработки на продакшн-сервер, где сайт лежит.
Кстати, и без bare репа я нашел-таки рабочий вариант. На продакшне активная ветка мастер (checkout master). На локальной машине работаю, делаю коммиты, а затем чтобы передать сделанное на продакшн, делаю "push origin new_branch", где new_branch - название ветки, которой не существует в origin. В результате, в основном репе создается копия мой рабочей ветки и ей дается название new_branch. Остается только слить её с мастером.