Как изменить коммит git после пуша

If a commit message contains unclear, incorrect, or sensitive information, you can amend it locally and push a new commit with a new message to GitHub. You can also change a commit message to add missing information.

Rewriting the most recent commit message

You can change the most recent commit message using the git commit --amend command.

In Git, the text of the commit message is part of the commit. Changing the commit message will change the commit ID—i.e., the SHA1 checksum that names the commit. Effectively, you are creating a new commit that replaces the old one.

Commit has not been pushed online

If the commit only exists in your local repository and has not been pushed to GitHub.com, you can amend the commit message with the git commit --amend command.

1. On the command line, navigate to the repository that contains the commit you want to amend.

2. Type git commit --amend and press Enter.

3. In your text editor, edit the commit message, and save the commit.

   • You can add a co-author by adding a trailer to the commit. For more information, see «Creating a commit with multiple authors.»

   • You can create commits on behalf of your organization by adding a trailer to the commit. For more information, see «Creating a commit on behalf of an organization»

The new commit and message will appear on GitHub.com the next time you push.

You can change the default text editor for Git by changing the core.editor setting. For more information, see «Basic Client Configuration» in the Git manual.

Amending older or multiple commit messages

If you have already pushed the commit to GitHub.com, you will have to force push a commit with an amended message.

We strongly discourage force pushing, since this changes the history of your repository. If you force push, people who have already cloned your repository will have to manually fix their local history. For more information, see «Recovering from upstream rebase» in the Git manual.

Changing the message of the most recently pushed commit

1. Follow the steps above to amend the commit message.
2. Use the push --force-with-lease command to force push over the old commit.

   $ git push --force-with-lease origin EXAMPLE-BRANCH

Changing the message of older or multiple commit messages

If you need to amend the message for multiple commits or an older commit, you can use interactive rebase, then force push to change the commit history.

1. On the command line, navigate to the repository that contains the commit you want to amend.

2. Use the git rebase -i HEAD~n command to display a list of the last n commits in your default text editor.

   # Displays a list of the last 3 commits on the current branch
   $ git rebase -i HEAD~3

   The list will look similar to the following:

   pick e499d89 Delete CNAME
   pick 0c39034 Better README
   pick f7fde4a Change the commit message but push the same commit.
   
   # Rebase 9fdb3bd..f7fde4a onto 9fdb3bd
   #
   # 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

3. Replace pick with reword before each commit message you want to change.

   pick e499d89 Delete CNAME
   reword 0c39034 Better README
   reword f7fde4a Change the commit message but push the same commit.

4. Save and close the commit list file.

5. In each resulting commit file, type the new commit message, save the file, and close it.

6. When you’re ready to push your changes to GitHub, use the push —force command to force push over the old commit.

   $ git push --force origin EXAMPLE-BRANCH

For more information on interactive rebase, see «Interactive mode» in the Git manual.

As before, amending the commit message will result in a new commit with a new ID. However, in this case, every commit that follows the amended commit will also get a new ID because each commit also contains the id of its parent.

If you have included sensitive information in a commit message, force pushing a commit with an amended commit may not remove the original commit from GitHub. The old commit will not be a part of a subsequent clone; however, it may still be cached on GitHub and accessible via the commit ID. You must contact GitHub Support with the old commit ID to have it purged from the remote repository.

Further reading

• «Signing commits»

Поговорим о решении проблем с Git.

Восстановление накопленных изменений

В том случае, если изменения, внесённые пользователем, находятся в режиме накопления, применить их к ветке можно с помощью команды git stash apply. Также можно запустить git diff — эта команда поможет выявить различия. Для того, чтобы затем избавиться от накопленных данных, нужно запустить команду:

Если существует более одного накопления, найти нужное можно с помощью команды:

git stash list затем можно применить его, воспользовавшись его индексом:

Необходимо учитывать, что отсчёт индексов ведётся от нуля.

Восстановление удалённого тега

В том случае, если необходимо восстановить случайно удалённый тег, начать можно с его поиска:

git fsck --unreachable | grep tag

После того, как нужный тег найден, его следует восстановить:

git update-ref refs/tags/название-тега

Восстановление удалённого файла

Если вы случайно удалили файл, его можно быстро восстановить:

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

