Введение¶
Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.
Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git, а StGit использует Git для управления коллекцией патчей.
Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.
Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH- или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.
Apply Git Patch Files
Now that you have created a patch file from your branch, it is time for you to apply your patch file.
In order to apply a Git patch file, use the “git am” command and specify the Git patch file to be used.
Referring to our previous example, make sure to check out to the branch where you want your patch file to be applied.
Now that you are on your branch, apply your Git patch file with the “git am” command.
Now, taking a look at your Git log history, you should see a brand new commit created for your patch operation.
When applying a Git patch, Git creates a new commit and starts recording changes from this new commit.
Awesome! You have successfully applied your Git patch file using “git am”.
Наблюдения и советы при работе с коммитами
В каждой команде свои правила и соглашения. Но я приведу общие советы и размышления, которые помогут в любом проекте
- коммит — это законченный функционал
- всегда проверяйте перед коммитом, что в него попадет. git diff — наш лучший друг
- выделяйте мелкие баги и правки в отдельные коммиты
- маленький коммит в одну строку — это нормально
- видите много изменений — подумайте, можно ли разбить их на отдельные коммиты
- мыслите задачей, а не файлами. Выделяйте полезное действие коммита
- commit message говорит, ЧТО делает коммит, а не КАК делает
- коммит-рефакторинг — это нормально. Не стоит мешать его с другими задачами
- git плохо работает с бинарниками (картинками, pdf, видеофайлами) — видит факт изменения, но не сами изменения
- подписывайте коммит так, чтобы можно было проследить историю развития проекта
Все эти правила одновременно соблюсти довольно трудно. Это приходит с опытом, но главное — полагаться на здравый смысл.
Умение хорошо формировать и подписывать коммиты — один из признаков хорошего разработчика.
Используйте удобные инструменты в IDE, но не забывайте командную строку. В ней вы лучше будете понимать, как устроен git, как он работает
Git tools для продвинутых разработчиков
Git tools для продвинутых разработчиков
При работе с Git вы можете столкнуться с ситуацией, когда вам нужно отредактировать сообщение коммита. Существует ряд причин, по которым вы хотите внести изменения, например, исправление опечатки, удаление конфиденциальной информации или добавление дополнительной информации.
В этом руководстве объясняется, как изменить сообщение о самых последних или старых коммитах Git.
Не задний коммит
Чтобы изменить сообщение самого последнего коммита, который не был в удаленный репозиторий, его снова, используя флаг .
-
Перейдите в каталог хранилища в вашем терминале.
Выполните следующую команду, чтобы изменить (изменить) сообщение о последнем коммите:
Команда выполняет перезапись самого последнего коммита новым.
Опция позволяет вам написать новое сообщение в командной строке, не открывая сеанс редактора.
Перед изменением сообщения о коммите вы также можете добавить другие ранее забытые изменения:
Задний коммит
Измененный (измененный) коммит — это новый объект с другим SHA-1. Предыдущий коммит больше не будет существовать в текущей ветке.
Как правило, вам следует избегать внесения изменений в коммит, который уже выдвинут, поскольку это может вызвать проблемы у людей, которые основывают свою работу на этом коммите. Хорошей идеей будет проконсультироваться со своими коллегами-разработчиками перед изменением принудительного коммита.
-
Перейдите в хранилище.
Исправьте сообщение о последнем введенном коммите:
Принудительно нажмите, чтобы обновить историю удаленного хранилища:
Изменение старого или нескольких коммитов
Команда переписывает историю коммитов, и настоятельно не рекомендуется перебазировать коммиты, которые уже переданы в удаленный репозиторий Git.
-
Перейдите в хранилище, содержащее сообщение фиксации, которое вы хотите изменить.
Введите , где — количество коммитов, на которых необходимо выполнить ребазинг. Например, если вы хотите изменить 4-й и 5-й последние коммиты, введите:
Команда отобразит последние коммиты в текстовом редакторе по умолчанию:
Перейдите к строкам коммит-сообщения, которое вы хотите изменить, и замените на :
Сохраните изменения и закройте редактор.
Для каждого выбранного коммита открывается новое окно текстового редактора. Измените сообщение о коммите, сохраните файл и закройте редактор.
Принудительно отправить изменения в удаленный репозиторий:
Вывод
Чтобы изменить самое последнее сообщение о , используйте команду а для изменения более старого или многократного сообщения о используйте
Не вносите изменения в принудительные коммиты, так как это может вызвать массу проблем у ваших коллег.
В этой статье будет показано, как стирать, настраивать, изменять или редактировать «Начать» название экрана запуска Windows 8 с помощью Resource Hacker.
Узнайте, как изменить размер или изменить размер миниатюр панели задач в Windows Vista / 7/8 через взлом реестра. Если вы обнаружите, что размер миниатюр слишком мал, легко увеличивайте его размер.
Git remotes — это указатели на версии репозитория, которые обычно хранятся на других серверах. В этом руководстве объясняется, как изменить URL-адрес пульта Git.
Добавляем новые файлы на ПК и переносим их в удалённый репозиторий
Папка с файлами нашего репозитория хранится на рабочем столе. Чтобы продолжить работу, откроем проект в редакторе кода: можно выбрать любую программу, и GitHub Desktop предлагает воспользоваться Atom.
Выбор редактора кода — дело вкуса. Мы будем работать с репозиторием в Visual Studio Code — это бесплатный редактор от компании Microsoft.
Папка с нашим тестовым репозиторием в Visual Studio Code
Создадим HTML-файл, добавим базовую структуру и посмотрим на боковое меню — HTML-файл подсвечен зелёным цветом. Это означает, что в проекте появились изменения и они ещё не добавлены в репозиторий на GitHub.
Редактор кода подсвечивает зелёным цветом новые файлы
Переходим в GitHub Desktop — созданный HTML-файл появится во вкладке Changes. Для его сохранения пишем коммит и переходим во вкладку History для просмотра изменений. Если изменения сохранились, нажимаем на Push origin и отправляем изменения в удалённый репозиторий.
5 ответов
Лучший ответ
Фиксация в Git — дешевая и полностью локальная операция, поэтому нет причин избегать фиксации, пока вы ее никуда не продвигаете.
Просто создайте новую локальную ветку и зафиксируйте там свои изменения. Вы всегда можете удалить ветку позже, если она вам больше не нужна, или вы можете сохранить ветку и использовать ее для работы над тем, что вы делаете, а затем объединить (или переустановить) ее в основную ветку, когда она будет готова. Это хороший рабочий процесс для использования при работе с Git.
8
hammar
21 Мар 2012 в 18:45
Фиксация в локальном репо в git не является «привязкой». Вы можете зафиксировать свои изменения, создать свой патч, а затем выполнить мягкий сброс в своей ветке до предыдущей фиксации, и это похоже на то, что вашей фиксации никогда не было.
При этом на самом деле нет причин, по которым вам НЕОБХОДИМО сбрасывать ветку после создания патча. Вы можете оставить фиксацию в репо и просто не нажимать на нее, пока не будет завершена проверка кода. Если вам нужно вернуться и внести изменения в исходный коммит, у вас есть варианты на этом этапе.
И если вы создадите ветку для фиксации, как предлагает hammar, это еще больше упростит возврат и внесение изменений позже без необходимости выполнять какие-либо раздражающие перебазирования и тому подобное в основной ветке перед нажатием.
1
mockobject
21 Мар 2012 в 18:49
Как сказал @hammar, коммит — это дешево, и тогда вы можете удалить коммит с помощью и т. Д.
Вы также можете спрятать, а затем сделать:
7
manojlds
21 Мар 2012 в 18:53
Общий шаг для генерации патча без фиксации наконец
-
зафиксируйте свои локальные изменения, используя
Примечание: не нажимайте эту фиксацию.
-
сгенерировать патч
он сгенерирует 0001-.patch
-
вернуть назад локальную фиксацию
удалить фиксацию, но сохранить свою работу
удалить фиксацию с вашей работой
9
Tunaki
27 Фев 2016 в 13:55
Когда другие ребята уже дали какой-то ответ, соответствующий соглашению git, вопрос OP «создать патч без фиксации» также может быть решен следующим образом:
Позже вы можете применить этот патч, также без фиксации, следующим образом:
Но если вы просто работаете локально, достаточно, чтобы перенести все ваши текущие незафиксированные изменения в этот another_branch, даже без исправлений и применения.
129
RayLuo
23 Фев 2014 в 23:46
git merge
Чтобы объединить ветки, например, ветку с веткой , необходимо выполнить следующие команды:
git checkout master git merge hotfix
Объединяем текущую локальную ветку с удаленной:
git merge origin/master
Создаем новую ветку на основе изменений в другой ветке
Бывают ситуации, когда вы начинаете работать на какой-либо ветке, но изменения становится настолько большими, что вам хотелось бы перенести их в новую ветку. Это сделать довольно просто:
git checkout -b new_feature
Коммитим изменения. Возвращаемся на старую ветку и вы уже не увидите своих изменений — они останутся на ветке .
—ours к файлу
Допустим, после ветки в в файле появились конфликты, при этом мы уверены, что код на ветке правильный. Чтобы разрешить конфликты в этом случае нам поможет команда:
git checkout --ours index.html
Если нам нужно взять версию из сливаемой () ветки:
git checkout --theirs index.html
Вернуться к версии с маркерами конфликта:
git checkout --merge index.html
Настройки
Переменные конфигурации Git хранятся на windows в файле . каждого конкретного репозитория приоритетен.
Команды
git config
Данную информацию следует указать обязательно, так как она будет включаться во все ваши коммиты:
git config –global user.name "firstName lastName" git config –global user.email "email@mail.ru"
Git позволяет ставить настройки общесистемные (), на уровне конкретного пользователя (), на уровне проекта ().
Проверка настроек
git config --list
Узнаем подробности о том, как работает команда, например, :
git help git help log
Пример файла
name = name_user
email = mail_user@mail.ru
default = matching
postBuffer = 524288000
st = status
ci = commit
br = branch
co = checkout
df = diff
lg = log -p
Псевдонимы (алиасы) в GIT
Команда позволяет создавать псевдонимы:
git config --global alias.st status git config --global alias.ci commit git config --global alias.co checkout git config --global alias.br branch git config --global alias.unstage 'reset HEAD --' git config --global alias.last 'log -1 HEAD'
rebase
Команда своего рода швейцарский нож для истории в git — с ее помощью можно переписывать историю — объединять, редактировать, менять местами коммиты. Но самое главное применение — это перенос или перебазирование веток.
Перенос веток
Допустим, у нас есть две ветки и ; ветка ушла вперед и нам нужно перенести коммиты из в ветку , для этого мы можем сделать:
git rebase master
И ветка будет начинаться с более нового состояния . См. скрин rebase_01
Как это работает: все коммиты из ветки (также как это делает cherry-pick) переносятся в ветку .
При переносе веток возможны конфликты, в этом случае перенос (rebase) будет остановлен на том коммите, в котором возник конфликт — поправьте конфликт (зафиксируйте изменения) и выполните команду:
git rebase --continue
Отказ от переноса
Чтобы отказаться от переноса (например, ваш rebase остановился на конфликте) выполните команду:
git rebase --abort
Чтобы пропустить коммит при переносе, например, rebase остановился на конфликте, вы можете выполнить команду:
git rebase --skip
Отмена rebase
Отмена rebase после того как rebase завершился.
git reset --hard ORIG_HEAD
Или (что более надежно).
git reflog feature
Удаленный репозиторий
Команда позволяет просмотреть удаленные репозитории
git remote -v
параметр позволяет увидеть URL-адреса.
git remote add (добавляем уд. реп., для работы локально)
Добавление удаленных репозиториев под коротким именем:
git remote add
git remote add alias_repo
— теперь вместо полного URL-адреса в командную строку можно вводить имя
В уже сущест. реп. добавляем реп. сторонний и стягиваем из него ветку :
git remote add interview https://github.com/asdasd/interview.git git pull interview master
Пример использования:
- Иниц. пустой реп.
- Добавляем реп.
- извлекаем все данные ()
- и стягиваем ветку из реп.
git init git remote add kuku https://github.com/denzLLL/test.git git fetch kuku git pull kuku master
git fetch (Извлечение данных из уд. реп.)
Извлечение данных из удаленного репозитория выполняется командой:
git fetch
После исполнения данной команды у вас должны появиться ссылки на все ветки удаленного проекта.
Отметьте, что при клонировании автоматически добавляется удаленный репозиторий с именем .
git fetch origin
Получаем данные из удаленного репо, но при этом они есть лишь в папке , в рабочей папке их нет. Для того чтобы данные появились в рабочей папке необходимо выполнить команду:
$ git pull
git push (проталкиваем изменения на уд. сервер)
Отправляем изменения в удаленный репозиторий:
git push
Отправим ветку на удаленный репозиторий :
git push origin master
Или, что тоже самое:
git push origin master:master
git push -u origin master
Параметр (флаг представляет краткой обозначение для , который устанавливает конфигурацию ветки) позволит нам в будущем не указывать дополнительные параметры: локальная ветка будет автоматически связана с удаленной веткой, и вы можете использовать без каких-либо аргументов.
Отправим ветку на удаленный репозиторий :
git push origin master:masterB
Посредством : разделяем локальную ветку и удаленную ветку .
Удаляем ветку в удаленном репозитории:
git push origin --delete
git pull (скачиваем изменения)
выполняет по сути команды и . Если ветка настроена на наблюдение, то обращение будет к ветке на сервере, за которой наблюдает текущая ветка.
git remote show (получаем инфо. об уд. реп.)
Команда позволяет просмотреть дополнительную информацию о конкретном удал. реп., включая удаленные ветки, локальные ветки, а также настройки для и .
git remote show git remote show origin
Команда также оповестит вас о том, что, если находясь на ветке master вы запустите , то ветка на удаленном репо. будет автоматически c вашей локальной веткой .
Удаленные ветки
Удаленные ветки — это ссылки на состояние веток в удаленных репозиториях.
Структура наименования удаленной ветки — (имя удаленного репозиория)/ветка. Например, .
Если вам потребуется своя локальная ветка (), аналогичная удаленной ветки, то можно воспользоваться командой:
git checkout -b name_branch origin/name_branch
Этим мы также говорим, что ветка следит за удаленной веткой .
Данную операцию можно реализовать при помощи параметра :
git checkout --track origin/name_branch
Будет создана локальная ветка , которая следит за удаленной веткой .
Или создадим локальную ветку, чье имя будет отличаться от имени удаленной ветки:
git checkout -b test-master origin/master
Локальная ветка ‘смотрит’ на удаленную ветку .
Если вам потребуется поменять удаленную ветку, за которой вы следите, используйте параметр или команды :
git branch -u origin/test-git
Текущая ветка начнет следить за удаленной
Параметр позволяет увидеть ветки наблюдения (локальная информация):
git branch -vv
Чтобы увидеть актуальные ветки наблюдения:
git fetch --all git branch -vv
Thunderbird
There are three different approaches: use an add-on to turn off line wraps, configure Thunderbird to not mangle patches, or use an external editor to keep Thunderbird from mangling the patches.
mailnews.send_plaintext_flowed => false
mailnews.wraplength => 0
-
4.
Open a compose window and click the external editor icon.
-
5.
In the external editor window, read in the patch file and exit the editor normally.
Side note: it may be possible to do step 2 with about:config and the following settings but no one’s tried yet.
-
mail.html_compose => false mail.identity.default.compose_html => false mail.identity.id?.compose_html => false
Немного о философии коммитов
Концепция коммитов заставляет если не менять подход к разработке, то по-другому к ней относиться. С git нам приходится не просто писать код, а планировать его написание.
Планировать задачи, над которыми мы работаем. Декомпозировать задачи, то есть разбивать их на небольшие части.
Мы больше думаем о том, что мы работаем не одни, а в команде. История коммитов общая для всего проекта.
Чем лучше мы научимся формировать и подписывать коммиты, тем легче будет ориентироваться в истории нам самим и нашим коллегам.
В любом проекте важны не только код и его структура, но и история коммитов и хорошие commit message.
На этом все. В следующем уроке мы будем больше работать с историей коммитов и посмотрим различные варианты использования команды git log
Спасибо за внимание и до встречи!
Следующий урок ⇨
Урок 5. История коммитов в подробностях. Путешествие по истории
⇦ Предыдущий урок
Урок 3. Первые изменения, git status и git diff
EXAMPLES
-
Extract commits between revisions R1 and R2, and apply them on top of
the current branch using git am to cherry-pick them:$ git format-patch -k --stdout R1..R2 | git am -3 -k
-
Extract all commits which are in the current branch but not in the
origin branch:$ git format-patch origin
For each commit a separate file is created in the current directory.
-
Extract all commits that lead to origin since the inception of the
project:$ git format-patch --root origin
-
The same as the previous one:
$ git format-patch -M -B origin
Additionally, it detects and handles renames and complete rewrites
intelligently to produce a renaming patch. A renaming patch reduces
the amount of text output, and generally makes it easier to review.
Note that non-git «patch» programs won’t understand renaming patches, so
use it only when you know the recipient uses git to apply your patch. -
$ git format-patch -3
Что такое git? Основные понятия
Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux.
Системы управления версиями (Version Control Systems) – это программное обеспечение, призванное автоматизировать работу с историей файла (или группы файлов), обеспечить мониторинг изменений, синхронизацию данных и организовать защищенное хранилище проекта. Короче говоря, основная задача систем управления версиями – упростить работу с изменяющейся информацией.
Распределённые системы управления версиями – это СУВ, главной парадигмой которых является локализация данных каждого разработчика проекта. Иными словами, если в централизованных СУВ все действия, так или иначе, зависят от центрального объекта (сервер), то в распределенных СУВ каждый разработчик хранит собственную ветвь версий всего проекта. Удобство такой системы в том, что каждый разработчик имеет возможность вести работу независимо, время от времени обмениваясь промежуточными вариантами файлов с другими участниками проекта.
Рассмотрим пример:
У каждого разработчика на машине есть свой локальный репозиторий – место хранения версий файлов. Работа с данными проекта реализуется над вашим локальным репозиторием, и для этого необязательно поддерживать связь с остальными (пусть даже и главными) ветвями разработки. Связь с другими репозиториями понадобится лишь при изменении/чтении версий файлов других ветвей. При этом каждый участник проекта задает права собственного хранилища на чтение и запись. Таким образом, все ветви в распределенных СУВ равны между собой, и главную из них выделяет координатор. Отличие главной ветви лишь в том, что на неё мысленно будут равняться разработчики.
Запись изменений в репозиторий (commit)
Допустим, у вас имеется репозиторий Git и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать состояния этих изменений (commit) в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (не отслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем слепке состояния проекта; они могут быть не измененными, измененными или подготовленными к коммиту (staged). Все изменения в них, будут отслеживаться. Не отслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний слепок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемые и не измененные, потому что вы только взяли их из хранилища и ничего пока не редактировали.
Как только вы отредактируете файлы, Git будет рассматривать их как измененные, т.к. вы изменили их с момента последнего коммита. Вы индексируете (stage) эти изменения и затем фиксируете (делаете коммит) все индексированные изменения.
Что такое ветка?
Ветка (или «branch») — это своеобразное «место» разработки. Например, после клонирования репозитория мы по-умолчанию находимся в ветке master, создаём ветку test (в которую будет всё слито из master), затем делаем в ней какие-то изменения, делаем коммит, а потом переключиться обратно в ветку master. С помощью команды
$ git log
в каждой из веток, можно будет посмотреть все коммиты. В ветке master вы увидите, что ваш коммит из test на ветку не распространяется, и те файлы, которые вы изменили в ветке test будут возвращены к состоянию последнего коммита в ветке master. Таким образом ветка — это что-то вроде текущего состояния вашей разработки.
Основы работы с удаленным репозиторием¶
git clone — создание копии (удаленного) репозитория
Для начала работы с центральным репозиторием, следует создать копию оригинального проекта со всей его историей локально.
Клонируем репозиторий, используя протокол http:
git clone http://user@somehost:port/~user/repository/project.git
Клонируем репозиторий с той же машины в директорию :
git clone /home/username/project myrepo
Клонируем репозиторий, используя безопасный протокол ssh:
git clone ssh://user@somehost:port/~user/repository
У git имеется и собственный протокол:
git clone git://user@somehost:port/~user/repository/project.git/
Импортируем svn репозиторий, используя протокол http:
git svn clone -s http://repo/location
-s
git fetch и git pull — забираем изменения из центрального репозитория
Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.
git fetch — забрать изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.
git fetch /home/username/project — забрать изменения из определенного репозитория.
Возможно также использовать синонимы для адресов, создаваемые командой :
git remote add username-project /home/username/project
git fetch username-project — забрать изменения по адресу, определяемому синонимом.
Естественно, что после оценки изменений, например, командой , надо создать коммит слияния с основной:
git merge username-project/master
Команда сразу забирает изменения и проводит слияние с активной веткой.
Забрать из репозитория, для которого были созданы удаленные ветки по умолчанию:
git pull
Забрать изменения и метки из определенного репозитория:
git pull username-project --tags
Как правило, используется сразу команда .
git push — вносим изменения в удаленный репозиторий
После проведения работы в экспериментальной ветке, слияния с основной, необходимо обновить удаленный репозиторий (удаленную ветку). Для этого используется команда git push.
Отправить свои изменения в удаленную ветку, созданную при клонировании по умолчанию:
git push
Отправить изменения из ветки master в ветку experimental удаленного репозитория:
git push ssh://yourserver.com/~you/proj.git master:experimental
В удаленном репозитории origin удалить ветку experimental:
git push origin :experimental
В удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:
git push origin master:master
Отправить метки в удаленную ветку master репозитория origin:
git push origin master --tags
Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)
git push origin origin/develop:master
Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:
git push origin origin/develop:refs/heads/test
Сложный вариант: починить за кем-то
Иногда бывает, что сделали либо не вы, либо кто-то принял пачку Pull Request’ов в то время, пока вы веселились со своими экспериментами.
Тяжесть ситуации в том, что вы не можете просто сделать , поскольку у вас локально нет коммитов, которые нужно восстановить (и у вас не получиться скачать их с помощью ).
Стоп! Без паники! Зайдите в чат, покайтесь, скажите, чтобы никто ничего не делал — вам понадобится время, чтобы всё вернуть.
Здесь нам поможет тот факт, что GitHub не удаляет коммиты, которые больше не принадлежат ни к какой ветке. Но, что усложняет задачу, не даёт их и стянуть с командной строки.
Если force-пуш сделали вы, то просто возьмите хэш коммита, который был в ветке до вас (как и в прошлом пункте). Если не вы, то можно зайти в ленту событий GitHub’а (на главной странице, в случае, если вы подписаны на репозиторий) и посмотреть, кто последний коммитил в эту ветку:
Теперь через консоль можно получить недостающие коммиты:
$ git fetch From github.com:org/repo * master-before-force-push -> origin/master-before-force-push
и теперь задача сводится к предыдущей:
Если наработки в вашем е ещё нужны, то лучше отребейзить свои коммиты поверх него:
