#git #github
В начале идея:
допустим имеется проЭкт. Планируется, что он будет лежать по адресу
https://github.com/myProfile/test.git
Локально постоянно что-то делается, коммитится сотни раз в сотнях ветках. Далее
заливается на гитхаб как версия 1.1. Далее исправляется 100 ошибок еще со 100 коммитами
и заливается уже как версия 1.2 и т.д.
То есть у себя, как внутриразрабатываемого продукта, будет история с сотней-тысячей
коммитов для отслеживания и отката (на всякий случай), а ТАМ (на гитхабе) история только
"ver 1.1.", "ver 1.2 (что исправлено)", и т.д...
Можно ли это как-то сделать? Возможно ли?
Вот как примерно процесс происходит локально (кстати, может это уже неправильно,
не знаю):
создаю папку test
набираю команду инициализации git init
создаю какой-либо файл и добавляю git add ., git commit -am "initial commit"
И дальше пляска по сценарию:
1 шаг: создается ветка git checkout -b develop20160731
2 шаг: что-то делается и добавляется:
git add .
git commit -am "some comment"
git checkout master
git merge develop20160731
git checkout develop20160731
3 шаг: повторяется шаг №2 N-раз.
4 шаг: повторяется все с шага №1 уже с другой веткой
В итоге история выглядит как-то так:
* a0c188f 2016-07-31 | comment №2 for anotherBranch (HEAD -> master, anotherDevelop)
[anonymous]
* 6acdde0 2016-07-31 | comment №1 for anotherBranch [anonymous]
* 9557ff9 2016-07-31 | comment №2 for my branch (develop20160731) [anonymous]
* b6946aa 2016-07-31 | comment №1 for my branch [anonymous]
* 864e4d9 2016-07-31 | initial commit [anonymous]
Нахожусь в мастере. И хочу все это отправить на Github как версию 1.1, т.е.
в истории коммитов чтоб там был единственный одинокий коммит, что-то типа
Commits on Jul 31, 2016
@anonymous
added superProject v1.1
anonymous committed 1 second ago
а не все коммиты проекта.
В следующий раз, чтоб добавился лишь еще один коммит added superProject v1.2 из всех
собранных коммитов локально и т.д.
Как так вытворить?
P.S. Если я как-то неправильно что-то делал локально, то прошу описать как правильнее.
Хотелось бы, в идеале, полную инструкцию от и до "на пальцах"
Ответы
Ответ 1
Далее заливается на гитхаб как версия 1.1. Далее исправляется 100 ошибок еще со 100 коммитами и заливается уже как версия 1.2 и т.д. Как правило, между версиями добавляется более чем одна фича или одно исправление ошибки. Сливать все исправления и дополнения в один коммит - неконструктивно. Потом сложно будет искать ошибки или ревертить изменения. Если история у вас примерно такая: c1fed68 попробуем сделать это так a046d5b неа, не работает, давай по-другому 836f56c вроде нормально, давай пока сохраним несколько временных файлов 5edb66e пускай этот код не компилируется, но я иду домой, надо сохранить работу 8cb14a7 зря я вчера так написал, есть покрасивее способ 91c6c05 вот так зашибись 01c5594 вроде даже работает То можно предложить следующий режим работы (он примерно соответствует методологии git-flow): В процессе работы над фичей разработчик делает отдельную ветку для фичи и в неё столько коммитов, сколько ему удобно. Если содержимое таких веток вы тоже не хотите показывать, то можно завести второй, закрытый репозиторий, в котором будет вся "кухня", включая пулл-реквесты. Ветки фич предлагаются к слиянию в develop, где копятся до релиза. В момент слияния ветка фичи схлапывается до 1 коммита (на выбор git rebase -i, git reset --soft develop), к коммиту пишется внятный комментарий. При этом привносить изменения в develop вы можете осуществлять как через слияние (merge), так и через rebase - это вопрос предпочтений команды. У обоих методов есть достоинства и недостатки. Когда накопленные в develop фичи и багфиксы по вашим субъективным критериям должны стать релизом, происходят следующие шаги: Ветка develop сливается в master. С большой вероятностью будет возможен fast-forward, но если хотите и здесь сделать коммит слияния, используйте git merge --no-ff develop. Можно сконфигурировать Git, чтобы --no-ff подразумевалось для всех или только определённых веток - об этом подробнее в ответе KoVadim. На полученный коммит вешается тег релиза. Обязательно используйте полновесный коммит (с комментарием). git tag 1.2.3 -m 'release 1.2.3' git push --follow-tags Если вы решили использовать два репозитория, сейчас самое время запушить в публичный. git push github --follow-tags Кстати, по похожей схеме реализована работа над такими крупными проектами как Linux. Там есть промежуточные ревьюеры, которые принимают к себе исключительно чистые, завершённые и упакованные коммиты, а потом проталкивают их дальше. А черновики не уходят дальше собственных репозиториев разработчиков. В принципе, вы можете сливать все релизные коммиты в один перед пушем на публичный репозиторий. Однако, это чревато сложностями: Практически невозможно отследить коммит, который внёс ошибку. Нельзя отменить (git revert) конкретный коммит (т.е. фичу, правку и т.п.) Если вы захотите выпустить патч к версии, вам всё равно придётся выпускать его отдельным коммитом. Если кто-то со стороны предложит вам пулл-реквест с небольшими правками, то принять его и после влить в один большой коммит будет невежливо. Так вы фактически сотрёте информацию об авторстве кода. Рекомендую остановиться на соответствии 1 фича - 1 коммит и дальше не объединять. Пользователи, даже не самые опытные, должны справиться с довольно несложным интерфейсом релизов на Github. А если в момент слияния ветки фичи есть какой-то код, который "неудобно" показывать публике - это признак того, что фича не готова. Пример: страница релизов самой программы Git даёт вполне наглядное представление о том, что является релизом:Ответ 2
Сложно будет сделать так, что бы на github были одни коммиты, а у разработчиков - другие. Но можно сделать так, как делают в больших группах. все фичи или багфиксы делаются в отдельной ветке. Даже мелкие. И не имеет значения, сколько там будет коммитов. Все изменения тестируются в своих ветках. Если изменение не подошло, то ветку можно оставить или прибить (по желанию). Когда фича/багфикс готов, его мержат в master/develop (это определяется текущим процессом и надобностями) с no fast forward (git merge --no-ff <ветка>). В этом случае в основной ветке будет как бы один коммит, но будет видно при необходимости все остальные. Такой коммит легко отревертить (git revert -m 1) (на самом деле это не просто реверт, а накатывания дифа изменений "наоборот", поэтому, если нужно, его можно откатить много раз - то есть, можно откатить откат отката). no fast forward можно включить в конфиге, тогда не нужно будет даже указывать при мердже git config --add merge.ff false или git config branch.master.mergeoptions "--no-ff" если нужно отключить только для мастера. Подсумируем, на самом деле, похоже, Вам нужно только в конфиг добавить настройку и даже не нужно менять процесс.
Комментариев нет:
Отправить комментарий