git checkout $commit~1 myfile.txt

Восстановление удалённой ветки

С помощью комманды git reflog можно узнать хеш (SHA1) последнего коммита в удалённой ветке. Скопируйте этот хеш и используйте в команде:

После этого восстановить удалённую ветку можно будет вот такой командой:

git checkout -b <название-ветки>

Изменение сообщения коммита перед его отправкой

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

Сообщение можно изменить и напрямую с помощью команды

git commit --amend -m "Новое прекрасное сообщение"

Изменение сообщения коммита после его отправки

В данном случае процесс занимает два шага. Сначала нужно изменить сообщение с помощью комманды git commit --amend, а затем перезаписать историю коммитов локальной ветки: git push <remote> <branch> --force

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

Использование алиасов команд в командной строке

Устали каждый раз печатать git status? Этой команде можно присвоить простой алиас, который проще и быстрее вбивать в git.

git config --global alias.st status

— теперь нужно писать только git st

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

git config --global alias.logme 'log -p --author=Rob'

Теперь алиас git logme будет выводить все наши коммиты.

Коммит в неправильную ветку

Нужно переключиться на новую ветку, которую вы забыли предварительно создать:

git checkout -b название-новой-ветки.

А затем переключиться к оригинальной ветке:

git checkout название-оригинальной-ветки

…и «откатиться» до последнего коммита, который нужно сохранить.

Чтобы это сделать, можно воспользоваться командой git log и сохранить хеш (SHA1) последнего коммита, который нужно оставить.. Например, это a31a45c.

Теперь его нужно сбросить: git reset --hard a31a45c и отправить получившийся результат.

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

Обновление конкретного подмодуля

Чтобы обновить конкретный подмодуль в репозитории, нужно добавить путь к подмодулю:

git submodule update --remote --merge <path>

Откат к конкретному коммиту в истории

Если вас не очень беспокоят изменения в локальном репозитории, то можно «откатиться» к конкретному коммиту в истории с помощью команды:

Эта команда установит HEAD на конкретный коммит. Также можно воспользоваться хешем коммита.

Отмена коммита до публикации изменений

Если вы сделали коммит, который впоследствии понадобилось отредактировать или полностью стереть, поможет команда git reset.

git reset HEAD~1 # отменить последний коммит, сохранить изменения
git reset --hard HEAD~1 # отменить последний коммит, стереть изменения

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

Чтобы сохранить сообщение коммита, наберите: :

Отмена коммита после отправки его в master-репозиторий

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

Отмена только коммита, который является вторым после последнего:

Простая отмена последнего коммита:

Отмена локальных изменений файлов

Простейшим способом избавиться от нежелательных изменений для файлов и папок является восстановление состояния последнего коммита. Сделать это можно с помощью специальной команды:

Кроме того, можно восстановить конкретный путь к файлу:

git checkout -- путь-до-файла

Отображение всех коммитов одного файла

Если вы хотите просмотреть все коммиты с изменениями конкретного файла, воспользуйтесь командой git log --follow -p -- myfile

Аргумент —follow позволяет вывести все изменения над файлом, даже если в процессе работы он был переименован.

Если опустить опцию -p, то система выведет только сообщения коммитов, но не их содержимое.

Отображения числа коммитов от каждого участника

Хотите узнать, сколько коммитов сделал каждый участник команды?

Эта команда выведет список, отсортированный в порядке убывания количества коммитов: git shortlog -s -n

Отобразить коммиты, содержащие удалённые файлы

Узнать, в каких коммитах содержатся удалённые файлы, можно с помощью команды:

git log --diff-filter=D --summary

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

Отсортировать коммиты по автору

Чтобы вывести список коммитов, отфильтрованных по автору, следует воспользоваться следующей командой:

git log --author="Имя автора"

Очистка всех скрытых состояний

Очистить все скрытые состояния можно следующей командой:

Переименование локальной и удалённой ветки

Предложим, у вас есть ветка «fix-bug25», которую вы захотели переименовать в «hotfix-users». Прежде всего, нужно будет изменить локальную ветку:

git branch -m fix-bug25 hotfix-users

