Клонировать конкретный коммит

Конкретный комьютер перестал видеть конкретный жесткий диск
Помогите пожалуйста мыслью. Ступор какой-то. Win7 отлично настроен все летает. Было.

Удалить коммит-дубликат
Так получилось, что запушил два одинаковых коммита. Как удалить один из них(более старый)?
Как отменить коммит
1) сделал git init добавил файл f.txt с содержимым: line 1 commit 1 выполнил: git add . git.
Что такое коммит?
Что такое коммит в данном контексте: ~~~~~~~~~~~~~~~~~~~~~ 10 000 коммитов в проект Open Source.

10142 / 6129 / 1442
Регистрация: 25.05.2015
Сообщений: 18,587
Записей в блоге: 14
См. — — depth
https://git-scm.com/docs/git-c. hltdepthgt
87844 / 49110 / 22898
Регистрация: 17.06.2006
Сообщений: 92,604
Помогаю со студенческими работами здесь
Удалить коммит из середины истории
Как я могу удалить не последний а нужный мне промежуточный коммит из истории? Добавлено через 3.
Как удалить коммит из Bitbecket?
Вроде не в тот раздел пишу, но раздела по git нет. Как удалить коммит из bitbucket, удалить.
Переход на предыдущий коммит SourceTree
Я выбираю предыдущий коммит в SourceTree и нажимаю правой кнопкой мыши и дальше в меню выбираю.
Постоянно прерывается коммит (git)
есть скрипт https://gist.github.com/davetron5000/37350 это хук для git. Подключается jar и ему.
Подкорректировать нужный коммит в истории
Допустим в середине истории у меня есть какой то коммит и я хочу добавить в него или изменить в нем.
Как первый коммит сделать из PhpStorm 9.0 ?
Привет всем. В PhpStorm 9.0 создал новый пустой проект Проверил, все плагины для git.
3.2 Ветвление в Git — Основы ветвления и слияния
Давайте рассмотрим простой пример рабочего процесса, который может быть полезен в вашем проекте. Ваша работа построена так:
- Вы работаете над сайтом.
- Вы создаете ветку для реализации новой функциональности в соответствии с пользовательской историей.
- Вы работаете в этой ветке.
В этот момент вы получаете сообщение, что обнаружена критическая ошибка, требующая скорейшего исправления. Ваши действия:
- Переключиться на основную ветку.
- Создать ветку для добавления исправления.
- После тестирования слить ветку, содержащую исправление, с основной веткой.
- Переключиться назад в ветку для реализации пользовательской истории и продолжить работать.
Основы ветвления
Предположим, вы работаете над проектом и уже имеете несколько коммитов.

Рисунок 18. Простая история коммитов
Вы выбрали задачу #53 из какая-там-у-вас-система-отслеживания-задач. Чтобы создать ветку и сразу переключиться на неё, можно выполнить команду git checkout с параметром -b :
$ git checkout -b iss53 Switched to a new branch "iss53"
Это то же самое, что и:
$ git branch iss53 $ git checkout iss53

Рисунок 19. Создание нового указателя ветки
Вы работаете над сайтом и делаете коммиты. Это приводит к тому, что ветка iss53 движется вперед, так как вы переключились на неё ранее ( HEAD указывает на неё).
$ vim index.html $ git commit -a -m 'Create new footer [issue 53]'

