I
Size: a a a
2017 June 23
FD
Выше Евгений опубликовал видео уроки. Пожалуй начну с них.
M
У людей нет времени читать, им надо выпускать фичи =/
M
спасибо за ссылке
FD
У людей нет времени читать, им надо выпускать фичи =/
Не отрицаю. Но увы, придётся читать, иначе в будущем выстрелим в ногу.
P
EK
эта ссылка есть в видео уроке
EK
и даже трактовка за пару минут там
EK
2 вопрос это сборка проекта и там целая пестня
EK
по workflow я рассказал 2 самых популярных подхода
EK
просто делает merge и переносятся комиты
P
Коллеги, возникла спорная ситуация - как вести разработку?
В наличие есть пять проектов, каждому свой репозиторий.
Каждый из проектов должен разрабатываться по аналогичному плану:
Ведём разработку в ветке testing. В какой-то определённый момент переносим все коммиты в master.
Соответственно ветка мастер у нас "LTS".
1. Как переносить коммиты с testing в master с полной заменой?
2. Как делать билды?
Например: создаём два проекта в Jenkins для кажого из репозиториев.
Один проект для ветки master/другой для ветки testing или же два проекта на репозиторий - два проекта предпочтительней, проще организовывать те же статусы.
В самих репозиториях два информира с статусом билдов.
p.s. Есть какие-то другие предложения?
В наличие есть пять проектов, каждому свой репозиторий.
Каждый из проектов должен разрабатываться по аналогичному плану:
Ведём разработку в ветке testing. В какой-то определённый момент переносим все коммиты в master.
Соответственно ветка мастер у нас "LTS".
1. Как переносить коммиты с testing в master с полной заменой?
2. Как делать билды?
Например: создаём два проекта в Jenkins для кажого из репозиториев.
Один проект для ветки master/другой для ветки testing или же два проекта на репозиторий - два проекта предпочтительней, проще организовывать те же статусы.
В самих репозиториях два информира с статусом билдов.
p.s. Есть какие-то другие предложения?
2й вопрос вроде бы включает в себя единственный возможный вариант :)
На счет билдов, вроде бы там не должно быть каких-либо сложностей, особенно если проект собирается быстро
Разве что, если проект большой, стоит сделать отдельный вручную запускаемый билд, которой можно запустить с любого коммита, чтобы он не перезатер другие билды.
Это может пригодиться на случаи:
1) если подготовка проекта к релизу очередной версии занимает много времени и эту предрелизную версию нужно тестировать на QA
2) если хочется протестировать сырой прототип, который длительное время разрабатывается в отдельной ветке и который рано мержить в основную ветку разработки
На счет билдов, вроде бы там не должно быть каких-либо сложностей, особенно если проект собирается быстро
Разве что, если проект большой, стоит сделать отдельный вручную запускаемый билд, которой можно запустить с любого коммита, чтобы он не перезатер другие билды.
Это может пригодиться на случаи:
1) если подготовка проекта к релизу очередной версии занимает много времени и эту предрелизную версию нужно тестировать на QA
2) если хочется протестировать сырой прототип, который длительное время разрабатывается в отдельной ветке и который рано мержить в основную ветку разработки
P
То есть в этих случаях можно конечно быстро создать проект (конфигурацию сборки), но зачастую оно того не стоит
2017 June 24
l
Коллеги, возникла спорная ситуация - как вести разработку?
В наличие есть пять проектов, каждому свой репозиторий.
Каждый из проектов должен разрабатываться по аналогичному плану:
Ведём разработку в ветке testing. В какой-то определённый момент переносим все коммиты в master.
Соответственно ветка мастер у нас "LTS".
1. Как переносить коммиты с testing в master с полной заменой?
2. Как делать билды?
Например: создаём два проекта в Jenkins для кажого из репозиториев.
Один проект для ветки master/другой для ветки testing или же два проекта на репозиторий - два проекта предпочтительней, проще организовывать те же статусы.
В самих репозиториях два информира с статусом билдов.
p.s. Есть какие-то другие предложения?
В наличие есть пять проектов, каждому свой репозиторий.
Каждый из проектов должен разрабатываться по аналогичному плану:
Ведём разработку в ветке testing. В какой-то определённый момент переносим все коммиты в master.
Соответственно ветка мастер у нас "LTS".
1. Как переносить коммиты с testing в master с полной заменой?
2. Как делать билды?
Например: создаём два проекта в Jenkins для кажого из репозиториев.
Один проект для ветки master/другой для ветки testing или же два проекта на репозиторий - два проекта предпочтительней, проще организовывать те же статусы.
В самих репозиториях два информира с статусом билдов.
p.s. Есть какие-то другие предложения?
Помог бы даже банальный gitflow — который конкретная методология с features, master, hotfix, release и dev бранчами
🦉
Коллеги, возникла спорная ситуация - как вести разработку?
В наличие есть пять проектов, каждому свой репозиторий.
Каждый из проектов должен разрабатываться по аналогичному плану:
Ведём разработку в ветке testing. В какой-то определённый момент переносим все коммиты в master.
Соответственно ветка мастер у нас "LTS".
1. Как переносить коммиты с testing в master с полной заменой?
2. Как делать билды?
Например: создаём два проекта в Jenkins для кажого из репозиториев.
Один проект для ветки master/другой для ветки testing или же два проекта на репозиторий - два проекта предпочтительней, проще организовывать те же статусы.
В самих репозиториях два информира с статусом билдов.
p.s. Есть какие-то другие предложения?
В наличие есть пять проектов, каждому свой репозиторий.
Каждый из проектов должен разрабатываться по аналогичному плану:
Ведём разработку в ветке testing. В какой-то определённый момент переносим все коммиты в master.
Соответственно ветка мастер у нас "LTS".
1. Как переносить коммиты с testing в master с полной заменой?
2. Как делать билды?
Например: создаём два проекта в Jenkins для кажого из репозиториев.
Один проект для ветки master/другой для ветки testing или же два проекта на репозиторий - два проекта предпочтительней, проще организовывать те же статусы.
В самих репозиториях два информира с статусом билдов.
p.s. Есть какие-то другие предложения?
а че не адекватный github-flow???
🦉
о, ну или gitflow
P
Ну github-flow вроде бы не подходит топикстартеру т.к. судя по описанию планируется иметь ветку разработки и ветку релизов
P
Вот на счет gitflow полностью согласен
2017 June 28
VS
Добрый день. Такой вопрос:
У меня есть, например, ветка dev. Я делал в ней некоторые изменения, а потом сделал squash & merge в master.
Я бы хотел продолжить работать в ветке dev, но при последующих слияниях с мастер-веткой все предыдущие коммиты (которые уже слиты с ней) тоже учитываются (на гитхабе автоматически добавляются в описание пулл реквеста и отображаются в списке).
Как правильнее это делать, или может так вообще не нужно делать?
Спасибо.
У меня есть, например, ветка dev. Я делал в ней некоторые изменения, а потом сделал squash & merge в master.
Я бы хотел продолжить работать в ветке dev, но при последующих слияниях с мастер-веткой все предыдущие коммиты (которые уже слиты с ней) тоже учитываются (на гитхабе автоматически добавляются в описание пулл реквеста и отображаются в списке).
Как правильнее это делать, или может так вообще не нужно делать?
Спасибо.
G
Добрый день. Такой вопрос:
У меня есть, например, ветка dev. Я делал в ней некоторые изменения, а потом сделал squash & merge в master.
Я бы хотел продолжить работать в ветке dev, но при последующих слияниях с мастер-веткой все предыдущие коммиты (которые уже слиты с ней) тоже учитываются (на гитхабе автоматически добавляются в описание пулл реквеста и отображаются в списке).
Как правильнее это делать, или может так вообще не нужно делать?
Спасибо.
У меня есть, например, ветка dev. Я делал в ней некоторые изменения, а потом сделал squash & merge в master.
Я бы хотел продолжить работать в ветке dev, но при последующих слияниях с мастер-веткой все предыдущие коммиты (которые уже слиты с ней) тоже учитываются (на гитхабе автоматически добавляются в описание пулл реквеста и отображаются в списке).
Как правильнее это делать, или может так вообще не нужно делать?
Спасибо.
так и должно работать