А затем — удалённую ветку: переименовать её напрямую нельзя, поэтому нужно будет её удалить, и затем опубликовать заново уже с новым именем. Прежде чем приступать к этим процедурам, следует убедиться, что никто из членов команды не работает с этой веткой! Удаляем ветку: git push origin :fix-bug25

А теперь заново публикуем её с новым именем: git push origin hotfix-users

Переименование тега

Чтобы переименовать существующий тег:

git tag новое-название-тега старое-название-тега
git tag -d старое-название-тега
git push origin :refs/tags/старое-название-тега
git push --tags

Перестать отслеживать существующие файлы

Если вы хотите перестать отслеживать файлы, которые уже есть в репозитории, но при этом желаете сохранить его локально, осуществите коммит изменений и запустите команду:

Она удалит изменённые файлы из зоны подготовленных файлов (staging area). Затем нужно запустить команду:

и отправить изменения.

Подготовка удалённых файлов

Чтобы подготовить к коммиту файлы и папки, которые были удалены локально, можно использовать специальную команду:

Если требуется подготовить только используемый в данный момент путь, воспользуйтесь командой

Поиск конкретного сообщения во всех коммитах

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

Пометить конфликтующий файл, как разрешённый

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

Затем можно запустить git commit, чтобы разрешить конфликты и опубликовать изменения.

Просмотр всех неотправленных коммитов

Чтобы просмотреть все коммиты, которые ещё не были отправлены в соответствующие ветки, воспользуйтесь следующей командой:

git log --branches --not --remotes

Кроме того, можно использовать:

git log origin/master..HEAD

Просмотр старой ревизии файла

Существует возможность просмотреть содержимое файла в конкретный момент времени в прошлом. Для этого нужно использовать команду:

git show commitHash:myfile.txt

Публикация локальной ветки для удалённого редактирования

Если вы создали локальную ветку, и хотите, чтобы другие пользователи могли с ней работать, воспользуйтесь командой:

git push -u origin название-моей-новой-ветки

Теперь они тоже смогут вносить изменения в эту ветку.

Сброс локальной ветки до состояния удалённой

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

Прежде всего нужно получить свежие обновления из удалённой ветки:

git fetch название-удалённой-ветки.

А затем нужно сообщить git, что локальную ветку следует «откатить» до состояния удалённой:

git reset --hard origin/название-локальной-ветки.

При наличии коммита, который нужно сохранить, перед сбросом нужно создать новую ветку и произвести коммит: git commit -m «Обновление»

git branch название-новой-ветки

Синхронизировать ветку с master-репозиторием

Чтобы синхронизировать последние изменения в репозитории master (или с любой другой веткой, с которой вы работали) необходимо «перебазировать» локальную ветку. Предположим, вы работаете над веткой foobar:

А затем осуществляете «перебазирование»:

После этого будут применены коммиты origin из master. После разрешения конфликтов процесс можно продолжить с помощью команды git rebase —continue. Теперь можно продолжать работу над своей веткой или осуществить её слияние (merge) с главным репозиторием.

Слияние локальных изменений с другой веткой

Это можно сделать прямо в процессе стандартного слияния (merge). Вам стоит сохранить историю слияний используя флаг —no-ff, что означает no fast forward.

Перейдите в ветку, в которую будут вливаться изменения, убедитесь в её актуальности и запустите процесс:

git merge <другая-ветка> --no-ff

Затем появится сообщение о коммите merge X into Y branch, после чего вы можете смело запушить ваше слияние.>

Совмещение двух и более коммитов

Здесь нам понадобится произвести интерактивное перебазирование. Если перебазирование происходит относительно master-ветки, то начать следует с команды git rebase -i master. Однако, если перебазирование происходит не относительно ветки, то нужно будет перебазироваться относительно HEAD.

Если есть необходимость в совмещении двух последних коммитов, можно использовать команду

После её ввода появятся инструкции по выбору коммитов. В том случае, если необходимо совместить все коммиты с первым старейшим коммитом, то в первой строке нужно написать pick, а для всех остальных коммитов изменить букву на f. Подробнее здесь

Совмещение коммитов по конкретной функции для добавления в ветку релиза

Если вы решите совместить и опубликовать коммиты, то возникнет новый коммит в ветке релиза, поэтому история ветки конкретной функции останется неизменной.