Рисунок 20. Ветка iss53 движется вперед
И тут вы получаете сообщение об обнаружении на сайте уязвимости, и эту уязвимость устранить нужно немедленно. Благодаря Git вам не придётся ни пытаться реализовать исправление вместе с изменениями, которые вы сделали в ходе разработки iss53 , ни прилагать усилия для отката этих изменений и возвращения к исходному состоянию перед началом разработки исправления. Все, что вам нужно — переключиться на ветку master .
Имейте в виду, что если рабочий каталог или индекс содержат незафиксированные изменения, конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит переключить ветки. Лучше всего переключаться из чистого рабочего состояния проекта: все изменённые файлы добавить в индекс и сделать коммит. Есть способы обойти это (припрятать изменения (stash) или добавить их в последний коммит (amend)), но об этом мы поговорим позже в разделе Припрятывание и очистка главы 7. Теперь предположим, что вы зафиксировали все свои изменения и можете переключиться на ветку master :
$ git checkout master Switched to branch 'master'
С этого момента ваш рабочий каталог имеет точно такой же вид, какой был перед началом работы над задачей #53, и вы можете сосредоточиться на работе над исправлением. Важно запомнить: когда вы переключаете ветки, Git возвращает состояние рабочего каталога к тому виду, какой он имел в момент последнего коммита в переключаемую ветку. Он добавляет, удаляет и изменяет файлы автоматически, чтобы состояние рабочего каталога соответствовало тому, когда был сделан последний коммит.
Теперь вы можете перейти к написанию исправления. Давайте создадим новую ветку, в которой реализуем исправление.
$ git checkout -b hotfix Switched to a new branch 'hotfix' $ vim index.html $ git commit -a -m 'Fix broken email address' [hotfix 1fb7853] Fix broken email address 1 file changed, 2 insertions(+)

Рисунок 21. Ветка hotfix основана на ветке master
Вы можете прогнать тесты, чтобы убедиться, что ваше уязвимость в самом деле исправлена. И если это так — выполнить слияние ветки hotfix с веткой master для включения изменений в продукт. Это делается командой git merge :
$ git checkout master $ git merge hotfix Updating f42c576..3a0874c Fast-forward index.html | 2 ++ 1 file changed, 2 insertions(+)
Заметили фразу «fast-forward» в этом слиянии? Git просто переместил указатель ветки вперед, потому что коммит C4 , на который указывает слитая ветка hotfix , был прямым потомком коммита C2 , на котором вы находились до этого. Другими словами, если коммит сливается с тем, до которого можно добраться, двигаясь по истории вперёд, Git упрощает слияние, просто перенося указатель ветки вперед, потому что в этом случае нет никаких разнонаправленных изменений, которые нужно было бы свести воедино. Это называется «fast-forward».
Теперь ваши изменения включены в коммит, на который указывает ветка master , и исправление можно внедрять.

Рисунок 22. master перемотан до hotfix
После внедрения вашего архиважного исправления вы готовы вернуться к работе над тем, что были вынуждены отложить. Но сначала нужно удалить ветку hotfix , потому что она больше не нужна — ветка master указывает на то же самое место. Для удаления ветки выполните команду git branch с параметром -d :
$ git branch -d hotfix Deleted branch hotfix (3a0874c).
Теперь вы можете переключиться обратно на ветку iss53 и продолжить работу над задачей #53:
$ git checkout iss53 Switched to branch "iss53" $ vim index.html $ git commit -a -m 'Finish the new footer [issue 53]' [iss53 ad82d7a] Finish the new footer [issue 53] 1 file changed, 1 insertion(+)

Рисунок 23. Продолжение работы над iss53
Стоит обратить внимание на то, что все изменения из ветки hotfix не включены в вашу ветку iss53 . Если их нужно включить, вы можете влить ветку master в вашу ветку iss53 командой git merge master , а можете отложить слияние этих изменений до завершения работы, и затем влить ветку iss53 в master .
Основы слияния
Предположим, вы решили, что работа по проблеме #53 закончена и её можно влить в ветку master . Для этого нужно выполнить слияние ветки iss53 точно так же, как вы делали это с веткой hotfix ранее. Все, что нужно сделать — переключиться на ветку, в которую вы хотите включить изменения, и выполнить команду git merge :
$ git checkout master Switched to branch 'master' $ git merge iss53 Merge made by the 'recursive' strategy. index.html | 1 + 1 file changed, 1 insertion(+)
Результат этой операции отличается от результата слияния ветки hotfix . В данном случае процесс разработки ответвился в более ранней точке. Так как коммит, на котором мы находимся, не является прямым родителем ветки, с которой мы выполняем слияние, Git придётся немного потрудиться. В этом случае Git выполняет простое трёхстороннее слияние, используя последние коммиты объединяемых веток и общего для них родительского коммита.

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

Рисунок 25. Коммит слияния
Теперь, когда изменения слиты, ветка iss53 больше не нужна. Вы можете закрыть задачу в системе отслеживания ошибок и удалить ветку:
$ git branch -d iss53
Основные конфликты слияния
Иногда процесс не проходит гладко. Если вы изменили одну и ту же часть одного и того же файла по-разному в двух объединяемых ветках, Git не сможет их чисто объединить. Если ваше исправление ошибки #53 потребовало изменить ту же часть файла что и hotfix , вы получите примерно такое сообщение о конфликте слияния:
$ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.
Git не создал коммит слияния автоматически. Он остановил процесс до тех пор, пока вы не разрешите конфликт. Чтобы в любой момент после появления конфликта увидеть, какие файлы не объединены, вы можете запустить git status :
$ git status On branch master You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: (use "git add . " to mark resolution) both modified: index.html no changes added to commit (use "git add" and/or "git commit -a")
Всё, где есть неразрешённые конфликты слияния, перечисляется как неслитое. В конфликтующие файлы Git добавляет специальные маркеры конфликтов, чтобы вы могли исправить их вручную. В вашем файле появился раздел, выглядящий примерно так:
contact : email.support@github.com
======= please contact us at support@github.com
>>>>>>> iss53:index.html
Это означает, что версия из HEAD (вашей ветки master , поскольку именно её вы извлекли перед запуском команды слияния) — это верхняя часть блока (всё, что над ======= ), а версия из вашей ветки iss53 представлена в нижней части. Чтобы разрешить конфликт, придётся выбрать один из вариантов, либо объединить содержимое по-своему. Например, вы можете разрешить конфликт, заменив весь блок следующим:
please contact us at email.support@github.com
В этом разрешении есть немного от каждой части, а строки >>>>>> полностью удалены. Разрешив каждый конфликт во всех файлах, запустите git add для каждого файла, чтобы отметить конфликт как решённый. Добавление файла в индекс означает для Git, что все конфликты в нём исправлены.
Если вы хотите использовать графический инструмент для разрешения конфликтов, можно запустить git mergetool , который проведет вас по всем конфликтам:
$ git mergetool This message is displayed because 'merge.tool' is not configured. See 'git mergetool --tool-help' or 'git help config' for more details. 'git mergetool' will now attempt to use one of the following tools: opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge Merging: index.html Normal merge conflict for 'index.html': : modified file : modified file Hit return to start merge resolution tool (opendiff):
Если вы хотите использовать инструмент слияния не по умолчанию (в данном случае Git выбрал opendiff , поскольку команда запускалась на Mac), список всех поддерживаемых инструментов представлен вверху после фразы «one of the following tools». Просто введите название инструмента, который хотите использовать.
Примечание
Мы рассмотрим более продвинутые инструменты для разрешения сложных конфликтов слияния в разделе Продвинутое слияние главы 7.
После выхода из инструмента слияния Git спросит об успешности процесса. Если вы ответите скрипту утвердительно, то он добавит файл в индекс, чтобы отметить его как разрешённый. Теперь можно снова запустить git status , чтобы убедиться в отсутствии конфликтов:
$ git status On branch master All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified: index.html
Если это вас устраивает и вы убедились, что все файлы, где были конфликты, добавлены в индекс — выполните команду git commit для создания коммита слияния. Комментарий к коммиту слияния по умолчанию выглядит примерно так:
Merge branch 'iss53' Conflicts: index.html # # It looks like you may be committing a merge. # If this is not correct, please remove the file # .git/MERGE_HEAD # and try again. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # All conflicts fixed but you are still merging. # # Changes to be committed: # modified: index.html #
Если вы считаете, что коммит слияния требует дополнительных пояснений — опишите как были разрешены конфликты и почему были применены именно такие изменения, если это не очевидно.
Клонировать репозиторий git с определенной версией
В этом посте мы обсудим, как клонировать репозиторий git с определенной версией.
1. git выборка
Чтобы клонировать определенную версию репозитория Git, лучше избегать git-clone так как git-clone клонирует полный репозиторий. Рекомендуемое решение — получить конкретную ветку, которую вы хотите клонировать. git-fetch . Вот полные шаги:
# create and initialize an empty repository
git init
# add a remote named origin for the repository at
git remote add origin
# fetch a commit using its hash
git fetch origin
# reset repository to that commit
git reset —hard FETCH_HEAD
Этот подход демонстрируется ниже:

2. гит-клон
Для небольших репозиториев можно использовать git-clone чтобы легко сбросить репозиторий на любую конкретную фиксацию с помощью git-reset, как показано ниже:
# clone the git repository into the current directory
git clone .
# hard reset repository to a specific commit
git reset —hard
Это предполагает, что вы находитесь в основной ветке. Чтобы снова вернуться к самой последней фиксации, вы можете просто сделать git-pull . Это показано ниже:

В качестве альтернативы вы можете выполнить git-clone а затем проверьте конкретную версию с помощью git-checkout .
# clone the git repository into the current directory
git clone .
# checkout a commit using its hash
git checkout
# hard reset repository
git reset —hard
Этот подход демонстрируется ниже:

Вот и все, что касается клонирования репозитория Git с определенной версией.
Оценить этот пост
Средний рейтинг 4.84 /5. Подсчет голосов: 25
Голосов пока нет! Будьте первым, кто оценит этот пост.
Сожалеем, что этот пост не оказался для вас полезным!
Расскажите, как мы можем улучшить этот пост?
Спасибо за чтение.
Пожалуйста, используйте наш онлайн-компилятор размещать код в комментариях, используя C, C++, Java, Python, JavaScript, C#, PHP и многие другие популярные языки программирования.
Как мы? Порекомендуйте нас своим друзьям и помогите нам расти. Удачного кодирования 🙂
Подписывайся
1 Комментарий
Большинство голосов
Новейшие Самый старый
Встроенные отзывы
Просмотреть все комментарии
Просмотр комментариев
Загрузить больше комментариев
Просматривать
Подпишитесь на новые публикации
- Все проблемы
- Практика DSA
- 100 самых популярных задач
- 50 лучших классических задач
- Лучшие алгоритмы
- Компилятор С/С++
- Компилятор Java
- Компилятор Python
- Компилятор JavaScript
- компилятор PHP
- Компилятор C#
- Свяжитесь с нами
- Политика конфиденциальности
- условия обслуживания
- Подпишитесь на новые публикации
Techie Delight © 2023 Все права защищены.
Этот веб-сайт использует файлы cookie. Используя этот сайт, вы соглашаетесь с использованием файлов cookie, нашей политикой, условиями авторского права и другими условиями. Читайте наши Политика конфиденциальности. Понятно
2.6 Основы Git — Работа с тегами
Как и большинство других систем контроля версий, Git имеет возможность помечать определённые моменты в истории как важные. Как правило, эта функциональность используется для отметки моментов выпуска версий (v1.0, и т. п.). Такие пометки в Git называются тегами. В этом разделе вы узнаете, как посмотреть имеющиеся теги, как создать новые или удалить существующие, а также какие типы тегов существуют в Git.
Просмотр списка тегов
Просмотреть список имеющихся тегов в Git можно очень просто. Достаточно набрать команду git tag (параметры -l и —list опциональны):
$ git tag v1.0 v2.0
Данная команда перечисляет теги в алфавитном порядке; порядок их отображения не имеет существенного значения.
Так же можно выполнить поиск тега по шаблону. Например, репозиторий Git содержит более 500 тегов. Если вы хотите посмотреть теги выпусков 1.8.5, то выполните следующую команду:
$ git tag -l "v1.8.5*" v1.8.5 v1.8.5-rc0 v1.8.5-rc1 v1.8.5-rc2 v1.8.5-rc3 v1.8.5.1 v1.8.5.2 v1.8.5.3 v1.8.5.4 v1.8.5.5
Примечание
Для отображение тегов согласно шаблону требуются параметры -l или —list
Если вы хотите посмотреть весь список тегов, запуск команды git tag неявно подразумевает это и выводит полный список; использование параметров -l или —list в этом случае опционально.
Если вы хотите отфильтровать список тегов согласно шаблону, использование параметров -l или —list становится обязательным.
Создание тегов
Git использует два основных типа тегов: легковесные и аннотированные.
Легковесный тег — это что-то очень похожее на ветку, которая не изменяется — просто указатель на определённый коммит.
А вот аннотированные теги хранятся в базе данных Git как полноценные объекты. Они имеют контрольную сумму, содержат имя автора, его e-mail и дату создания, имеют комментарий и могут быть подписаны и проверены с помощью GNU Privacy Guard (GPG). Обычно рекомендуется создавать аннотированные теги, чтобы иметь всю перечисленную информацию; но если вы хотите сделать временную метку или по какой-то причине не хотите сохранять остальную информацию, то для этого годятся и легковесные.
Аннотированные теги
Создание аннотированного тега в Git выполняется легко. Самый простой способ — это указать -a при выполнении команды tag :
$ git tag -a v1.4 -m "my version 1.4" $ git tag v0.1 v1.3 v1.4
Опция -m задаёт сообщение, которое будет храниться вместе с тегом. Если не указать сообщение, то Git запустит редактор, чтобы вы смогли его ввести.
С помощью команды git show вы можете посмотреть данные тега вместе с коммитом:
$ git show v1.4 tag v1.4 Tagger: Ben Straub Date: Sat May 3 20:19:12 2014 -0700 my version 1.4 commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon Date: Mon Mar 17 21:52:11 2008 -0700 Change version number
Здесь приведена информация об авторе тега, дате его создания и аннотирующее сообщение перед информацией о коммите.
Легковесные теги
Легковесный тег — это ещё один способ пометить коммит. По сути, это контрольная сумма коммита, сохранённая в файл — больше никакой информации не хранится. Для создания легковесного тега не передавайте опций -a , -s и -m , укажите только название:
$ git tag v1.4-lw $ git tag v0.1 v1.3 v1.4 v1.4-lw v1.5
На этот раз при выполнении git show для этого тега вы не увидите дополнительной информации. Команда просто покажет коммит:
$ git show v1.4-lw commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon Date: Mon Mar 17 21:52:11 2008 -0700 Change version number
Отложенная расстановка тегов
Также возможно помечать уже пройденные коммиты. Предположим, история коммитов выглядит следующим образом:
$ git log --pretty=oneline 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment' a6b4c97498bd301d84096da251c98a07c7723e65 Create write support 0d52aaab4479697da7686c15f77a3d64d9165190 One more thing 6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment' 0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc Add commit function 4682c3261057305bdd616e23b64b0857d832627b Add todo file 166ae0c4d3f420721acbb115cc33848dfcc2121a Create write support 9fceb02d0ae598e95dc970b74767f19372d61af8 Update rakefile 964f16d36dfccde844893cac5b347e7b3d44abbc Commit the todo 8a5cbc430f1a9c3d00faaeffd07798508422908a Update readme
Теперь предположим, что вы забыли отметить версию проекта v1.2, которая была там, где находится коммит «Update rakefile». Вы можете добавить тег и позже. Для отметки коммита укажите его контрольную сумму (или её часть) как параметр команды:
$ git tag -a v1.2 9fceb02
Проверим, что коммит отмечен:
$ git tag v0.1 v1.2 v1.3 v1.4 v1.4-lw v1.5 $ git show v1.2 tag v1.2 Tagger: Scott Chacon Date: Mon Feb 9 15:32:16 2009 -0800 version 1.2 commit 9fceb02d0ae598e95dc970b74767f19372d61af8 Author: Magnus Chacon Date: Sun Apr 27 20:43:35 2008 -0700 Update rakefile .
Обмен тегами
По умолчанию, команда git push не отправляет теги на удалённые сервера. После создания теги нужно отправлять явно на удалённый сервер. Процесс аналогичен отправке веток — достаточно выполнить команду git push origin .
$ git push origin v1.5 Counting objects: 14, done. Delta compression using up to 8 threads. Compressing objects: 100% (12/12), done. Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done. Total 14 (delta 3), reused 0 (delta 0) To git@github.com:schacon/simplegit.git * [new tag] v1.5 -> v1.5
Если у вас много тегов, и вам хотелось бы отправить все за один раз, то можно использовать опцию —tags для команды git push . В таком случае все ваши теги отправятся на удалённый сервер (если только их уже там нет).
$ git push origin --tags Counting objects: 1, done. Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done. Total 1 (delta 0), reused 0 (delta 0) To git@github.com:schacon/simplegit.git * [new tag] v1.4 -> v1.4 * [new tag] v1.4-lw -> v1.4-lw
Теперь, если кто-то клонирует (clone) или выполнит git pull из вашего репозитория, то он получит вдобавок к остальному и ваши метки.
Примечание
git push отправляет оба типа тегов
Отправка тегов командой git push —tags не различает аннотированные и легковесные теги. В настоящее время не существует опции чтобы отправить только лёгковесные теги, но если использовать команду git push —follow-tags , то отправятся только аннотированные теги.
Удаление тегов
Для удаления тега в локальном репозитории достаточно выполнить команду git tag -d . Например, удалить созданный ранее легковесный тег можно следующим образом:
$ git tag -d v1.4-lw Deleted tag 'v1.4-lw' (was e7d5add)
Обратите внимание, что при удалении тега не происходит его удаления с внешних серверов. Существует два способа изъятия тега из внешнего репозитория.
Первый способ — это выполнить команду git push :refs/tags/ :
$ git push origin :refs/tags/v1.4-lw To /git@github.com:schacon/simplegit.git - [deleted] v1.4-lw
Это следует понимать как обновление внешнего тега пустым значением, что приводит к его удалению.
Второй способ убрать тег из внешнего репозитория более интуитивный:
$ git push origin --delete
Переход на тег
Если вы хотите получить версии файлов, на которые указывает тег, то вы можете сделать git checkout для тега. Однако, это переведёт репозиторий в состояние «detached HEAD», которое имеет ряд неприятных побочных эффектов.
$ git checkout v2.0.0 Note: switching to 'v2.0.0'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c Or undo this operation with: git switch - Turn off this advice by setting config variable advice.detachedHead to false HEAD is now at 99ada87. Merge pull request #89 from schacon/appendix-final $ git checkout v2.0-beta-0.1 Previous HEAD position was 99ada87. Merge pull request #89 from schacon/appendix-final HEAD is now at df3f601. Add atlas.json and cover image
Если в состоянии «detached HEAD» внести изменения и сделать коммит, то тег не изменится, при этом новый коммит не будет относиться ни к какой из веток, а доступ к нему можно будет получить только по его хешу. Поэтому, если вам нужно внести изменения — исправить ошибку в одной из старых версий — скорее всего вам следует создать ветку:
$ git checkout -b version2 v2.0.0 Switched to a new branch 'version2'
Если сделать коммит в ветке version2 , то она сдвинется вперед и будет отличаться от тега v2.0.0 , так что будьте с этим осторожны.