└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # Базовые операции с Git 2 | Тут рассмотрено несколько типичных операций, которые нужно уметь делать с Гитом. Перед прочтением лучше ознакомиться с ссылками в [предыдущей статье на девмане](https://devman.org/encyclopedia/git/git_motivation/): пройти [туториал гитхабе](https://try.github.io/) и прочитать пару глав [Git-book'a](https://git-scm.com/book/ru/v1). 3 | 4 | # Задачи 5 | ### Подтянуть чужие изменения 6 | >Утро, ты пришёл на работу. Как к локальной версии исходного кода добавить те изменения, 7 | которые коллеги сделали вчера? 8 | 9 | Для работы с удалёнными репозиториями используем [fetch, merge и pull](https://git-scm.com/book/ru/v1/Основы-Git-Работа-с-удалёнными-репозиториями): 10 | `$ git fetch server_branch` \# изъять данные из другой ветки 11 | `$ git merge server_branch` \# слить другую ветку в текущую рабочую 12 | 13 | или 14 | 15 | `$ git pull server_branch master` \# два действия одной командой 16 | 17 | Вопросы по команде `$ git merge` должны отпасть после прочтения [третьей главы Git-book'a](https://git-scm.com/book/ru/v2/%D0%92%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B2-Git-%D0%9E-%D0%B2%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B8-%D0%B2-%D0%B4%D0%B2%D1%83%D1%85-%D1%81%D0%BB%D0%BE%D0%B2%D0%B0%D1%85). 18 | 19 | -------------------------------------------------- 20 | ### Поделиться своими изменениями с коллегами 21 | >Ну вот, ты поработал. Теперь нужно поделиться своим кодом с другими. Как? 22 | 23 | Используем [git push](https://git-scm.com/book/ru/v1/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git-%D0%A0%D0%B0%D0%B1%D0%BE%D1%82%D0%B0-%D1%81-%D1%83%D0%B4%D0%B0%D0%BB%D1%91%D0%BD%D0%BD%D1%8B%D0%BC%D0%B8-%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F%D0%BC%D0%B8#Push): 24 | `$ git push origin master` 25 | 26 | Также важно понимать, почему нежелательно делать [push с форсом](https://developer.atlassian.com/blog/2015/04/force-with-lease/)! 27 | 28 | -------------------------------------------------- 29 | ### Разобраться с конфликтами 30 | >При попытке отправить свои изменения на сервер ты узнал, что твой коллега изменял тот же файл, что и ты, теперь непонятно, какая версия правильная. Как быть? 31 | 32 | Чтобы посмотреть разницу состояния файла при разных коммитах используют команду `$ git diff`. 33 | О том, как ей пользоваться можно прочесть на [СтекОверфловиче](http://stackoverflow.com/questions/3338126/how-to-diff-the-same-file-between-two-different-commits-on-the-same-branch). 34 | А если непонятно чей код оставлять: твой или коллеги, то уже выяснить это напрямую с ним. 35 | 36 | В PyCharm можно выполнять данные операции удобнее и нагляднее чем в консоли. [Ссылка на документацию](https://www.jetbrains.com/help/pycharm/2016.1/using-git-integration.html) 37 | 38 | -------------------------------------------------- 39 | ### Отпочковать ветку 40 | >Тимлид дал тебе задачу. Объяснение он закончил фразой "делай в фичабранче". Когда ты спросил, что это значит, он промямлил что-то про гитфлоу. Что делать-то? 41 | 42 | `$ git branch feature_branch` # создание новой ветки 43 | `$ git checkout feature_branch` # переход в новую ветку 44 | 45 | или 46 | 47 | `$ git checkout -b feature_branch` # два действия одной командой 48 | 49 | Графические иллюстрации веток для понимания происходящего можно найти всё в том же [Git-book](https://git-scm.com/book/ru/v2/%D0%92%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B2-Git-%D0%9E-%D0%B2%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B8-%D0%B2-%D0%B4%D0%B2%D1%83%D1%85-%D1%81%D0%BB%D0%BE%D0%B2%D0%B0%D1%85). 50 | 51 | -------------------------------------------------- 52 | ### Слить свои изменения 53 | >Задачу ты закончил, теперь ты получил указание "замерджить свой бранч в дев". Что это за дичь? Как делать? 54 | 55 | Всё та же третья глава и уже, должно быть, знакомые команды: 56 | `$ git checkout dev_branch` # переключаемся на ветку dev 57 | `$ git merge my_work_branch` # мерджим ветку my_work_branch 58 | 59 | -------------------------------------------------- 60 | ### Добавить в одну ветку изменения из другой 61 | >Следующую задачу ты делаешь так же, в отдельной ветке от дева. Правда, долго: уже неделя прошла, а задача не готова. Лид даёт указание "подлить изменения из дева в свой бранч". Шта? 62 | 63 | `$ git merge dev` # выполняем команду слияния ветки dev с my_branch, находясь в векте my_branch 64 | 65 | -------------------------------------------------- 66 | ### Перенести коммит 67 | >Ты сделал задачу, но ошибся с веткой, в которую коммитить: вместо дева сделал коммит в мастер. Хорошо, что не запушил. Теперь надо этот коммит перенести в дев. Как это сделать? 68 | 69 | Используем [git cherry-pick](https://git-scm.com/docs/git-cherry-pick) и [git reset](https://githowto.com/ru/removing_commits_from_a_branch): 70 | `$ git cherry-pick 62ecb3` # выполним команду, находясь в ветке dev. Данная команда заберёт все коммиты ветки в другую одним коммитом, в нашем случае из ветки dev в ветку master. `62ecb3` - хэш ошибочного коммита. 71 | `$ git сommit -m "Commit message` # сделать коммит уже в своей ветке 72 | `$ git checkout master` # переходим в master 73 | `$ git reset --hard HEAD` # удаление ошибочного коммита вместе с индексированными файлами. Подробнее о данной команде в следующем пункте. 74 | 75 | 76 | -------------------------------------------------- 77 | ### Откатить коммит 78 | >Работаешь над фронтом в своей ветке и, вдруг, понимаешь, что сильно ошибся уже как два коммита назад... Как откатиться? 79 | 80 | Предположим, вот два последних коммита: 81 | `$ git commit -m "Change header style with a mistake"` 82 | `$ git commit -m "Change header style with a critical mistake"` 83 | 84 | Надо вернуться к состоянию репозитория на третий коммит, где нет той самой ошибки. Чтобы было проще дальше объяснять, обзовём это состояние репозитория "C" (от слова correct). 85 | 86 | Первый способ, используем reset: 87 | `$ git reset --hard HEAD~2` # все файлы изменятся на состояние репозитория "C", а индексированные файлы двух ошибочных коммитов будут удалены. 88 | 89 | Выглядеть это будет как на картинке из [одного стоящего прочтения параграфа GitBook'a](https://git-scm.com/book/ru/v2/%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B-Git-%D0%A0%D0%B0%D1%81%D0%BA%D1%80%D1%8B%D1%82%D0%B8%D0%B5-%D1%82%D0%B0%D0%B9%D0%BD-reset), только здесь рассматривается переход на один коммит назад, а не на два: 90 | ![alt-text](https://git-scm.com/book/en/v2/book/07-git-tools/images/reset-hard.png) 91 | 92 | Если ошибка совсем критична, то нет смысла оставлять каталог индексированным. Но, если нет, то мы могли бы воспользоваться `$ git reset --soft HEAD~2`. В таком случае произойдет отмена двух последних коммитов и все индексированные файлы станут "unstaged". Сами файлы не изменятся и будут соответствовать последнему состоянию репозитория с ошибкой, поэтому придётся их исправить, чтобы вести дальнейшую работу с кодом. Также можно использовать `$ git commit -c ORIG_HEAD`, чтобы не писать сообщение коммита заново. 93 | 94 | Выглядеть это будет так: 95 | ![alt-text](https://git-scm.com/book/en/v2/book/07-git-tools/images/reset-soft.png) 96 | 97 | Подытожим, фрагментом из данного параграфа. Команда reset: 98 | 99 | 1. Перемещает ветку, на которую указывает HEAD (останавливается на этом, если указана опция --soft) 100 | 101 | 2. Делает Индекс таким же как и HEAD (останавливается на этом, если не указана опция --hard) 102 | 103 | 3. Делает Рабочий Каталог таким же как и Индекс. 104 | 105 | Второй способ, используем [revert](https://githowto.com/ru/undoing_committed_changes): 106 | `$ git commit revert HEAD~2` # всё тоже самое, но безопаснее: команда создаёт новый коммит c состоянием репозитория "C", не удаляя предыдущие коммиты и не трогая индексированные файлы. 107 | 108 | ![alttext](https://www.git-tower.com/learn/content/01-git/04-faq/04-undo-revert-old-commit/01-revert-concept.png) 109 | 110 | Иллюстрированное резюме: 111 | 112 | ![alttext](http://image.slidesharecdn.com/gittutorial-150724014321-lva1-app6891/95/git-tutorial-19-638.jpg?cb=1437702443) 113 | 114 | 115 | -------------------------------------------------- 116 | ### Удалить коммиты, которые были запушены на удалённый сервер 117 | >Как же мне теперь удалить пять коммитов с сообщением "финальная версия 3" из ветки на github? 118 | 119 | Используем [git rebase](https://git-scm.com/book/ru/v1/%D0%92%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B2-Git-%D0%9F%D0%B5%D1%80%D0%B5%D0%BC%D0%B5%D1%89%D0%B5%D0%BD%D0%B8%D0%B5): 120 | `$ git rebase -i origin/master~4 master` 121 | `$ git push origin +master` 122 | 123 | Плюс - это почти --force и использовать его надо крайне осторожно! На [СтекОверфловиче](http://stackoverflow.com/questions/8981194/changing-git-commit-message-after-push-given-that-no-one-pulled-from-remote) подробнее говорится про данную команду. 124 | 125 | -------------------------------------------------- 126 | ### Добавить изменение в сделанный коммит или переименовать его 127 | >Исправил ридми, но забыл поставить запятую... 128 | 129 | Используем [git commit --amend](https://git-scm.com/book/ru/v1/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git-%D0%9E%D1%82%D0%BC%D0%B5%D0%BD%D0%B0-%D0%B8%D0%B7%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D0%B9): 130 | `$ git commit -m "Add description"` # сделали коммит 131 | `$ git add README.md` # вспомнили про запятую, отредактировали и добавили заново файл 132 | `$ git commit --amend` # команда добавит изменения в сделанный коммит и откроет редактор для исправления его текста, исправлять необязательно. 133 | 134 | Чтобы просто переименовать предыдущий коммит, 135 | нужно использовать ту же связку команд, но не добавлять файлы в индекс: 136 | `$ git commit -m "Add description"` 137 | `$ git commit --amend` 138 | 139 | -------------------------------------------------- 140 | 141 | # Contributing 142 | 143 | Нашел ошибки? Хочешь пулреквестнуть? 144 | Пиши мне в slack [@beastrock](https://devmanorg.slack.com/team/beastrock) или [вконтакте](http://vk.com/beastrock). 145 | --------------------------------------------------------------------------------