Ниже представлен пример того, как достичь подобного эффекта:

git fetch origin
git checkout [release-branch]
git rebase origin/[release-branch]
git merge —squash —no-commit [feature-branch]
git commit -m 'Merge X into Y'

В конечном итоге останется только один коммит в ветке релиза, а история изменений в ветке разработки конкретной функции останется нетронутой.

Подробнее о ветках функций

Создание новой ветки с изменениями текущей

Часто возникает ситуация, при которой пользователи начинают изменять файлы в ветке, чтобы что-то исправить, и лишь позднее вспоминают, что предварительно не создали новую ветку. К счастью, есть способ сделать это уже в процессе:

git checkout -b название-моей-новой-ветки

Эта команда перенесёт файлы из текущей ветки в новую, которую потом уже можно «закоммитить».

Убрать файл из буфера

Чтобы убрать добавленный по ошибке файл из буфера, нужно воспользоваться простой командой:

git reset HEAD unlovedfile.txt

Удаление внешней ветки

Если вы хотите удалить ветку, введите команду:

git push origin --delete название-ветки

Удаление неотслеживаемых файлов и папок

Чтобы удалить неотслеживаемые файлы и папки из рабочей копии наберите следующую команду:

Чтобы в принципе удалить их:

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

Удаление старых веток, стёртых из внешнего репозитория

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

git-remote prune название-удалённой-ветки.

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

Удаление файла из git с сохранением его локальной копии

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

git rm --cached myfile.txt

Больше статей о Git

• Полезные команды для работы с Git
• Как работать с GitHub в большой команде
• Как бесплатно залить сайт на хостинг GitHub Pages

Changing the latest Git commit message

If the message to be changed is for the latest commit to the repository, then the following commands are to be executed:

1. git commit --amend -m "New message"
   

2. git push --force repository-name branch-name
   

Note that using --force is not recommended unless you are absolutely sure that no one else has cloned your repository after the latest commit.

A safer alternative is to use:

git push --force-with-lease repository-name branch-name

Unlike --force, which will destroy any changes someone else has pushed to the branch, --force-with-lease will abort if there was an upstream change to the repository.

Changing older commit messages

If the message needs to be amended for an older commit, then the interactive rebase tool can be used:

1. Navigate to the repository that contains the commit you want to amend and open a terminal window.
2. Use the git rebase -i HEAD~n command to display a list of the last nn commits in your default text editor. For example, the following command would display a list of the last three commits in your current branch:

   git rebase -i HEAD~3 
   

The list would be similiar to
this:

pick e499d89 Delete CNAME
pick 0c39034 Better README
pick f7fde4a Change the commit message but push the same commit.

# Rebase 9fdb3bd..f7fde4a onto 9fdb3bd
#
# 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

1. Replace pick with reword before each commit message that needs to be changed:

   pick e499d89 Delete CNAME
   reword 0c39034 Better README
   reword f7fde4a Change the commit message but push the same commit.
   

2. Save and close the commit list file.
3. In each resulting commit file, type the new commit message, save the file, and close it.
4. Force push the amended commits using git push --force.

Many times, when working with Git, you may want to revise your local commit history.
One of the great things about Git is that it allows you to make decisions at the last possible moment.
You can decide what files go into which commits right before you commit with the staging area, you can decide that you didn’t mean to be working on something yet with git stash, and you can rewrite commits that already happened so they look like they happened in a different way.
This can involve changing the order of the commits, changing messages or modifying files in a commit, squashing together or splitting apart commits, or removing commits entirely — all before you share your work with others.

In this section, you’ll see how to accomplish these tasks so that you can make your commit history look the way you want before you share it with others.

$ git commit --amend --no-edit

pick f7f3f6d Change my name a bit
pick 310154e Update README formatting and add blame
pick a5f4a0d Add cat-file

# Rebase 710f0f8..a5f4a0d onto 710f0f8
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# 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

$ git log --pretty=format:"%h %s" HEAD~3..HEAD
a5f4a0d Add cat-file
310154e Update README formatting and add blame
f7f3f6d Change my name a bit

edit f7f3f6d Change my name a bit
pick 310154e Update README formatting and add blame
pick a5f4a0d Add cat-file

