Гит – система контроля версий. Им можно пользоваться без гитхаба вообще. Создаете локальный репозиторий и работаете. Можно потом удаленный репозиторий добавить в общей папке на сервере.
Гитхаб – сервис для командной разработки. Там много всего, но в том числе есть и гитовый репозиторий. Некоторые операции можно делать прямо в браузере, но для полноценной работы нужен и локальный гит клиент.
Гитхаб не единственный в своем роде, есть еще гитлаб и битбакет (самые популярные альтернативы).
Наверное, всё дело в том, что распределение зарплат там было справедливым? Т.е. я вот смотрел на коллег, которые получают больше и понимал, что всё справедливо.
А если бы вам казалось, что распределение не самое справедливое, мы бы статью-антоним читали?
Хороший метод. Применял его пару раз, но скорее случайно, чем осознанно. Из последнего: подождал, пока все выскажутся в почтовом треде и только потом предложил свое решение, основанное на всех предложения и обсуждениях.
У вас, получается, действует правило "кто нашел, тот и сломал"? Качество код-ревью от этого не страдает? Ведь приходится из своей задачи "вынырнуть", чтобы качественно починить чужой код.
Про оверхед, сравнимый с парным программтрованием, интересно замечено.
А вы этот гайд на 100 страниц читать будете? На ревью, конечно, приятнее получить ссылку на документ, чем простое "у нас так принято", но легче не станет, мне кажется.
Сам я за жесткие автоматические проверки на стадии CI. Зачем спорить о том, что могут проверить машины?
А можно как-то проверить коммиты, которые были перенесены в другую ветку с помощью cherry-pick? sha у них отличаются, конечно. Можно попробовать patch-id, но это несколько затратно перебирать много коммитов.
Поддерживаю. Можно хотя бы пониже варианты располагать, а то замечаю их краем глаза, и все — помню слово. Оставшееся время трачу на то, чтобы осознать, вспомнил или все же прочитал.
А то, что этот функционал добавили, это очень круто.
Спасибо, становится понятнее.
Что вы понимаете под блоком? Еще, на сколько я понял, совершенно игнорируется реальная структура файла, вы рассматриваете его как битовый поток. Верно? И на сколько рандомные повреждения похожи на те, что происходят в реальной жизни?
Промахнулся, ответил ниже
Гит – система контроля версий. Им можно пользоваться без гитхаба вообще. Создаете локальный репозиторий и работаете. Можно потом удаленный репозиторий добавить в общей папке на сервере.
Гитхаб – сервис для командной разработки. Там много всего, но в том числе есть и гитовый репозиторий. Некоторые операции можно делать прямо в браузере, но для полноценной работы нужен и локальный гит клиент.
Гитхаб не единственный в своем роде, есть еще гитлаб и битбакет (самые популярные альтернативы).
А если бы вам казалось, что распределение не самое справедливое, мы бы статью-антоним читали?
Хороший метод. Применял его пару раз, но скорее случайно, чем осознанно. Из последнего: подождал, пока все выскажутся в почтовом треде и только потом предложил свое решение, основанное на всех предложения и обсуждениях.
У вас, получается, действует правило "кто нашел, тот и сломал"? Качество код-ревью от этого не страдает? Ведь приходится из своей задачи "вынырнуть", чтобы качественно починить чужой код.
Про оверхед, сравнимый с парным программтрованием, интересно замечено.
А вы этот гайд на 100 страниц читать будете? На ревью, конечно, приятнее получить ссылку на документ, чем простое "у нас так принято", но легче не станет, мне кажется.
Сам я за жесткие автоматические проверки на стадии CI. Зачем спорить о том, что могут проверить машины?
Эта команда, как минимум, уже готова. Спасибо, попробую.
А можно как-то проверить коммиты, которые были перенесены в другую ветку с помощью
cherry-pick? sha у них отличаются, конечно. Можно попробоватьpatch-id, но это несколько затратно перебирать много коммитов.Так ведь уже было. Вот тут, например: https://habrahabr.ru/post/243091/.
Официальный ответ Telegram.
А то, что этот функционал добавили, это очень круто.
Очень пригодилось бы для студийных проектников. Добавление нового файла – всегда конфликт.
Что вы понимаете под блоком? Еще, на сколько я понял, совершенно игнорируется реальная структура файла, вы рассматриваете его как битовый поток. Верно? И на сколько рандомные повреждения похожи на те, что происходят в реальной жизни?