Начали использовать source-driven approach and Salesforce DX в новом проекте, и есть одна проблема с GitHub.
В какой то момент он ведет себя не так как я ожидал, а скорее всего я что-то делаю не так, так как с такой проблемой просто невозможно его использовать.
Вот пример:
Есть два разраба, один работает в одном Скретч орге и создает объект А. Другой работает в другом Скретч орге и создает объект Б. Их работы не пересекаются, за исключением Permission sets.
Первый программист создал объект А, добавил права на объект А в Permission set, создал в локальном гите новую ветку "Объект А", опубликовал ее на гитхабе, сделал пул риквест и замержил все в гитхаб мастер. Локальную и гитхаб ветки "Объект А" можно удалять, они сделали свое дело.
Второй программист все сделал то же самое, но с объектом Б. Но в его версии Permission sets нет ничего об объекте А, так как объекта А нет в его орге, и вообще это не его забота. И вот он делает пул риквест, и пул риквест показывает что никаких конфликтов нет, ветка "Объект Б" мерджится в мастер, и все - Permission sets перезаписан версией от разработчика Б! Ну как так?
GitHub не показывает конфликта, не выводит в режим ручного построчного мержа, чтобы можно было бы построчно все помержить. Все что GitHub - это показывает в момент пул-риквеста внизу страницы разницу в документах: что было добавлено, что было удалено. Но выйти оттуда в режим ручного построчного редактирования нет возможности.
Что я делаю не так?
Может кто-то rebase делал? Второй программист например. Или еще настроен специфический тип merge и его опции.
Можно в истории посмотреть что и как было
не думаю, эти программисты таких слов то не знают
не думаю, эти программисты таких слов то не знают
Попробуйте внедрить pull requests и что бы qa их апрувили
в смысле? новая feature-ветка у нас не мержится на гитхабе как-то автоматически, кто-то все равно должен в ручную создать pull request, а потом апрувнуть его
не думаю, эти программисты таких слов то не знают
Возожно поэтому и сделали ребейс)))
а можно сделать ребейс не делая ребейс?
все что мы делаем, это add/comit, checkout new branch, publish to remote, далее уже описаная часть на гитхабе, и далее сразу или не сразу делаем fetch или pull с ремоута в локал мастер чтоб освежиться
а можно сделать ребейс не делая ребейс?
все что мы делаем, это add/comit, checkout new branch, publish to remote, далее уже описаная часть на гитхабе, и далее сразу или не сразу делаем fetch или pull с ремоута в локал мастер чтоб освежиться
можно случайно не заметить и тыкнуть галочку, ребейс вместо пула, и все(это если вы через source tree или fork или любой другой гит клиент работаете)
ok, есть идея искусствено провоцировать конфликт во время pull request с Permission sets
например
можно ли каждый раз перед комитом добавлять в Permission set такой коммент на line 1:
<!-- push number 1 -->
и увеличивать номер каждый раз
это спровоцирует конфликт в время pull request и выход на скрин построчного мержа?
А перед тем, как сделать pull request, мердж master делается в текущую ветку?
ну давайте разбираться.
если вы имеете ввиду то что происходит не на локальном гите, а на гитхабе,
то туда прилетает новая feature-ветка, с которой делается pull request в мастер
зачем перед этим делать мердж master в нее?
а сама ветка очень свежая, она создается из локального мастера на локальном гите как раз перед отправкой на гитхаб (потом удаляется, как и ее аналог на гитхабе). Сам локальный мастер может быть свежим или несколько комитов отставшим от мастера на гитхабе
например
можно ли каждый раз перед комитом добавлять в Permission set такой коммент на line 1:
<!-- push number 1 -->
и увеличивать номер каждый раз
это спровоцирует конфликт в время pull request и выход на скрин построчного мержа?
конфликт будет только если в 2х разных ветках сделать такой комментарий на одной и той же линии
<!-- push number branch1-1 -->
<!-- push number branch2-1 -->
тогда после мержа первой ветки в мастер/девелоп(у кого что), при попытке мержа второй ветки будет конфликт, так как во второй ветке никто не знал про изменения из первой ветки. поэтому перед созданием пр нужно делать пулл из мастера в ветку под номером 2, тогда на момент пулла ваш клиент выдаст вам что у вас есть конфликты(вы в своей меняли ту же строчку что менялась в первой ветке).
Я не работал конкретно с гитхабом, но битбакет выдает при создании пулреквеста информацию, что ваша ветка X коммитов behind master branch(30 изменений в мастере с момента последнего пулла в ветку) и Y коммитов ahead(30 изменений в вашей ветке)
Вот пробовал у себя воспроизвести сценарий - не получилось. Всегда изменения дописывались дополнительно в файл и ничего не перетиралось.
Вообще, если посмотреть историю файла с Permission Set, по-идеи, должно показать в каком коммите проискходит перетирание. Если это во время мержа - то в мерж коммите должно быть.
У меня раньше подобное было, когда реверт коммитов криво делал. Но опять же, это должно быть видно в истории.
Девелоперы комитят только свои изменения или весь файл?
вот этого и нужно мне добиться
Хорошие вопросы задаете.
Не хотел я этого вам рассказывать, но придется.
В связи с тем, что наши СФ разрабы очень неопытны с source-driven разработкой в целом и гитом в частности, есть риск что они могут закомитить все что было вытянуто со скретча и так отправить на гитхаб
чтоб избежать таких конфузов, пока они учатся, было решено, что они работают с двумя локальными проектами:
- чистовой Мастер проект, его гит подключен к ремоуту, из него идет обновление скретча через деплой команды.
- рабочий проект, подключенный к скретчу, и использует пулл/пуш команды для обмена обновками с этим скретчем. Здесь делается работа.
когда юзер стори готова, то разраб в ручную копипастит новые или обновленные компоненты с рабочего проекта в чистовой, своими глазами видя, что сейчас будет отправлено в ремоут. Ну и далее в чистовом проекте идет адд/комит/чекаут новую ветку/паблиш
и, да, permission set file во время копипасты перетирается полностью. Думаете, если бы они копипастили в него только измененную часть, то на гитхабе проблем с перетиранием не было? Замедьте, по своему содержанию, перетертый во время копипасты permission set file или вручную дополненный будут одинаковы.
А не должно ли быть так?:
чекаут новую ветку -> адд/комит -> pull from master (если есть конфликты - правятся) -> push на ремоут -> создание пулреквеста -> мерж
В таком варианте ничего перетираться не должно
Думаю тут и зарыта собака. Получается же, что делается коммит в мастере, потом создается ветка с мастера и отправляется на ремоут, чтоб пулреквест создать и изменения попали в мастер на ремоут. Но во время мержа гит считает, что то состояние в ветке - истина, так как коммит с изменениями был изначально сделан в мастере, соответственно просто мержит состояние и все.
Нужно проверить
тоже годная идея
специально спросил у другого проекта, они утверждают, что они сначала делают чек аут новой фитче ветки из мастера, и потом делают в нее эдд/комит изменений, и все равно имеют ту же проблему. И они тоже копипастят Перм сет файл целиком
А как можно закоммитить только часть файла? Я может вопрос неправильно понял.
1. Вытягивается "мастер" ветка
2. Создается ветка под задачу от "мастера"
3. Вносятся изменения в файл
4. Файл коммитится - и тут будут видны изменения (пару строчек, а не весь файл удален, и пару строчек добавлены), т.е. разница между изначальной версией файла и версией после изменений. Но закоммитить только часть файла - это удалить из файла другие части (что совершенно неправильно и так делать не надо).
5. В ветке под задачу видны изменения (пару строчек) в файле
Собственно единственный вариант - это сесть и глянуть на историю изменений, там все будет видно.
После этого начать разматывать историю, общаясь с разрабами и прося их повторить шаги, которые они делали, вплоть до нажимания кнопки "Merge". Если воспроизведется - то уже можно понять куда копать. Если не воспроизведется - значит что-то все-таки эти разработчики сделали не так в прошлый раз.
Можно даже сделать новую ветку от коммита, от которого создали свои ветки оба разраба, и полностью повторить сценарий.
я не работал с гитхабом конкретно, только с локально серверными версиями
как по мне оба разраба должны были сделать пул перед пушем и (если уже сделали коммит) получить локальный мердж конфликт или (если не сделали коммит) увидеть что стирают чужие изменения. Для этого есть diff который тебе все покажет.
ну и никогда не стоит скидывать целиком файл в гит, всякие профайлы , пермишшен сеты и т.д. все мерджится построчно, я использую winmerge, кому что удобно. Скидывать целиком файлы верный способ закоммитить то что не надо. В мастер вообще так никогда не закоммитишь потому что профайл в продакшене может содержать строчки метадаты которые не может содержать профайл в сэндбоксе потому что есть пермишшены которые существуют только в проде.
тогда нужно подготовить целый список того, что требуется мержить построчно.
Уже четыре списка нужно:
(1) какие компоненты нужно держать в пре-деплой папке, в деплой (default) и в пост-деплой
(2) компоненты, которые требуется мержить построчно.
(3) список того, что не возможно задеплоить, а нужно настраивать только в ручную
(4) список настроек которые существуют только в проде (если есть такие и если они должны быть отражены в проектной метадате)
тогда нужно подготовить целый список того, что требуется мержить построчно.
Уже четыре списка нужно:
(1) какие компоненты нужно держать в пре-деплой папке, в деплой (default) и в пост-деплой
(2) компоненты, которые требуется мержить построчно.
(3) список того, что не возможно задеплоить, а нужно настраивать только в ручную
(4) список настроек которые существуют только в проде (если есть такие и если они должны быть отражены в проектной метадате)
всё гораздо проще
ничего нельзя мерджить целым файлом если это не новый файл
готово 
Задеплоить можно почти все. Если ты уже деплоишь профиля это практически конец. Остаются всякие портальные изменения, орг левел настройки, рекорды в обьекты или в кастом сеттинги и совсем специфические вещи типа letterheads
Like, like, like :)