$ git rebase -i HEAD~3
Stopped at f7f3f6d... Change my name a bit
You can amend the commit now, with

       git commit --amend

Once you're satisfied with your changes, run

       git rebase --continue

pick f7f3f6d Change my name a bit
pick 310154e Update README formatting and add blame
pick a5f4a0d Add cat-file

pick 310154e Update README formatting and add blame
pick f7f3f6d Change my name a bit

#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# 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

pick f7f3f6d Change my name a bit
squash 310154e Update README formatting and add blame
squash a5f4a0d Add cat-file

# This is a combination of 3 commits.
# The first commit's message is:
Change my name a bit

# This is the 2nd commit message:

Update README formatting and add blame

# This is the 3rd commit message:

Add cat-file

pick f7f3f6d Change my name a bit
edit 310154e Update README formatting and add blame
pick a5f4a0d Add cat-file

$ git reset HEAD^
$ git add README
$ git commit -m 'Update README formatting'
$ git add lib/simplegit.rb
$ git commit -m 'Add blame'
$ git rebase --continue

$ git log -4 --pretty=format:"%h %s"
1c002dd Add cat-file
9b29157 Add blame
35cfb2b Update README formatting
f7f3f6d Change my name a bit

pick 461cb2a This commit is OK
drop 5aecc10 This commit is broken

$ git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21)
Ref 'refs/heads/master' was rewritten

$ git filter-branch --subdirectory-filter trunk HEAD
Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12)
Ref 'refs/heads/master' was rewritten

$ git filter-branch --commit-filter '
        if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
        then
                GIT_AUTHOR_NAME="Scott Chacon";
                GIT_AUTHOR_EMAIL="schacon@example.com";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD

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

Однако порой в спешке под конец рабочего дня разработчик может закоммититься с подписью вроде такой «WIP» или «TMP». В статье рассмотрим, как в git переименовать коммит. При этом возможны два основных случая — коммит является последним или коммит не является последним.

Переименование последнего коммита

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

Изменение комментария к не последнему коммиту

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

Итак, чтобы в git исправить комментарий такого коммита потребуется выполнить rebase в интерактивном режиме.

1. Сначала нужно посмотреть, на сколько коммитов назад находится тот коммит, которые нужно отредактировать. Для этого можно использоваться либо git log --oneline, либо консольный GUI для Git, например, tig.

Видим, что изменить комментарий нужно к коммиту «tmp», находящийся позади на четыре коммита относительно HEAD.

2. Теперь запускаем rebase в интерактивной режиме:

git rebase -i HEAD~5

3. В появившемся редакторе следует в строках коммитов изменить команду pick на reword.

Затем сохраняем файл и выходим.

4. Автоматически начнется ребейз и откроется файл редактирования коммита. Здесь необходимо ввести новую подпись к коммиту.

5. Остаётся сохранить и выйти. Теперь название коммита изменено.

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

git push --force

Однако, если работа в ветке ведётся несколькими разработчиками одновременно, тогда такой подход неприемлем.

Метки: Метки: git

Answer of @Mureinik is good but not understandable by newbie.

First method:

1. If you only want to edit latest commit message, then you only need git commit --amend, you would see:

<your existing commit mesage foo bar> 

# Please enter the commit message fir your changes. Lines starting
# with # will be ignored, and an empty message aborts the commit.
#
# Date: Sat Aug 24 17:56:16 2019 +0800
#
# On branch is up to date with 'origin/master'.
#
# changes to be committed:
#       modified:   foo.py
#

1. As you can see, commit message on top without any prefix of command such as pick, this is already the edit page and you can direct edit the top message and save&quit, e.g.:

<your new correction commit message> 

# Please enter the commit message for your changes. Lines starting
....

1. Then do git push -u origin master --force or <how you push normally> --force. The key here is --force.

Second method:

1. You can see the commit hash by git log or extract from the
   repository url, example in my case is 881129d771219cfa29e6f6c2205851a2994a8835

2. Then you can do git rebase --interactive 881129d771219cfa29e6f6c2205851a2994a8835 or git rebase -i HEAD^ (if the latest)

3. You would see:

pick <commit hash> <your current commit message>

# Rebase 8db7e8b..fa20af3 onto 8db7e8b
#
# 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
#
# 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

