Как правильно откатиться до коммита и залить это на удаленный репозиторий?

#git #git_commit #git_remote #git_push

                    
Есть два репозитория:


голый (bare) репозиторий, из него все берут копию, в нем есть  мастер ветка, которая
всегда соответствует production состоянию
есть локальный репозиторий


Разработчик откатывается к предыдущем коммиту в локальном репозитории git reset --soft,
потом делает коммит, потом пуш.

Пуш отклоняется, разработчик делает пул и мержит локальный мастер и с удаленным,
после чего отмененные строки кода опять встают на место и смысл затеи теряется!

Подскажите, пожалуйста, как правильно откатиться до коммита и залить это на удаленный
репозиторий?
    

Ответы

Ответ 1

Для простоты предположим, что проблемный коммит только один.

Чтобы откатить опубликованный (push) коммит, есть два основных пути:


git revert номер_проблемного_коммита. Создаёт второй, "противоположный" коммит, "со
знаком минус". После его публикации получится состояние, как до проблемного коммита,
но в истории останется пара ненужный-коммит + отмена-ненужного-коммита.
git push --force. Перед этим нужен git reset, как советуют в комментариях. Эту опцию
следует использовать с осторожностью. Рассмотрим следующие случаи:

Никто ещё не увидел опубликовынные изменения (в том числе "роботы", которые могут
что-то автоматически делать при push'е). Тогда --force наилучший вариант.
Несколько человек уже обновились после неудачного коммита. Тогда перед использованием
--force следует их уведомить, так как на их стороне --force может "взбаламутить" ситуацию
и потребовать дополнительных действий. Если тут же вместо проблемного коммита не положить
ещё какой-нибудь другой коммит, то проблемный коммит может снова попасть на сервер
(даже без --force'а) от этих разработчиков.
Кто-то уже опубликовал изменения поверх неудачного коммита. Тогда --force затрёт
их новые коммиты. От этого можно защититься опцией --force-with-lease. В этом случае
нужно обновиться и делать git rebase -i, а потом уже --force (причём во время этой
операции могут набежать ещё новые коммиты). Тут git revert будет более уместен.
Много человек уже обновилось, есть несколько опубликованных или неопубликованных
изменений "поверх" плохого коммита: git revert.


Ответ 2

как вариант

git reflog - выдаст список HEAD c номерами и описанием, достаточно выбрать интересуещее
вас состояние и сделать сброс до этого HEAD.

git reset --hard HEAD @{номер}


  HEAD – это указатель на текущую ветку, которая, в свою очередь,
  является указателем на последний коммит, сделанный в этой ветке. Это
  значит, что HEAD будет родителем следующего созданного коммита. Как
  правило, самое простое считать HEAD снимком вашего последнего коммита.


Ответ 3

В зависимости от платформы, Вы можете написать так:

GitHub 

откат на 1 коммит локально:

git reset --hard HEAD~1



  Примечание: это потенциально опасная команда, так как она
  сбрасывает все ваши незафиксированные изменения.


Потом удаляете в репозитории удаленно командой:

git push origin -f




По аналогии на BitBucket

откат на 1 коммит локально:

git reset --hard HEAD~1


и удаленно командой удаляете:

git push -f origin HEAD^:master



  Примечание: вместо ветки master Вы можете использовать любую другую
  ветку. Этой командой Вы только удаляете с Bitbucket.


HEAD~1 и HEAD^ могут быть взаимозаменяемыми.

Что делать с файлом имяпроекта.v12.suo GIT

#c_sharp #visual_studio #git #visual_studio_2013 #git_commit

У меня есть проект, я его закомитил и создал новую ветку потом поработал в ней и
закомитил ещё раз чтоб вернуться в основную ветку. Потом вернулся в основную ветку,
в VS попросило нажать reload я жму, и потом пишу git status. Мне показывает что мой
файл имяпроекта.v12.suo modified. Тоже самое происходит когда я возвращаюсь обратно
в новую ветку, опять имяпроекта.v12.suo modified, тоесть чтоб переключаться между ветками
мне приходится дополнять коммит git commit --amend. Что с этим делать?
    

Ответы

Ответ 1

Добавьте *.suo в .gitignore.

Файлы .suo содержат состояние открытых панелей Visual Studio и тому подобные вещи,
интересные только на локальной машине. В репозитории им не место.



Вот большой список того, что должно быть в .gitignore для проектов под Visual Studio:
https://www.gitignore.io/api/visualstudio

Порядок выполнения git commit и git pull

#git #git_commit #git_pull

Недавно начал работать с гитом.
Какая разница сделать pull до commit или после commit, и есть ли она вообще?
    

Ответы

Ответ 1

В целом разницы нет. Если конфликта в ваших изменениях и изменениях из upstream не
будет, то все пройдет без вопросов. Если же возникнет конфликт слияния, git так или
иначе сообшит об этом, и вам в любом случае придется его решать.

Но я бы предпочел сначала сделать коммит, чтобы зафиксировать изменения. Тогда легко
можно будет откатиться к исходной версии ваших изменений, если что-то пойдет не так.

Если коммит по каким-то причинам делать не хочется (например, работа не завершена),
можно временно спрятать изменения командой git stash, потом сделать git pull, а потом
вернуть изменения командой git stash apply. Этому посвящен отдельный раздел в документации.

Порядок выполнения git commit и git pull

#git #git_commit #git_pull

Недавно начал работать с гитом.
Какая разница сделать pull до commit или после commit, и есть ли она вообще?
    

Ответы

Ответ 1

В целом разницы нет. Если конфликта в ваших изменениях и изменениях из upstream не
будет, то все пройдет без вопросов. Если же возникнет конфликт слияния, git так или
иначе сообшит об этом, и вам в любом случае придется его решать.

Но я бы предпочел сначала сделать коммит, чтобы зафиксировать изменения. Тогда легко
можно будет откатиться к исходной версии ваших изменений, если что-то пойдет не так.

Если коммит по каким-то причинам делать не хочется (например, работа не завершена),
можно временно спрятать изменения командой git stash, потом сделать git pull, а потом
вернуть изменения командой git stash apply. Этому посвящен отдельный раздел в документации.

Потерял текущую ветку с кодом - как восстановить?

#android_studio #git #git_commit #git_push

У меня случился полный пиндец... Целую неделю писал код в Android Studio в базовой
ветке master. Изменения коммитил, но не пушил на сервер.

В итоге, когда собрался запушить на сервер, решил сначала сохранить то что было на
сервере в ветке master в отдельную ветку. Используя инструменты AS, в нижнем правом
углу, выбрал ветку master на сервере, нажал checkOutAs, ввел новое имя "develop/test1"
и нажал enter. После чего проект просто обнулился до состояния сервера, в папке проекта
так же все файлы удалились, и пропала панель Version Control.

Вот последние сообщения в логах:


  12:29 5 files committed: Отказался от использования элементов экшен бара
  
  13:29 1 file committed: Схема базы данных
  
  13:30 Checked out new branch develop/test1 from origin/master (show balloon)


Помогите понять что произошло. И самое главное - как восстановить потерянный код?!
Где-то же дожна была сохраниться история коммитов???
    

Ответы

Ответ 1

У вас все коммиты должны остаться в локальном репозитории. Попробуйте выполнить
git reflog, чтобы отобразить список всех сделанных вами коммитов.
Если найдете там нужный (последний ваш коммит), то сделайте git checkout 1c7474c,
где "1c7474c" - это id нужного коммита.


Ответ 2

Еще один более простой и правильный способ решения проблемы.

По каким то непонятным причинам в Android Studio иногда слетает Git, что приводит
к вышеописанным проблемам. И на самом деле, ничего переключать и восстанавливать не
нужно. Достаточно зайти в меню VSC и нажать Enable version control integration, после
чего в появившемся окошке выбрать нужный вариант (в моем случае Git).

Как не потерять локальные изменения, если надо сделать git pull?

#git #git_commit #git_push #git_pull

При попытке запушить код в репозиторий, git ругнулся и сказал, что есть свежие изменения,
а значит надо сделать pull. При подтягиваний изменений с сервера не слетит ли мой локальный
коммит и смогу ли я его потом запушить в удаленный репозиторий ?
    

Ответы

Ответ 1

Перед pull можно сделать коммит, или прописать команду git stash, чтобы все изменения
сохранились временно в нём, при этом Ваш проект "откатывается" до версии сервера. При
неправильном pull можно вызвать ненужный merge, если сделать коммит, при pull все коммиты
с сервера просто соединяются с Вашим.


Ответ 2

Разобрался , ничего плохого не произойдет. В самом худшем случае, если свежие изменение
затронули ваши файлы, то придется все смержить и запушить уже свои изменения.

Как правильно сплющить (объединить) удалённые коммиты?

#git #bitbucket #git_commit #git_push

Дано:

Последовательные коммиты А и В,  запушенные в удалённый репозиторий.

Задача:

Сделать из них один коммит С.

Вопрос:

Беглое гугленье убеждает меня в том, что достаточно что-то типа такого сделать:

git squash А
git squash В
git push origin branchname


Верно ли я понял и что в процессе может пойти не так?
    

Ответы

Ответ 1

Шаг 0: а можно ли это делать?


  что в процессе может пойти не так


Если коммиты последовательные, то конфликтов изменений не будет. Но поскольку коммиты
уже отправлены на удалённый репозиторий, то вам придётся переписывать историю там и
что-нибудь может пойти не так у коллег. Вот пара вопросов о том, что и когда можно
ребейзить и переписывать:


В каких случаях rebase можно и нужно делать, а в каких нет?
Откатить уже опубликованный коммит и опубликовать новый, не вызывая мержа у других


Кратко: никогда нельзя это делать в стабильных ветках репозитория, где кроме вас
есть ещё хоть один разработчик.

Шаг 1а: сплющивание через rebase -i

Под git squash вы наверное понимаете git rebase --interactive с последующим выбором
опции squash. Действительно, можно сделать так:

Ребейз к третьему коммиту с конца (пред-предпоследнему)

git rebase -i HEAD^^


откроется такой документ:

pick 7423f96 сообщение предпоследнего коммита
pick 91e9b6e сообщение последнего коммита

# Rebase c9e8f38..91e9b6e onto c9e8f38 (2 commands)
...


Чтобы объединить два коммита в один нужно сделать squash последнего в предпоследний:

pick 7423f96 сообщение предпоследнего коммита
squash 91e9b6e сообщение последнего коммита


А потом сохранить документ и выйти из редактора. Откроется новый документ, в котором
можно написать сообщение для вновь полученного коммита. По умолчанию там будет:

# This is a combination of 2 commits.
# This is the 1st commit message:

сообщение предпоследнего коммита

# This is the commit message #2:

сообщение последнего коммита


Закомментированные строки не войдут в сообщение. Если оставить пустую строку, то
rebase будет прерван.

Шаг 1б: сплющивание через reset

Поскольку нужно объединить N последних коммитов, отлично подойдёт более простой способ:

# сначала очистим индекс (staging area, область подготовки коммита),
# чтобы потом не закоммитить ничего лишнего
git reset .
# поехали
git reset --soft HEAD^^


Произошло следующее:


текущая ветка переставлена на коммит HEAD^^, т.е. на два коммита назад.
изменения всех коммитов вплоть до, но не включая HEAD^^ собраны в индекс


Можно сделать новый коммит:

git commit -m'message'


В отличие от способа с rebase, информация об авторе и дате оригинального коммита
не сохраняется. Лучше не ребейзить таким образом чужие коммиты, т.к. информация об
авторстве обычно важна.

Шаг 1в: комбинированный подход

Предположим, что в предпоследнем коммите у вас написано нормальное сообщение, раскрывающее
суть изменений. А в последнем вы исправили опечатку. Т.е. было бы удобно объединить
два коммита, оставив сообщение от предпоследнего.

# То же, что и в шаге 1б: собираем содержимое последнего коммита в индекс
git reset .
git reset --soft HEAD^

# "редактируем" последний коммит, добавляя в него содержимое индекса
# (на самом деле создаём новый коммит с тем же сообщением и переставляем на него ветку)
git commit --amend --no-edit


Шаг 2. запушить на удалённый репозиторий

Поскольку вы переписали свою ветку, нужно будет запушить с -f. 

git push -f origin mybranch


Ответ 2

Я бы сделал так:

git reset --soft HEAD~2
git commit 
git push -f origin


Всё это, разумеется, если у Вас коммиты на конце текущей ветви. В противном случае
придётся делать rebase.


Ответ 3

Нет такой команды как git squash, делайте через git rebase -i.

$ git squash
git: 'squash' is not a git command. See 'git --help'.

Did you mean this?
        stash
$ git --version
git version 1.8.3.1


Вот тут ещё советуют создать алиас на squash.

Проблем со сплющиванием двух последовательных коммитов не будет. :сли вам нужно влить
B в A, то проблем не возникнет. (Так же как и при вливании N последовательных коммитов
в предыдущий).

Сложности могут возникнуть в том случае, если между A и B есть другие коммиты.

В общем случае если нужно влить B в A - делайте так.

(переключаемся на нужную ветку)

$ git rebase -i HEAD~4
pick 8394e5a commit
pick 33b90d9 A
pick 5c633cf B
pick 1604c23 yet another commit

# Rebase 76e6ae0..1604c23 onto 76e6ae0
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
~
"~/ansible/test/.git/rebase-merge/git-rebase-todo" 22L, 780C


Приводите к виду:

pick 8394e5a commit
pick 33b90d9 A
s 5c633cf B
pick 1604c23 yet another commit


Далее выходите с сохранением и пушим изменения в удалённую ветку.

Как обычно: не забываем, что изменение истории через rebase требует git push -f,
что в общем случае не приветствуется в командной работе.

Как переименовать любой коммит в git?

#git #git_commit #git_rebase

Хочу переименовать десяток коммитов, но что-то не могу разобраться, как это сделать.
Вот, к примеру, статья тут, но у меня загвоздка после git rebase --interactive, то
есть редактор открывается такой же, но а дальше куда и что писать? Если пытаюсь написать
что-то, то у меня почему-то пишет в самом низу и по одному символу. Делал я это на
windows через терминал в SourceTree. Может, есть какой-то другой способ?     

Ответы

Ответ 1

git rebase --interactive вам покажет в текстовом редакторе своего рода план: список
коммитов и действий, которые к ним будут применены. По умолчанию всем коммитам сопоставлено
действие pick - сохранить как есть. Ваша первая задача отредактировать действия на
свой вкус. Доступные действия описаны в комментарии, отбитом символом #.
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell

Вас в первую очередь интересует команда r reword - изменить текст сообщения. Не знаю,
как SourceTree, а обычный шелл из пакета msysgit (мы ведь о Windows говорим?) предлагает
в качестве редактора православный vim. Если у вас так же, и вы с ним не знакомы - смело
давите кнопку i на клавиатуре и vim перейдет в режим редактирования. У нужных коммитов
замените pick на reword. Теперь надо вернуться в командный режим, нажав Esc. Сохраняемся
и выходим - набирайте на клавиатуре :wq, жмите Enter.
Редактор закроется, и git приступит к выполнению вашего плана. Для каждого коммита,
помеченного действием reword, он откроет вам редактор и предложит отредактировать сообщение.
Опять-таки, если у вас vim - жмем i, редактируем, Esc, сохраняем :wq.
На комментарий под текстом коммита, отбитый решеткой, не обращайте внимания. Он просто
подсказывает вам, что делать, и в текст сообщения не попадет.

Сформировать коммит с сообщением на основе указанного коммита

#git #git_commit

Задача следующая: нужно скопировать сообщение старого коммита и исправить последнюю
строку в нём для нового коммита. 

Сейчас приходится находить нужный коммит, копировать его сообщение, делать новый
коммит с таким же сообщением, подправляя последнюю строку. Хочется упростить этот процесс.

Узнал недавно про такую возможность, как git commit -C HEAD, которая сделает коммит
с таким же сообщением, как в указанной ссылке, но приходится еще делать git commit
--amend, чтобы подправить последнюю строку. 

Можно ли обойтись одной командой для этого?
    

Ответы

Ответ 1

изспользуйте опцию -c, а не -C:

git commit -c <коммит>


в этом случае сразу можно внести правки в коммит-сообщение.

ещё логично добавить опцию --reset-author, для того, чтобы авторство и время создаваемого
коммита не дублировались из указанного существующего коммита.


Ответ 2

git commit -C HEAD -e



  -e The message taken from file with -F, command line with -m, and from commit object
with -C are usually used as the commit log message unmodified. This option lets you
further edit the message taken from these sources.


Или как правильно подсказал alexander barankin:

git commit -c HEAD

Почему коммит прерывается с ошибкой “Aborting commit due to empty commit message”?

#git #git_commit

пытаюсь сделать commit в git, пишу команду

git commit


Выводит описание комита через gedit (я думаю это не сильно важно каким текстовым
редактором пользоваться?), я сохраняю изменения и закрываю его. И выводится 

Aborting commit due to empty commit
message.


Всё прекрасно работает с помощью 

git commit -m 'commit'


Но хотелось бы до конца разобраться. Кто-то может подсказать, почему так происходит?
    

Ответы

Ответ 1

Читайте внимательно сообщения об ошибках. Та, что у вас, говорит о том, что не задано
описание для коммита. В вылезшем окошке gEdit необходимо указать описание для коммита
в первой строчке файла, записать файл и выйти.


Ответ 2

Как вариант: "git commit" fails if gedit is already opened
Баг найден в феврале, до сих пор не пофиксан.


Ответ 3

Очень может быть, что при указании текстового редактора для git, вы не поставили
флаг -w (wait).

Попробуйте так:

git config --global core.editor "'путь_до_редактора/gedit.exe' -w"

Как сохранить и выйти после изменения сообщения коммита? [дубликат]

#git #git_commit

        
             
                
                    
                        
                            This question already has answers here:
                            
                        
                    
                
                        
                            Как выйти из редактора Vi или Vim?
                                
                                    (3 ответа)
                                
                        
                                Закрыт 2 года назад.
            
                    
Как же мне не везет с git ( восьмой урок достал вот здесь: сделал git commit, далее
пишется "В первой строке введите комментарий: «Added h1 tag». 

Сохраните файл и выйдите из редактора. Вы увидите…", написал «Added h1 tag»(нажав
кнопку INSERT) а как сохранить и выйти? 
    

Ответы

Ответ 1

Поступайте проще
git commit -m "Added h1 tag"


Ответ 2

Esc : w q

По необходимости добавить Enter


Ответ 3

нажимаете последовательно:

Esc + Z + Z


при создании коммита можно не попадать в Vim написав комментарий в кавычках:

git commit -m "Added h1 tag"

Удалить последний коммит [дубликат]

#git #git_commit

        
             
                
                    
                        
                            This question already has an answer here:
                            
                        
                    
                
                        
                            Как вернуться (откатиться) к более раннему коммиту?
                                
                                    (1 ответ)
                                
                        
                                Закрыт 2 года назад.
            
                    
Можно ли удалить свой последний коммит? Если да, какую команду надо ввести?    

Ответы

Ответ 1

Для отката последнего локального коммита используйте git reset. Для отката коммита,
который вы запушили на сервер, используйте git revert.

Отмена коммита в гите

#git #git_commit

Подскажите, как убрать изменения коммита "fix server name".
Он уже запушен на сервер. Пробовал удалять через тег - не получается


    

Ответы

Ответ 1

Если сервер не допускает изменеие истории (push с параметром --force), то можно воспользоваться
командой git revert, которая создаст коммит "обратный" к ненужному:

git revert COMMIT_HASH


Ответ 2

Можно откатиться к предыдущему состоянию до последнего изменения. 
Узнайте его индекс через команду: 

git log

git reset --hard идентификатор коммита


Также можете удалить просто последний коммит командой:

git reset --hard HEAD^


UPD:

Следующая команда отменит последний коммит, но файлы останутся нетронутыми.

git reset --soft HEAD^

git: как “нейтрализовать” коммит?

#git #git_commit

Есть бажный коммит, после него еще несколько коммитов, которые пока нельзя деплоить.
Необходимо как-то выкинуть изменения этого коммита из проекта, затем развернуться из
следующего перед ним коммита, а потом продолжить работу с последнего коммита, но исключая
изменения бажного. Дайте, пожалуйста, последовательность действий.
    

Ответы

Ответ 1

затем развернуться из следующего перед ним коммита


Подробная информация в вопросе Как вернуться (откатиться) к более раннему коммиту?.
Кратко - когда всё почините, сможете просто перейти в нужный коммит или даже новую
ветку создать в нём.


  выкинуть изменения этого коммита из проекта,


Про это будет весь ответ дальше.

Самый важный вопрос:

Успели ли вы запушить эту ветку на удалённый репозиторий? Возможно ли, что другой
разработчик уже получил с удаленного репозитория коммит B или один из последующих и
продолжает работать над ним. Если ответ - да, то в общем случае желательно revert,
но не rebase, cherry-pick и прочее, что переписывает историю Git, так как это создает
большие проблемы с интеграцией. 

Поскольку вам нужно развернуться из C, не содержащего изменений из B, то почти наверняка
историю переписывать придётся. В таком случае предупредите коллег заранее. Им придётся
аналогичным образом ребейзить свои изменения, например с коммита D на D'.

Обозначим начальную ситуацию на следующей схеме:

A - B - C - D 
            ↑
          branchname
          (HEAD)


A, B, C, D — коммиты в ветке branchname.  B - "плохой коммит", его нам нужно удалить.
Коммит C нужно задеплоить.
(HEAD) — местоположение указателя HEAD.
↑ обозначает коммит, на который указывает определенная ветка или указатель.

Вариант 1 - через rebase -i


Плюс - меньше мусора в истории. И можно гордиться, что освоил rebase.
Плюс - позволяет развернуться из С, не содержащего изменений из B.
Минус - переписывает историю, опасно при командной работе.


Команды:

git checkout branchname
git rebase -i A
git checkout -b deployme C'


В качестве A мы указываем коммит сразу перед тем, который будем исключать. При этом
A останется на месте. Откроется редактор, в нём будут коммиты в обратном порядке. Меняем
pick на drop, обозначая что мы хотим выкинуть этот коммит.

drop 323d4e6 comment for B
pick 31da2b9 comment for C
pick 24d420c comment for D

# Rebase c8893f9..24d420c onto c8893f9 (3 command(s))
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit


Результат

A - C' - D' 
         ↑
       branchname
       (HEAD)
    ↑
  deployme
  (HEAD)


У новых коммитов теперь другой предок, поэтому это - другие, новые коммиты (хотя
содержимое то же за вычетом B). Новая ветка deployme смотрит на коммит C'.

Вариант 2 - через revert


Плюс - не переписывает историю и безопасен при командной работе. Проще чем rebase.
Минус - ошибочный коммит останется в истории. Плохо, если там информация, которую
нельзя показывать или код, который стыдно публиковать. :)
Минус - коммит C по-прежнему будет содержать изменения от B.


Команды:

git checkout branchname
git revert B


Результат:

A - B - C - D - xB
                ↑
              branchname
              (HEAD)


Новый коммит xB содержит изменения, которые отменяют изменения коммита B. Однако
у нас есть проблема: коммит C по-прежнему содержит изменения от B.

Немного подробнее о revert:


Документация
тут, пятый пункт.


В дополнение:


Если в процессе ошибётесь или протеряете не тот коммит: Как отменить откат изменений
(восстановить потерянный коммит)?
Заодно, при желании, можно что-нибудь сделать и с другими коммитами: Как разделить/склеить
старый комит?.


Ответ 2

Создать ветку из нужного вам коммита и продолжить работу в этой ветке.

git checkout -b <имя ветки> <номер коммита>


Затем замержить в эту ветку нужные вам коммиты.

git cherry-pick <номер коммита>


Ответ 3

Коммит, удаляющий изменения, сохраненные нежелательным коммитом

git revert HEAD


Удаление коммита из ветки

git reset --hard 


Ответ 4

git revert - создаёт откатывающий коммит, см. https://git-scm.com/docs/git-revert

git cherry-pick - позволяет в другом бранче создать Новый коммит с изменениями указанного
коммита https://git-scm.com/docs/git-cherry-pick

Теоретически этого сочетания должно быть достаточно

Непонятное слияние в git затёрло работу

#git #git_commit #git_branch

Сегодня на работе произошла странная ситуация, и хоть она разрешилась, её причины
остались непонятными. С репозиторием работают два разработчика. Соответственно, в репозитории
три постоянные ветки: Alice, Bob и master.

$ git branch --all
Bob
Alice
* Alice_n
master
remotes/origin/HEAD -> origin/master
remotes/origin/Bob
remotes/origin/Carol
remotes/origin/Alice
remotes/origin/Alice_n
remotes/origin/master
remotes/origin/master_instance


Вчера перед уходом с работы я внесла коммит в Alice и подлила изменения из мастера.

git status
git add --all
git commit -m 'Изменения'


В результате получился коммит 0cf7f9e Add export all editable records for Admin role.

После: 

git push origin HEAD
git checkout master
git pull 


На этом этапе возник конфликт в трёх файлах по 2-3 строчки. В одном файле работала
только я, поэтому конфликт я разрешила. В двух других мы работали оба, а напарник был
уже недоступен, поэтому я оставила свои изменения, а конфликтные закомментировала.
Потом чтобы вернуться на свою ветку, я закоммитила в мастера изменения, оставив их
на локальной ветке.

git add --all
git commit -m "Fix conflicts"
git checkout first
git merge master


Мерж-коммит, полученный в результате конфликта при git pull: 9d2fda5 Fix conflicts.

$ git cat-file commit 9d2fda5
tree f10d0642a0bee9c08572afacc732e19aeef6f029
parent 62043f332ff8e6ca9e6d12058bddc490cb1694de
parent 0cf7f9e6e55ef80bf2fbfba69d8d2bee57955a75
author Alice <> 1480521034 +0300
committer Alice <> 1480521034 +0300 


Потом по итогам работы пришлось сделать ещё один коммит в свою ветку, но с мастером
я уже не мёрджилась, потому что там не было изменений.

Сегодня напарник написал, что добавил мои изменения в свою ветку Bob и у него пропала
его вчерашняя работа. Ему пришлось откатить изменения и сделать новую ветку, в которую
вручную внести изменения с наших веток, это заняло много времени и он нервничал. Ошибочное
слияние, видимо, не сохранилось в коммитах, потому что он сразу откатил слияние обратно.
1314ced merge files from first – это он вручную добавлял мои файлы в свою рабочую ветку,
когда выяснил, что обычное слияние затирает его работу

На моей ветке его вчерашняя работа сохранилась. Он говорит, что виноват мой коммит,
но не знает, почему у меня на ветке работает правильно. Чтобы не повторять косяк в
дальнейшем, мне нужно разобраться, как мой коммит мог затереть работу у него, но сохранить
у меня. Я читала документацию весь вечер, но так и не нашла, что сделала неправильно.
Буду благодарна за разъяснения.

Update

$ git log --oneline --decorate --graph --all
* 4b2be62 (origin/first_n, first_n) Fix different date types (array and
* 02d3a6f small fix
*   850cd31 Fix date at import_xls and print card
|\
* | 6510271 Fix date in cards and in import_xls
| | * e5243af (HEAD, origin/second, second) Правки в связаных формах
| | * 5da1775 правки в связаных полях
| |/
| * 3433552 set print
| * 1314ced merge files from first
|/
* 7df8366 (origin/master, origin/HEAD, master) Правки в селекте, добавление
*   c7e2dd1 merge second
|\
| * a0a7832 правки в поиске связаных полей
* | 346d429 (origin/third) change font
* | 93fff9e fix styles
* |   6a11fc2 merge master, fix conflicts
|\ \
| |/
* | 390fc18 change work of map control, fix styles
* | 76bdbfb add gis-logo lib
* | 174a55d add logo
| | * 2cf67b5 (origin/first, first) changed
| | * 2cf07b3 Fix import shp bug creating new records with old info
| | *   9d2fda5 Fix conflicts
| | |\
| |/ /
| | * 0cf7f9e Add export all editable records for Admin role
| | * d8f7231 Fix integer to string strip decimal points
| | * 59e50c8 Add icon to Geometry spatial layers style
| | *   97d357a Fix conflicts
| | |\
| | * | ff3118c Fix geomcollection default geometry to point
| | * | 9648c8f Add GeometryCollection spatial database append, export, print
| | * |   f5f4469 Merge branch 'master' into first
| | |\ \
| | * | | a776df4 Merge master
| * | | | 62043f3 Работа со свзаными полями
| * | | | fb4b7b7 Правки - дома без точки
| * | | | 4d5fef4 Удаление пустых групп из списка слоев
| * | | | 7410f87 come back
| * | | | acca807 asd
| * | | | bec436a ghost
| * | | | 9d26601 clear debugger and merge third
| * | | |   502a766 clear conflict
| |\ \ \ \
|/ / / / /
| * | | | e86d785 Настройка слоев, правки в валидации модели, создание отдельног
* | | | | bdbe5d3 merge master
* | | | |   b5b8bc5 Merge branch 'master' into third
|\ \ \ \ \
| |/ / / /
| * | | | 67a042c Правки в окне авторизации
| * | | | 6ddfc73 Удаление кнопки фильтра из кластерных слоев
| * | | | 40ca02e Правки в загрузке кластерных слоев.
| | |_|/
| |/| |
| * | | 2ebfeb1 changed model on edit table
| * | | 47ee6c5 Запрет на редактирование геометрии таблицы.
| * | | e9f1e5d правки в создании правил отображения слоев
| * | | 40152bb Удаление сессий, изменние страницы авторизации
| * | | 7f82cad Правки в ддп
| * | | c63f80b clear debugger and import pdb;
| * | | 0bca931 Правки в проекте, удаление что здесь, правки экспорта сводной ст
| | |/
| |/|
* | | 193cfcc icon markercluster
* | | b82aa6e fix backbone-tree, models, form for point, polygon
* | | 50ea454 add displaystyle form for line, polygon, multipolygon
* | | 85188fb add changing of pictogram size in vectorlayers
* | | c6da90a rerurn pictogram 126482.svg
* | | 9804246 Правка отображения фото для слоев со статистикой, отдельная форма


Update 2

    $ git log --format="%h %ai %an %d %s" --all --graph
* 02d3a6f 2016-12-05 10:28:30 +0300 Alice  small fix
*   850cd31 2016-12-05 10:26:34 +0300 Alice  Fix date at import_xls and print
|\
* | 6510271 2016-12-02 18:15:48 +0300 Alice  Fix date in cards and in import_
| | * e5243af 2016-12-02 17:23:02 +0300 Bob  (origin/Bob, Bob) Правки в св
| | * 5da1775 2016-12-02 15:49:38 +0300 Bob  правки в связаных полях
| |/
| * 3433552 2016-12-02 11:36:14 +0300 Bob  set print
| * 1314ced 2016-12-02 11:23:09 +0300 Bob  merge files from Alice
|/
* 7df8366 2016-12-02 09:54:26 +0300 Bob  (origin/master, origin/HEAD, master,
*   c7e2dd1 2016-12-01 15:00:38 +0300 Bob  merge Bob
|\
| * a0a7832 2016-12-01 14:58:34 +0300 Bob  правки в поиске связаных полей
* | 346d429 2016-12-01 10:32:21 +0300 Carol  (origin/Carol
* | 93fff9e 2016-12-01 10:09:45 +0300 Carol  fix styles
* |   6a11fc2 2016-12-01 09:43:36 +0300 Carol  merge master
|\ \
| |/
* | 390fc18 2016-11-30 18:21:07 +0300 Carol  change work of
* | 76bdbfb 2016-11-30 12:41:24 +0300 Carol  add gis-logo l
* | 174a55d 2016-11-29 18:42:50 +0300 Carol  add logo
| | * 2cf67b5 2016-12-02 10:43:56 +0300 Alice  (origin/Alice, Alice) chan

    

Ответы

Ответ 1

1. Что произошло

1.1 Конфликт при git pull

Команда git pull внутри себя выполняет две другие команды:


git fetch. С удалённого сервера забираются данные по всем указателям (ветки и коммиты).
git merge. В текущую ветку мержится та, которая указана как upstream branch. Для
master это как правило origin/master. 


Если master является предком origin/master, т.е просто отстаёт на сколько-то коммитов,
то выполняется fast-forward merge: ветка master переставляется на тот же коммит, что
и origin/master

Если в результате git pull появляются конфликты, значит две ветки разошлись. У них
где-то есть общий предок, но в каждой есть не менее одного отличающегося коммита. Именно
это и произошло.

$ git cat-file commit 9d2fda5
tree f10d0642a0bee9c08572afacc732e19aeef6f029
parent 62043f332ff8e6ca9e6d12058bddc490cb1694de
parent 0cf7f9e6e55ef80bf2fbfba69d8d2bee57955a75


Первым предком указан 62043f3 Работа со свзаными полями. Этот коммит находился на
текущей ветке, т.е. вашей ветке master. 

Вторым предком указан 0cf7f9e Add export all editable records for Admin role. Это
коммит из той ветки, которую мержили в текущую. Неожиданно, но это ваш собственный
только что сделанный коммит.

Как можно было добиться такого эффекта? Есть пара вариантов.


Запушить свою ветку в origin/master:

git checkout Alice
...
git commit ...
git push origin master


Тогда изменилось бы содержимое origin/master. Наш git pull в master сработал бы точно
так, как наблюдалось. Но тогда у Carol тоже появился бы этот коммит, чего не произошло.
Видим, что у коммита 6a11fc2 merge master, fix conflicts в предках тот же 62043f3 Работа
со свзаными полями
Сделать git pull из другой ветки

git commit 
git push origin HEAD 
git checkout master
git pull origin Alice


В результате в ваш master мержится только что запушенное содержимое origin/Alice.
Похоже, что именно это и произошло.


1.2 Пропали изменения у коллеги после мержа


  допишу позже, когда коллега уточнит подробности пропажи


2. Что делать, чтобы избежать будущих ошибок


  Тоже допишу вечером, пока оставлю оглавление



Использовать git pull --set-upstream
От модели «по ветке на разработчика» перейти к модели «по ветке на фичу»
Мержить только feature-ветки в master, но не master в другие ветки и не другие ветки
между собой.
Предотвращать попадание нерабочего кода в master:


Оставить право на мерж в мастер только тимлиду
Прогонять тесты на коммитах.

Изменение первого комита

#git #git_commit #git_revert

В первом (initial) коммите забыл внести файлы в gitignore сейчас уже комит 20-й. 

Как можно выйти с ситуации, чтоб в репозиторий запушить ветку без лишних файлов ?

В удаленный репозиторий ничего не пушил, но описание того что делал важно сохранить.

Возможно ли изменить первый коммит и чтоб те что шли после него уже были без лишних
файлов ?   
    

Ответы

Ответ 1

Вы что-нибудь на удаленный репозиторий пушили после этого?
Если да, то тогда прямо так сделать нельзя, но можно удалить вручную из репозитория
файлы, добавленные по ошибке и добавить в гитигнор, и больше они там не появятся.

После уточнения вопроса:
Можно попробовать применить git rebase с флагом root для того, чтобы создать новую
историю от коммита с правильным гитигнором.

Как обнулить историю Git?

#git #git_commit #git_remote #git_push

Ситуация такая: на сервере удалил репозиторий и создал заново, с локального теперь
нужно сделать push, но если сделаю, то всю историю коммитов запишет на сервер.

Как начать с нуля?
    

Ответы

Ответ 1

Все эти инструкции верны, если на удаленном сервере у вас пусто, а локально - есть
проект и репозиторий Git с историей, которую вы хотите удалить.

Что будет потеряно безвозвратно


Собственно, история. Вы точно хотите ее потерять? Ради нее весь Git и придумывался.
Весь код в не-слитых (unmerged) ветках.
Весь код в orphaned ветках.
Метки (tags)


Быстрый способ

Найдите первый коммит в ветке, запомните его sha1.

 git log --oneline


Переключитесь на тот коммит, который хотите сохранить в итоге.

git checkout master


Теперь используем git reset --soft чтобы сделать из всей истории один коммит (подробнее
- пункт 4.1: Как вернуться (откатиться) к более раннему коммиту? ).

git reset --soft 
git commit -m'слил историю в один коммит'


Долгий способ

Сделайте бэкап локального репозитория. Можно запушить на резервный удаленный репозиторий,
а можно просто взять и переместить папку .git в другое место.  

mkdir ../git-backup
mv .git ../git-backup/.git


Если не переместили локально, а забэкапили куда-то еще: удаляем папку.

rm -Rf .git


Теперь заново инициализируем репозиторий:

git init


Добавляем все файлы в рабочей области и делаем коммит.

git add .
git commit -m'начал с нуля'   


Когда все готово

Подключаем удаленный репозиторий и заливаем на него изменения:

git remote add origin 
git push -u origin --all


Ответ 2

Сделать clone, скопировать файлы (без .git), сделать push! Нет? ))


Ответ 3

Эта команда делает совсем другое: стирает всю историю до commitId и возвращает рабочую
область к его состоянию. При этом вы потеряете данные более поздних коммитов.

git reset --hard commitId #УДАЛЯЕТ ИСТОРИЮ GIT

Как отредактировать заголовок последнего коммита?

#git #git_commit

Написал неправильное сообщение, когда сделал commit, но ещё не сделал push. Как исправить?
    

Ответы

Ответ 1

Вы можете дать новый заголовок

git commit --amend -m "ваш заголовок"


или 

git commit --amend -c HEAD


если хотите отредактировать старый


Ответ 2

В похожем вопросе было очень интересное замечание, если вам нужно отредактировать
коммит более старый, а не последний, используйте rebase interactive (например тут если
искомый коммит 3мя ранее):  

git rebase -i HEAD~3  

Пометьте нужный коммит как edit, а потом делайте  

git commit --amend  

А после окончания редактирования коммита сделайте  

git rebase --continue  

чтобы завершить rebase.
Ну и как написал @Daniil следует потом сделать push force если коммиты уже в удаленном
репозитории.


Ответ 3

git commit --amend -m "исправленный текст"


Если исправленный текст должен быть больше одной строки, то: 

git commit --amend


Откроется текстовый редактор, и вы сможете внести исправления.

как переименовать коммит в github?

#git #github #git_commit

Недавно начал ознакомление с git и github. Могу ли я переименовать commit, уже пропушеный
на гитхабе? Знаю, что для этого используют git commit --amend -m "Some info". Только
вот куда это вписывать? Долго рылся в интернете и не смог найти внятного объяснения.
Использую расширение для VS, также есть десктопная версия гитхаба. 


    

Ответы

Ответ 1

Для выполнения команд git используется так называемая «консоль» — интерпретатор команд
на специальном языке. На Linux/Unix/OS X консоль работает с языками семейства Sh (sh,
bash, zsh...), на Windows есть cmd.exe (cmd) и PowerShell (powershell), но вместе с
Git ставится Git Bash – интерпретатор bash с базовым набором программ.


  Подробнее: Что означают такие понятия как: консоль, терминал, эмулятор терминала?




Не всегда коммит можно переименовывать

Пока коммит не попал на удаленный репозиторий, с ним можно делать что угодно.

Ваш коммит уже попал на удаленный репозиторий, в ветку master. Если кто-то ещё использует
этот репозиторий, переименовывать коммиты нельзя, потому что при переименовании фактически
создается новый коммит.

В вашем случае похоже, что вы работаете над учебным заданием в собственном репозитории,
поэтому вреда не будет.



Как переименовать коммит и отправить новое состояние на GitHub

Предположим, что есть вот такая история коммитов. На локальном и удаленном сервере
одна и та же история:

локальный: A---B (master)

удаленный: A---B (origin/master)


Для переименования коммита действительно нужно выполнить команду.

git commit --amend -m 'Новое сообщение'


Стало после --amend:

локальный: A---B2 (master) # совершенно другой коммит, хоть и с тем же содержимым)
            \
             B # не удален, но больше не принадлежит ветке master.
               # можно восстановить через git reflog

удаленный: A---B (origin/master)


После этого придётся явным образом переписать ветку master на удаленном репозитории
(на GitHub). Поскольку история коммитов разошлась, GitHub не примет изменения просто
так, нужно добавить ключ --force:

git push --force origin <имя ветки на удаленном репозитории>


Было:

локальный: A---B2 (master) 
            \
             B

удаленный: A---B (origin/master)


Стало после push --force:

удаленный: A---B2 (origin/master)
            \
             B # вообще недоступен, потому что у вас нет доступа к файловой системе
гитхаба
               # уберется сборщиком мусора на сервере



  Осторожно: в общем случае команда push --force опасна, так как переписывает состояние
ветки на удаленном репозитории и может привести к потерям.
  
  Например, если кто-то добавит свой коммит в ветку master, а потом вы переименуете
свою ветку и сделаете push --force, то чужой коммит будет потерян.
  
  Было: 


локальный: A---B2 (master) 
            \
             B

удаленный: A---B---С (origin/master)



  Стало: чужой коммит C потерян, автор идёт к вам с недобрыми намерениями


удаленный: A---B2 (origin/master)
            \
             B---С # недоступен

Работа с GIT локально?

#git #git_commit

Можно ли просмотреть изменения версий локально, не делая push в удаленный репозиторий?
Если можно, то как?
    

Ответы

Ответ 1

История коммитов:

# в текущей ветке
git log

# Если хотите посмотреть изменения во всех ветках в красивом виде:
git log --oneline --graph --decorate --all


Что поменялось в файлах проекта между двумя коммитами, ветками, тегами:

# явно сравниваем две ветки
git diff master branch1

# или два коммита
git diff ad72b3 134gf6

# можно сравнить что-то с текущим коммитом:
git diff branch1

# например, сравнить предыдущий коммит:
git diff HEAD^


Какие файлы изменились с момента последнего коммита:

git status -s


Что изменилось в этих файлах с последнего коммита:

git diff

# можно указать конкретный файл:
git diff filename


Ответ 2

Добрый день!

git status


Показывает текущий статус (изменения в индексе, изменения не в индексе, сколько коммитов
вы не запушили).

git log


Выводит список коммитов для той ветки, в которой вы находитесь. (Там будут номера
коммитов, их названия, автор, дата коммита и т.п.)

git branch


Покажет вам какие ветки есть у вас в репозитории и на какой вы находитесь сейчас

git diff <название файла>


Покажет непроиндексированные изменения в файле

Думаю, для начала вам будет достаточно)


Ответ 3

Командой git log -p в bash прямо высвечиваются красным и зеленым изменения


Ответ 4

Тут уже ответов много, но от себя добавлю.
Просмотр коммитов со списком изменённых файлов:

git log --stat  


Иногда бывает нужно посмотреть какие коммиты  принадлежат текущей ветке. В гите это
явно сделать нельзя, но можно сравнить с актуальной веткой. 

git cherry -v master


Какие изменения были сделаны в коммите можно посмотреть ещё и так:

git show 99452d955bdb57e7e4f2b09f8ce2fbb6cd56377a