Вопросы и если что-то не получается можете писать в комментариях, я постараюсь помочь. Так же можно посмотреть плейлист по Git: th-cam.com/video/ii8uMQhzZBE/w-d-xo.html.
просто еще раз хотел поблагодарить за то, что уже 2 года работаю в IT. даже не сразу осознал, насколько крутые курсы. Библиотеки подучить и инфраструктуру можно где угодно или даже самому, а Тимофей очень доходчиво объяснял архитектуру (clean, mvvm, mvp, паттерны, etc) и зачем вот это всё. как оказалось, эти вещи очень мало кто понимает и умеет правильно использовать. (это не реклама)
Кстати важно, что если вы создаете ветки для фиксов или дополнений в основную ветку, но перед СОЗДАНИЕМ фикс-ветки находились в ПРОШЛОЙ фикс-ветке, то в новый pull-request попадет не только ваш новый код над которым вы работали, но и старый из прошлой ветки. Поэтому не забывайте перед созданием новой ветки выходить в мастер
Спасибо за важное пояснение. Когда-то натолкнулся на эту проблему и, будучи совсем новичком в Git, долго мучился с последствиями, не понимая, где накосячил)
Спасибо за видео! Но у меня появился вопрос. А просто объединить с главной веткой никак нельзя? Ну, там слить вместе, как нибудь, соединить?) Только обязательно смерджить?))
Я так понял, смерджили в PR ветки, удалили ветку, локально сделали пулл и получили смердженные ветки? У меня так не работает. После попытки стянуть в удаленного репозитория себе локально, я вижу следующее: Your configuration specifies to merge with the ref 'refs/heads/dev' from the remote, but no such ref was fetched. Т.е. ветки локально не слиты и локально нужно также слить ветки? Или делать что-то типа git pull --merge origin main ?
Никак :). Просто делаете коммит и в комментариях отвечаете на замечания, например "Исправлено", или нажимаете на кнопку "Resolve" (может по разному называться в разных системах). Вам стоит узнать, как принято это делать конкретно в вашей команде или компании, подходы могут различаться.
после того как я "пошел пообедал ,и еще поработал", прежде чем делать PR, нужно ОБязательно! сделать не только коммит, но и Пуш, чтобы в рабочем репозитории не осталось незалитых на сервер изменений. В частности в PR они не попадут, если перед этим не было Push. Верно ведь?
Правильно, поскольку пулл реквест - это функция сервиса, в данном случае гитхаба, и потому все изменения должны быть туда залиты, чтобы было что мерджить.
Это конечно классно все , но на практике далеко не так, хоть я с ней и не сталкивался. Я уже наверное ответ не увижу но все же напишу 1. Допустим у меня реализация фитчи состоит 50 файлов. Не камельфо столько проверять за раз. 2. Чтобы не допустить развития событий 1, будем п.р по 4 файла, т.е сделал за сегодня отправил на ревью. Т.е получается мне надо будет делать п.р из моей ветки в мою же ветку?
Ну во первых врят-ли вас будут каждый день ревьювить по чуть чуть, у других программистов в команде тоже хватает задач. А во вторых, если задача большая, то нужно разбивать на небольшие куски, которые можно будет мерджить в мастер независимо друг от друга. Либо создать общую ветку для вашей задачи, а от нее уже делать разбивку на более мелкие задачи, и пул реквест делать не в мастер, а именно в эту ветку, а когда все части будут проверены можно будет за раз смерджить главную ветку. Делать ПР за каждый день не нужно, нужно делать только когда есть готовая законченая часть. Если так не получается значит задача слишком массивная и требует разделения.
сделал pull request, потом поступили правки, я могу сделать новые коммиты и заново сделать pull request этой ветки или какие действия при таком условии?
Смысл Pul request в возможности, что-то сделать на сервере - ревью кода другими разработчиками, автоматизированный запуск тестов и тд. Поэтому технически можно, но на практике так никто не делает.
Спасибо за информацию. У меня вопрос: вы добавляете через Settings, а потом Collaborators людей. А как их добавить, если я захожу в settings, а там нет вкладки Collaborators? Видимо интерфейс поменялся. Где искать ?)
@@TimofeyKovalenko не немного а ваще поменялся кардинально, давно пора новые видео делать уже по интерфейсу. Кстати, а что если не использовать пулл реквесты, а просто скопировать из адресной строки ссылку на конкретный открытый репозиторий? так тоже пойдет, чтобы показать кому-то?
да, но минус такого способа, что не видна разница между тем что было, и тем что стало. Смысл PR в том, что видно какие конкретно строки кода менялись, то есть видна разница между теми файлами, которые были до новых изменений в PR. Я рекомендую создать файлы, залить в мастер, затем сделать какие нибудь изменения и залить это как PR. А затем самому полазить по PR и посмотреть как это выглядит в гит хабе. Тогда сразу станет все понятно.
@@TimofeyKovalenko уточню, там работать с решением не так удобно как в чреде разработки. Комменты, замечания, там удобно делать и в таком смысле ревью там хорошо делать. Особенно когда замечаний много гитлаб очень упрощает работу. Но если возникают конфликты, при мердже, вы как из решаете? В гитлабе или в стеле разработки?
Вопросы и если что-то не получается можете писать в комментариях, я постараюсь помочь. Так же можно посмотреть плейлист по Git: th-cam.com/video/ii8uMQhzZBE/w-d-xo.html.
Спасибо вам, отличный информационный видосик!:)
как отправить реквест ссылкой на код
Всё время ломал голову о том что это
Отлично рассказано и показано
Спасибо большое
Кратко и очень понятно. Спасибо!!!
Спасибо большое! Кратко, корректно и конкретно!
Спасибо добрый человек, то над чем голову ломала у вас поняла!!!
просто еще раз хотел поблагодарить за то, что уже 2 года работаю в IT. даже не сразу осознал, насколько крутые курсы. Библиотеки подучить и инфраструктуру можно где угодно или даже самому, а Тимофей очень доходчиво объяснял архитектуру (clean, mvvm, mvp, паттерны, etc) и зачем вот это всё. как оказалось, эти вещи очень мало кто понимает и умеет правильно использовать. (это не реклама)
Очень подробно и информативно. Спасибо большое)
спасибо за подробные объяснения!
Как всегда всё понятно. Спасибо!!!👍
Отлично объясняешь!
спс все четко без воды.
Отлично, как раз то, что я искал👍
Космос! Так рада что нашла это видео, очень помогло!
Спасибо за урок,Тимофей!
Спасибо 😊 видео очень помогло 👍🏻
Спасибо Тимофей, ты мне очень помог, видосу лайк 👍
Все по делу! Супер! Спс
git спасибо большое за видео))
Спасибо!!
пасиб, мне очень помогло)
Кстати важно, что если вы создаете ветки для фиксов или дополнений в основную ветку, но перед СОЗДАНИЕМ фикс-ветки находились в ПРОШЛОЙ фикс-ветке, то в новый pull-request попадет не только ваш новый код над которым вы работали, но и старый из прошлой ветки. Поэтому не забывайте перед созданием новой ветки выходить в мастер
Спасибо за важное пояснение. Когда-то натолкнулся на эту проблему и, будучи совсем новичком в Git, долго мучился с последствиями, не понимая, где накосячил)
А что не показали как через баш этакой запрос выполнить?
Спасибо за видео! Но у меня появился вопрос. А просто объединить с главной веткой никак нельзя? Ну, там слить вместе, как нибудь, соединить?) Только обязательно смерджить?))
Я так понял, смерджили в PR ветки, удалили ветку, локально сделали пулл и получили смердженные ветки? У меня так не работает. После попытки стянуть в удаленного репозитория себе локально, я вижу следующее:
Your configuration specifies to merge with the ref 'refs/heads/dev'
from the remote, but no such ref was fetched.
Т.е. ветки локально не слиты и локально нужно также слить ветки? Или делать что-то типа
git pull --merge origin main
?
Спасибо
Блин, спасибо за объяснение, что пул реквест это всего лишь надстройка над мержем.
Подскажите, пожалуйста, после того как я подправил замечания ревьювера, как отправить на повторное ревью?
Никак :). Просто делаете коммит и в комментариях отвечаете на замечания, например "Исправлено", или нажимаете на кнопку "Resolve" (может по разному называться в разных системах). Вам стоит узнать, как принято это делать конкретно в вашей команде или компании, подходы могут различаться.
после того как я "пошел пообедал ,и еще поработал", прежде чем делать PR, нужно ОБязательно! сделать не только коммит, но и Пуш, чтобы в рабочем репозитории не осталось незалитых на сервер изменений. В частности в PR они не попадут, если перед этим не было Push. Верно ведь?
Правильно, поскольку пулл реквест - это функция сервиса, в данном случае гитхаба, и потому все изменения должны быть туда залиты, чтобы было что мерджить.
Это конечно классно все , но на практике далеко не так, хоть я с ней и не сталкивался. Я уже наверное ответ не увижу но все же напишу 1. Допустим у меня реализация фитчи состоит 50 файлов. Не камельфо столько проверять за раз. 2. Чтобы не допустить развития событий 1, будем п.р по 4 файла, т.е сделал за сегодня отправил на ревью. Т.е получается мне надо будет делать п.р из моей ветки в мою же ветку?
Ну во первых врят-ли вас будут каждый день ревьювить по чуть чуть, у других программистов в команде тоже хватает задач. А во вторых, если задача большая, то нужно разбивать на небольшие куски, которые можно будет мерджить в мастер независимо друг от друга. Либо создать общую ветку для вашей задачи, а от нее уже делать разбивку на более мелкие задачи, и пул реквест делать не в мастер, а именно в эту ветку, а когда все части будут проверены можно будет за раз смерджить главную ветку. Делать ПР за каждый день не нужно, нужно делать только когда есть готовая законченая часть.
Если так не получается значит задача слишком массивная и требует разделения.
сделал pull request, потом поступили правки, я могу сделать новые коммиты и заново сделать pull request этой ветки или какие действия при таком условии?
Коммитов достаточно, делать еще один pull reques не нужно.
а если мне нужен не мердж а rebase, то в таком случае нужно с консоли сливать ветки?
В настройках к репозиторию на github должна быть опция, что-бы был rebase вместо merge по умолчанию.
А что если не создавать другую ветку? я ведь могу из локального в удалённый репозиторий пулл реквест сделать
Смысл Pul request в возможности, что-то сделать на сервере - ревью кода другими разработчиками, автоматизированный запуск тестов и тд. Поэтому технически можно, но на практике так никто не делает.
Спасибо за информацию. У меня вопрос: вы добавляете через Settings, а потом Collaborators людей. А как их добавить, если я захожу в settings, а там нет вкладки Collaborators? Видимо интерфейс поменялся. Где искать ?)
Да, немного поменялся. Сейчас это вкладка "Manage access".
@@TimofeyKovalenko не немного а ваще поменялся кардинально, давно пора новые видео делать уже по интерфейсу. Кстати, а что если не использовать пулл реквесты, а просто скопировать из адресной строки ссылку на конкретный открытый репозиторий? так тоже пойдет, чтобы показать кому-то?
да, но минус такого способа, что не видна разница между тем что было, и тем что стало. Смысл PR в том, что видно какие конкретно строки кода менялись, то есть видна разница между теми файлами, которые были до новых изменений в PR. Я рекомендую создать файлы, залить в мастер, затем сделать какие нибудь изменения и залить это как PR. А затем самому полазить по PR и посмотреть как это выглядит в гит хабе. Тогда сразу станет все понятно.
@@TimofeyKovalenko cпасибо
Добрый день!
а можно ли загрузить к себе чужой Pull request ?
Да, просто сливаете себе ветку в котором этот PR находится и можете даже туда коммитить.
А если PR пришёл из приватного форка и доступа к ветке нет?
Почему-то думал, что в мастер абы кто мерджи не может делать.
Так и есть, пока не заревьювят код, никто туда ничего не заливает.
Да в гитлабе не удобно ревьювить. Вы серьезно там ревью делаете?
В большинстве случаев да. Если не выходит сделать это по простому, то это звоночек к тому, что ревью сделано плохо.
@@TimofeyKovalenko уточню, там работать с решением не так удобно как в чреде разработки. Комменты, замечания, там удобно делать и в таком смысле ревью там хорошо делать. Особенно когда замечаний много гитлаб очень упрощает работу.
Но если возникают конфликты, при мердже, вы как из решаете? В гитлабе или в стеле разработки?
Конфликты конечно же в среде правятся).
@@TimofeyKovalenko так мердж реквест подтверждается в гитлабе, и в нем же при подтверждении надо решить конфликты. Разве нет?