1. But if you see noop then you are probably typing wrong, e.g. if you do git rebase -i 881129d771219cfa29e6f6c2205851a2994a88 which missing ^ at the end, you better quit the editor without save and figure out the reason:

noop

# Rebase 8db7e8b..fa20af3 onto 8db7e8b
...

1. If no noop issue, then simply change the word pick to reword , other just remains (you don’t edit commit message at this point), e.g:

reword <commit hash> <your current commit message>

# Rebase 8db7e8b..fa20af3 onto 8db7e8b
#
# Commands:
#  p, pick = use commit
...

1. Save&quit will see the edit page similar to method #1:

<your existing commit mesage foo bar> 

# Please enter the commit message fir your changes. Lines starting
# with # will be ignored, and an empty message aborts the commit.
#
# Date: Sat Aug 24 17:56:16 2019 +0800
#
# interactive rebase in progress; onto b057371
# Last command done (1 command done):
#    reword d996ffb <existing commit message foo bar>
# No commands remaining.
# You are currently editing a commit while rebasing branch 'master' on 'b057371'.
#
# changes to be committed:
#       modified:   foo.py
#

1. Edit the message on top, same like method #1 and save&quit, e.g:

<your new correction commit message> 

# Please enter the commit message for your changes. Lines starting
....

1. Again, same like method #1, do git push -u origin master --force or <how you push normally> --force. The key here is --force.

For more info please read the doc.

Many programmers underestimate the role of the commit message, while it is very important for managing the work. It helps other developers working on your project to understand the changes that you have made. So it must be as concrete, well-structured and clear as possible.

In this snippet, we will show you how to change your most recent commit message, as well as how to change any number of commit messages in the history.

Read on to see the options.

You can use --amend flag with the git commit command to commit again for changing the latest commit:

git commit --amend -m "New commit message"

Running this will overwrite not only your recent commit message but, also, the hash of the commit. Note, that it won’t change the date of the commit.

It will also allow you to add other changes that you forget to make using the git add command:

git add more/changed/w3docs.txt
git commit --amend -m "message"

The -m option allows writing the new message without opening the Editor.

If you want to change the message of the commit that is already pushed to the server, you should force push it using the git push command with —force flag, otherwise, your push will be rejected.

Check out Force Pushing Local Changes to Remote for more details on how to force push your changes.

In this section, we will show you the steps to follow if you want to change multiple commit messages in the history.

Let’s assume that we want to take the 10 latest commit messages, starting from the HEAD.

Run Git Rebase in Interactive Mode

Firstly, you should run the git rebase in the interactive mode:

Type «Reword»

After the first step, the editor window will show up the 10 most recent commits. It will offer you to input the command for each commit. All you need to do is typing «reword» at the beginning of each commit you want to change and save the file. After saving, a window will open for each selected commit for changing the commit message.

Enter a New Commit Message

After the second step, an editor will open for each commit. Type a new commit message and save the file.

Check out Force Pushing Local Changes to Remote for more details on how to force push your changes.

It is not recommended to change a commit that is already pushed because it may cause problems for people who worked on that repository.

If you change the message of the pushed commit, you should force push it using the git push command with --force flag (suppose, the name of remote is origin, which is by default):

git commit --amend -m "New commit message."

git push --force origin HEAD

—force overwrites the remote branch on the basis of your local branch. It destroys all the pushed changes made by other developers. It refers to the changes that you don’t have in your local branch.

Here is an alternative and safer way to amend the last commit:

git push --force-with-lease origin HEAD

—force-with-lease is considered a safer option that will not overwrite the work done on the remote branch in case more commits were attached to it (for instance, by another developer). Moreover, it helps you to avoid overwriting another developer’s work by force pushing.

The git add command is used for adding changes in the working directory to the staging area. It instructs Git to add updates to a certain file in the next commit. But for recording changes the git commit command should also be run. The git add and git commitcommands are the basis of Git workflow and used for recording project versions into the history of the repository. In combination with these two commands, the git status command is also needed to check the state of the working directory and the staging area.

The git push command is used to upload the content of the local repository to the remote repository. After making changes in the local repository, you can push to share the modification with other members of the team.

Git refuses your push request if the history of the central repository does not match the local one. In this scenario, you should pull the remote branch and merge it into the local repository then push again. The --force flag matches the remote repository’s branch and the local one cleaning the upstream changes from the very last pull. Use force push when the shared commits are not right and are fixed with git commit --amend or an interactive rebase. The interactive rebase is also a safe way to clean up the commits before sharing. The git commit --amend option updates the previous commit.

Изменение истории

Если это последняя фиксация, вы можете просто сделать это:

git commit --amend

Это вызывает редактор с последним сообщением фиксации и позволяет редактировать сообщение. (Вы можете использовать -m, если хотите стереть старое сообщение и использовать новый.)

Нажатие

И затем, когда вы нажимаете, сделайте следующее:

git push --force-with-lease <repository> <branch>

Или вы можете использовать «+»:

git push <repository> +<branch>

Или вы можете использовать --force:

git push --force <repository> <branch>

Будьте внимательны при использовании этих команд.

• Если кто-то другой нажал изменения в одну ветвь, вы, вероятно, захотите избежать уничтожения этих изменений. Параметр --force-with-lease является самым безопасным, так как он будет прерван, если есть какие-либо восходящие изменения (

• Если вы явно не укажете ветвь, Git будет использовать настройки push по умолчанию. Если ваша настройка по умолчанию «соответствует», вы можете одновременно уничтожить изменения на нескольких ветвях.

Вытягивание/выборка

Любой, кто уже вытащил, теперь получит сообщение об ошибке, и им нужно будет обновить (при условии, что они сами не вносят никаких изменений), выполнив что-то вроде этого:

git fetch origin
git reset --hard origin/master # Loses local commits

Будьте осторожны при использовании reset --hard. Если у вас есть изменения в ветке, эти изменения будут уничтожены.

Заметка об изменении истории

Уничтоженные данные на самом деле являются только старым сообщением фиксации, но --force не знает этого и с радостью удалит другие данные. Поэтому подумайте о --force как «Я хочу уничтожить данные, и я точно знаю, какие данные уничтожаются». Но когда уничтоженные данные фиксируются, вы можете часто восстанавливать старые коммиты из reflog — данные фактически потеряны, а не уничтожены (хотя потерянные синтаксические ошибки периодически удаляются).

Если вы не думаете, что уничтожаете данные, избегайте --force… могут произойти плохие вещи.

Вот почему --force-with-lease несколько безопаснее.

Это пост для тех, кто начинает работу с Git. Все, что здесь написано по частям можно найти в многочисленных простынях о Git на Хабре. Но я подумал, что неплохо было бы иметь отдельный предельно понятный топик, который бы гуглился по запросу «git изменение коммитов».

Изменение последнего коммита

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

git add .

Затем закоммитить изменения с параметром —amend (amend /əˈmɛnd/ — вносить поправки, исправлять, улучшать):

git commit --amend

Изменение названия последнего коммита

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

git commit --amend -m "Новое название"

Изменение НЕ последнего коммита

Тут чуть посложнее, сделайте для начала два коммита, в моем примере они будут называться С1 и С2:

Для начала выполняем:

git rebase --interactive 
# короткая версия: git rebase -i

Откроется редактор, в котором вы можете указать что хотите сделать:

Как видите, git rebase -i может послужить когда нужно

• r reword переименовать коммит
• e edit изменить коммит
• s squash склеить два или больше коммитов (squash /skwɒʃ/ — втиснуть, сжимать, тыква )

Рядом с коммитом С1 вместо pick впишите e для редактирования коммита или r для переименования. Сохранив файл, вы увидите подсказку от Git:

Разберемся подробнее что произошло. Мы переместились на коммит С1, «спрыгнув» с ветки master. Это можно проверить, запустив:

git branch

В ответ получим:

* (no branch, rebasing master)
  master

Дальше, как первой части поста где мы меняли последний коммит, делаем изменения и добавляем их:

git add .

и коммитим с параметром --amend:

git commit --amend

После успешного коммита, следуя подсказке (чуть выше на скриншоте), выполняем:

git rebase --continue

Тем самым мы возвратимся на ветку master с измененным коммитом, что и требовалось.

Пост получился короткий и, надеюсь, ясный. Commit early, commit often.