Двач.hk не отвечает.
Вы видите копию треда, сохраненную 12 июня 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 12 июня 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Не прошло и года, как предыдущий тред (>>1035893 (OP)) ушел в бамплимит.
Собираем мануалы, тулзы, лайфхаки по версионированию и хранению исходников. Планируем критерии для отправки программистов в биореактор. Доказываем, что данный тред не нужен вовсе.
А также нельзя не отметить, что OP-хуй регулярно раз в год обсирается
Собираем мануалы, тулзы, лайфхаки по версионированию и хранению исходников. Планируем критерии для отправки программистов в биореактор. Доказываем, что данный тред не нужен вовсе.
А также нельзя не отметить, что OP-хуй регулярно раз в год обсирается
Иметь несколько версий физически как на смешных картинках при одновременной с ними работе тупо во много раз удобнее чем иметь их где-то в виртуальном мирке и жонглировать загружая-выгружая их.
>>239124
если это все архивируется теневыми копиями, то почему бы и нет
>все давно перешли на каталоги с суффиксами
если это все архивируется теневыми копиями, то почему бы и нет
Git
На данный момент - default version control system а ля Нерезиновая = ДС. Что характерно, ей не является (https://blog.feld.me/posts/2018/01/git-is-not-revision-control/) без допиливания различными соглашениями, да и позиционирует себя скорее как систему контроля исходных кодов не vcs а scm.
Запилена тем самым Торвальдсом в 2005 году после того как один хитрый Ларри закрыл бесплатный доступ к BitKeeper - тогдашней vcs, использовавшейся при разработке Linux. Первая рабочая версия была готова и выкачена в использование всего за два месяца. Последствия разгребаем до сих пор.
Имеется сайт: https://git-scm.com/ , с него можно взять билды, документацию, исходники. А также книженцию Pro Git: https://git-scm.com/book/en/v2 - в которой есть информация от азов до специфичных вещей эмодзи в комментах, лол. Написание книги, кстати, проходит тоже через git (https://github.com/progit/progit2), из-за особенностей используемых средств полно мест где вовсю торчит css is awesome.
Заявляется, что у гита есть разделение на plumbing и porcelain, то бишь можно пользоваться только дружелюбным фарфором для работы нассать в писуар, но всегда есть возможность копнуть на уровень глубже и работать напрямую с сантехникой срать прямо в трубу. Где-то рядом торчит мем "всего пять комманд нужно для использования". По факту при работе с гитом до уровня сантехники приходится докапываться довольно часто ну или звать сантехника Федора иди разворачивать свежую копию репы, xkcd не врет. Связано это с историей разработки гита, целей его использования и организацией работы: git - проект с типичной unix-идеологией, состоящий из множества мелких утилит, каждая из которых делает только свою работу и делает ее хорошо. С другой стороны, каждая из утилит имеет свой синтаксис и может частично дублировать функционал другой утилиты (например есть git-apply которая применяет патчи, сгенерированные git-diff, но Линуса как-то задолбало вытаскивать патчи из email и накатывать их, потому есть git am который применяет патчи из git-format-patch, полученные с мыла). Также костылями прикручивается поддержка больших файлов LFS или GVFS Однако все это не отменяет открытости git, которая и привела к тому, что его популярность взлетела до небес... с помощью гитхаба.
Github
Если в начале своей истории git соревновался на равных с меркуриалом, то создание https://github.com/ вырвало использование git вперед и закрепило его доминирующее положение. Именно гитхаб прикрыл сложности работы с гитом своим функционалом, что однако вылилось что у гитхаба есть и свои туториалы по гиту (https://guides.github.com/), и свои клиенты (https://desktop.github.com/), и свои надстройки над гитом. Дошло до того, что мало кто знает, что пулл-реквест - это не фича гита, а фича гитхаба git-request-pull запилен сильно позже и не обладает аналогичным функционалом.
Еще гитхаб хорошо протолкнул себя функционалом "соцсети для разработчиков" и тем, что удачно переманил кучу опенсорсных проектов с sourceforge (который к тому же знатно начал обсираться к тому времени) - что в итоге превратило гитхаб в хостинг опенсорных проектов по дефолту и в "строчку в резюме".
На данный момент у гитхаба из конкурентов атлассиановский bitbucket (тоже поддерживает git), относительно недавно еще отпочковался gitlab. А еще его купил Microsoft. По итогу git непотопляем пока не потонул github, но вероятность потонуть из-за славы мелкомягких определенно имеется.
На данный момент - default version control system а ля Нерезиновая = ДС. Что характерно, ей не является (https://blog.feld.me/posts/2018/01/git-is-not-revision-control/) без допиливания различными соглашениями, да и позиционирует себя скорее как систему контроля исходных кодов не vcs а scm.
Запилена тем самым Торвальдсом в 2005 году после того как один хитрый Ларри закрыл бесплатный доступ к BitKeeper - тогдашней vcs, использовавшейся при разработке Linux. Первая рабочая версия была готова и выкачена в использование всего за два месяца. Последствия разгребаем до сих пор.
Имеется сайт: https://git-scm.com/ , с него можно взять билды, документацию, исходники. А также книженцию Pro Git: https://git-scm.com/book/en/v2 - в которой есть информация от азов до специфичных вещей эмодзи в комментах, лол. Написание книги, кстати, проходит тоже через git (https://github.com/progit/progit2), из-за особенностей используемых средств полно мест где вовсю торчит css is awesome.
Заявляется, что у гита есть разделение на plumbing и porcelain, то бишь можно пользоваться только дружелюбным фарфором для работы нассать в писуар, но всегда есть возможность копнуть на уровень глубже и работать напрямую с сантехникой срать прямо в трубу. Где-то рядом торчит мем "всего пять комманд нужно для использования". По факту при работе с гитом до уровня сантехники приходится докапываться довольно часто ну или звать сантехника Федора иди разворачивать свежую копию репы, xkcd не врет. Связано это с историей разработки гита, целей его использования и организацией работы: git - проект с типичной unix-идеологией, состоящий из множества мелких утилит, каждая из которых делает только свою работу и делает ее хорошо. С другой стороны, каждая из утилит имеет свой синтаксис и может частично дублировать функционал другой утилиты (например есть git-apply которая применяет патчи, сгенерированные git-diff, но Линуса как-то задолбало вытаскивать патчи из email и накатывать их, потому есть git am который применяет патчи из git-format-patch, полученные с мыла). Также костылями прикручивается поддержка больших файлов LFS или GVFS Однако все это не отменяет открытости git, которая и привела к тому, что его популярность взлетела до небес... с помощью гитхаба.
Github
Если в начале своей истории git соревновался на равных с меркуриалом, то создание https://github.com/ вырвало использование git вперед и закрепило его доминирующее положение. Именно гитхаб прикрыл сложности работы с гитом своим функционалом, что однако вылилось что у гитхаба есть и свои туториалы по гиту (https://guides.github.com/), и свои клиенты (https://desktop.github.com/), и свои надстройки над гитом. Дошло до того, что мало кто знает, что пулл-реквест - это не фича гита, а фича гитхаба git-request-pull запилен сильно позже и не обладает аналогичным функционалом.
Еще гитхаб хорошо протолкнул себя функционалом "соцсети для разработчиков" и тем, что удачно переманил кучу опенсорсных проектов с sourceforge (который к тому же знатно начал обсираться к тому времени) - что в итоге превратило гитхаб в хостинг опенсорных проектов по дефолту и в "строчку в резюме".
На данный момент у гитхаба из конкурентов атлассиановский bitbucket (тоже поддерживает git), относительно недавно еще отпочковался gitlab. А еще его купил Microsoft. По итогу git непотопляем пока не потонул github, но вероятность потонуть из-за славы мелкомягких определенно имеется.
Git
На данный момент - default version control system а ля Нерезиновая = ДС. Что характерно, ей не является (https://blog.feld.me/posts/2018/01/git-is-not-revision-control/) без допиливания различными соглашениями, да и позиционирует себя скорее как систему контроля исходных кодов не vcs а scm.
Запилена тем самым Торвальдсом в 2005 году после того как один хитрый Ларри закрыл бесплатный доступ к BitKeeper - тогдашней vcs, использовавшейся при разработке Linux. Первая рабочая версия была готова и выкачена в использование всего за два месяца. Последствия разгребаем до сих пор.
Имеется сайт: https://git-scm.com/ , с него можно взять билды, документацию, исходники. А также книженцию Pro Git: https://git-scm.com/book/en/v2 - в которой есть информация от азов до специфичных вещей эмодзи в комментах, лол. Написание книги, кстати, проходит тоже через git (https://github.com/progit/progit2), из-за особенностей используемых средств полно мест где вовсю торчит css is awesome.
Заявляется, что у гита есть разделение на plumbing и porcelain, то бишь можно пользоваться только дружелюбным фарфором для работы нассать в писуар, но всегда есть возможность копнуть на уровень глубже и работать напрямую с сантехникой срать прямо в трубу. Где-то рядом торчит мем "всего пять комманд нужно для использования". По факту при работе с гитом до уровня сантехники приходится докапываться довольно часто ну или звать сантехника Федора иди разворачивать свежую копию репы, xkcd не врет. Связано это с историей разработки гита, целей его использования и организацией работы: git - проект с типичной unix-идеологией, состоящий из множества мелких утилит, каждая из которых делает только свою работу и делает ее хорошо. С другой стороны, каждая из утилит имеет свой синтаксис и может частично дублировать функционал другой утилиты (например есть git-apply которая применяет патчи, сгенерированные git-diff, но Линуса как-то задолбало вытаскивать патчи из email и накатывать их, потому есть git am который применяет патчи из git-format-patch, полученные с мыла). Также костылями прикручивается поддержка больших файлов LFS или GVFS Однако все это не отменяет открытости git, которая и привела к тому, что его популярность взлетела до небес... с помощью гитхаба.
Github
Если в начале своей истории git соревновался на равных с меркуриалом, то создание https://github.com/ вырвало использование git вперед и закрепило его доминирующее положение. Именно гитхаб прикрыл сложности работы с гитом своим функционалом, что однако вылилось что у гитхаба есть и свои туториалы по гиту (https://guides.github.com/), и свои клиенты (https://desktop.github.com/), и свои надстройки над гитом. Дошло до того, что мало кто знает, что пулл-реквест - это не фича гита, а фича гитхаба git-request-pull запилен сильно позже и не обладает аналогичным функционалом.
Еще гитхаб хорошо протолкнул себя функционалом "соцсети для разработчиков" и тем, что удачно переманил кучу опенсорсных проектов с sourceforge (который к тому же знатно начал обсираться к тому времени) - что в итоге превратило гитхаб в хостинг опенсорных проектов по дефолту и в "строчку в резюме".
На данный момент у гитхаба из конкурентов атлассиановский bitbucket (тоже поддерживает git), относительно недавно еще отпочковался gitlab. А еще его купил Microsoft. По итогу git непотопляем пока не потонул github, но вероятность потонуть из-за славы мелкомягких определенно имеется.
На данный момент - default version control system а ля Нерезиновая = ДС. Что характерно, ей не является (https://blog.feld.me/posts/2018/01/git-is-not-revision-control/) без допиливания различными соглашениями, да и позиционирует себя скорее как систему контроля исходных кодов не vcs а scm.
Запилена тем самым Торвальдсом в 2005 году после того как один хитрый Ларри закрыл бесплатный доступ к BitKeeper - тогдашней vcs, использовавшейся при разработке Linux. Первая рабочая версия была готова и выкачена в использование всего за два месяца. Последствия разгребаем до сих пор.
Имеется сайт: https://git-scm.com/ , с него можно взять билды, документацию, исходники. А также книженцию Pro Git: https://git-scm.com/book/en/v2 - в которой есть информация от азов до специфичных вещей эмодзи в комментах, лол. Написание книги, кстати, проходит тоже через git (https://github.com/progit/progit2), из-за особенностей используемых средств полно мест где вовсю торчит css is awesome.
Заявляется, что у гита есть разделение на plumbing и porcelain, то бишь можно пользоваться только дружелюбным фарфором для работы нассать в писуар, но всегда есть возможность копнуть на уровень глубже и работать напрямую с сантехникой срать прямо в трубу. Где-то рядом торчит мем "всего пять комманд нужно для использования". По факту при работе с гитом до уровня сантехники приходится докапываться довольно часто ну или звать сантехника Федора иди разворачивать свежую копию репы, xkcd не врет. Связано это с историей разработки гита, целей его использования и организацией работы: git - проект с типичной unix-идеологией, состоящий из множества мелких утилит, каждая из которых делает только свою работу и делает ее хорошо. С другой стороны, каждая из утилит имеет свой синтаксис и может частично дублировать функционал другой утилиты (например есть git-apply которая применяет патчи, сгенерированные git-diff, но Линуса как-то задолбало вытаскивать патчи из email и накатывать их, потому есть git am который применяет патчи из git-format-patch, полученные с мыла). Также костылями прикручивается поддержка больших файлов LFS или GVFS Однако все это не отменяет открытости git, которая и привела к тому, что его популярность взлетела до небес... с помощью гитхаба.
Github
Если в начале своей истории git соревновался на равных с меркуриалом, то создание https://github.com/ вырвало использование git вперед и закрепило его доминирующее положение. Именно гитхаб прикрыл сложности работы с гитом своим функционалом, что однако вылилось что у гитхаба есть и свои туториалы по гиту (https://guides.github.com/), и свои клиенты (https://desktop.github.com/), и свои надстройки над гитом. Дошло до того, что мало кто знает, что пулл-реквест - это не фича гита, а фича гитхаба git-request-pull запилен сильно позже и не обладает аналогичным функционалом.
Еще гитхаб хорошо протолкнул себя функционалом "соцсети для разработчиков" и тем, что удачно переманил кучу опенсорсных проектов с sourceforge (который к тому же знатно начал обсираться к тому времени) - что в итоге превратило гитхаб в хостинг опенсорных проектов по дефолту и в "строчку в резюме".
На данный момент у гитхаба из конкурентов атлассиановский bitbucket (тоже поддерживает git), относительно недавно еще отпочковался gitlab. А еще его купил Microsoft. По итогу git непотопляем пока не потонул github, но вероятность потонуть из-за славы мелкомягких определенно имеется.
>>239134
Дропнул гит когда понял, что нужно читать книги
Дропнул гит когда понял, что нужно читать книги
Истоки создания Mercurial (ртутный, сокращенно зовется Hg) - ровно те же самые что и у Git, и изначально он рассматривался как альтернатива гиту.
И вообще, Mercurial - это лучший гит. Аналогично гиту - распределенная система контроля версий (DVCS), но поддерживает работу именно как vcs из коробки. Есть настоящие бранчи, а есть легковесные как в гите - bookmarks. Синтаксис команд менее вырвиглазный. Однако пока меркуриал пилил нормальную систему и фиксил баги - гит вырвался вперед. Добавляет проблем то, что если гит сложен снаружи, но просто внутри, то у меркуриала все наоборот - снаружи все просто, а внутри ад и израиль, что означает невозможность взять и запилить его альтернативную закрытую реализацию для создания чего-нибудь на уровне гитхаба.
Имеется сайт: https://www.mercurial-scm.org/ с билдами и туториалами. Есть туториал от Спольски: http://hginit.com , его, честно говоря, неплохо бы и почитать любителям гита.
Меркуриал поддерживается Atlassian, соответственно есть хостинг на bitbucket. В отличие от git хорошо масштабируется на гигантские проекты, поэтому Mercurial популярен у контор с большой кодовой базой: Mozilla, Facebook, разработка ОpenJDK также ведется в Hg. Гугл тоже держал свои проекты под Hg, пока не перевел все дело под внутреннюю систему Piper
И вообще, Mercurial - это лучший гит. Аналогично гиту - распределенная система контроля версий (DVCS), но поддерживает работу именно как vcs из коробки. Есть настоящие бранчи, а есть легковесные как в гите - bookmarks. Синтаксис команд менее вырвиглазный. Однако пока меркуриал пилил нормальную систему и фиксил баги - гит вырвался вперед. Добавляет проблем то, что если гит сложен снаружи, но просто внутри, то у меркуриала все наоборот - снаружи все просто, а внутри ад и израиль, что означает невозможность взять и запилить его альтернативную закрытую реализацию для создания чего-нибудь на уровне гитхаба.
Имеется сайт: https://www.mercurial-scm.org/ с билдами и туториалами. Есть туториал от Спольски: http://hginit.com , его, честно говоря, неплохо бы и почитать любителям гита.
Меркуриал поддерживается Atlassian, соответственно есть хостинг на bitbucket. В отличие от git хорошо масштабируется на гигантские проекты, поэтому Mercurial популярен у контор с большой кодовой базой: Mozilla, Facebook, разработка ОpenJDK также ведется в Hg. Гугл тоже держал свои проекты под Hg, пока не перевел все дело под внутреннюю систему Piper
Subversion - он же SVN, централизованная система контроля версий (CVCS) от Apache. Предыдущая дефолтная система контроля версий - по этой причине в основном преимущества гита описывают в основном сравнивая его с svn.
Основной сайт: https://subversion.apache.org/ Имеется книга, известная как "THE Subversion Book" - http://svnbook.red-bean.com/
Концептуально значительно проще, чем распределенные системы. До сих пор часто используется в проектах, которые версионируют не только исходный код, но и ресурсы, а также требуют различные права доступа не на уровне репозиториев, а на уровне файлов. Все менее и менее популярен, но проживет еще очень долго за счет старых, мелких проектов и бедного энтерпрайза.
Основной сайт: https://subversion.apache.org/ Имеется книга, известная как "THE Subversion Book" - http://svnbook.red-bean.com/
Концептуально значительно проще, чем распределенные системы. До сих пор часто используется в проектах, которые версионируют не только исходный код, но и ресурсы, а также требуют различные права доступа не на уровне репозиториев, а на уровне файлов. Все менее и менее популярен, но проживет еще очень долго за счет старых, мелких проектов и бедного энтерпрайза.
Perforce, он же P4, нонче Perforce Helix - древнючая корпоративная система контроля версий, которая лет пять назад проснулась от сладкого сна под покрывалом абсолютного лидерства в толстожопом энтерпрайзе и начала допиливать кучу функционала в свою CVCS Perforce, добавляя туда распределенный функционал, интеграцию с гитом и кучу решений для ALM из выкупленной шведской Hansoft, перемеиновав это дело в Perforce Helix Core. И что самое неожиданное для Perforce - наличие бесплатной версии для <5 юзеров (https://www.perforce.com/downloads/helix-core-p4d)
В России крайне малоизвестна, ибо была целиком и полностью платной, но довольно популярна в мире. Что уж говорить, до Mercurial гугл использовал P4, мелкомягкие делали свой TFVC с оглядкой на P4, а сами использовали внутри себя приватный форк P4 под названием SourceDepot. Netflix до того как переползти на Stash использовал P4, Disney до сих пор его использует. Вообще говоря в геймдеве 90% крупных контор используют P4 - что Ubisoft и EA, что CD Projekt RED.
За пределами экосистемы P4 известен ее кусок - утилита P4Merge, которая одна из первых популяризовала отображение 3-way merge, а также поддерживает осмысленный diff не только текста, но и изображений и документов
В России крайне малоизвестна, ибо была целиком и полностью платной, но довольно популярна в мире. Что уж говорить, до Mercurial гугл использовал P4, мелкомягкие делали свой TFVC с оглядкой на P4, а сами использовали внутри себя приватный форк P4 под названием SourceDepot. Netflix до того как переползти на Stash использовал P4, Disney до сих пор его использует. Вообще говоря в геймдеве 90% крупных контор используют P4 - что Ubisoft и EA, что CD Projekt RED.
За пределами экосистемы P4 известен ее кусок - утилита P4Merge, которая одна из первых популяризовала отображение 3-way merge, а также поддерживает осмысленный diff не только текста, но и изображений и документов
CVS
Concurrent Versioning System - предшественник SVN, она же SVN под дезоморфином. Разработка гита шла под девизом "как сделать хорошо? - сделать не так, как в CVS". Крайне медленная система и без поддержки транзакций - так что коммит мог быть успешным наполовину. Официально померла с последним стабильным релизом в 2008, что характерно, изначально была написана как набор шелл-скриптов поверх исключительно локальной системы RCS до SourceDepot мелкомягкие использовали приватный форк RCS под названием SLM, но у той последний стабильный релиз был аж в 2015
Visual SourceSafe
Известная как говносос-контрол от мелкомягких. Плохо все. И не удивительно - была куплена в спешке в 1994 по дешевке лишь бы хоть с чем-то выпустить релиз VisualStudio. Внутри самой Microsoft не использовалась от слова совсем, и была удачно похоронена заменой на TFS
ClearCase
Поделие не для "простого" толстожопого энтерпрайза, а самого настоящего кровавого. Потому и куплено IBM. Очень медленная CVCS, которая, однако поддерживает распределенные сценарии... на базе проприетарной сетевой файловой системы. Максимум корпоративности, максимум ебли, минимум скорости. Система еще жива и даже развивается. Держит гигантские проекты и странные сценарии, но требует много поддержки. Кровавому энтерпрайзу слезть с нее очень дорого, так что помирать будет еще долго.
Concurrent Versioning System - предшественник SVN, она же SVN под дезоморфином. Разработка гита шла под девизом "как сделать хорошо? - сделать не так, как в CVS". Крайне медленная система и без поддержки транзакций - так что коммит мог быть успешным наполовину. Официально померла с последним стабильным релизом в 2008, что характерно, изначально была написана как набор шелл-скриптов поверх исключительно локальной системы RCS до SourceDepot мелкомягкие использовали приватный форк RCS под названием SLM, но у той последний стабильный релиз был аж в 2015
Visual SourceSafe
Известная как говносос-контрол от мелкомягких. Плохо все. И не удивительно - была куплена в спешке в 1994 по дешевке лишь бы хоть с чем-то выпустить релиз VisualStudio. Внутри самой Microsoft не использовалась от слова совсем, и была удачно похоронена заменой на TFS
ClearCase
Поделие не для "простого" толстожопого энтерпрайза, а самого настоящего кровавого. Потому и куплено IBM. Очень медленная CVCS, которая, однако поддерживает распределенные сценарии... на базе проприетарной сетевой файловой системы. Максимум корпоративности, максимум ебли, минимум скорости. Система еще жива и даже развивается. Держит гигантские проекты и странные сценарии, но требует много поддержки. Кровавому энтерпрайзу слезть с нее очень дорого, так что помирать будет еще долго.
>>239263
Давай про fossil пили
Давай про fossil пили
Fossil
Как написано для/с SQLite, так и развивается. Относительно молодая DVCS со встроенным баг-трекингом и вики. Есть сайт: https://www.fossil-scm.org/ Очень популярна при выборе "что, если не гит", с мотивацией https://sqlite.org/whynotgit.html
darcs
DVCS на хаскеле. Есть сайт: http://darcs.net Система контроля версий с алгеброй патчей и публикациями вида ftp://ftp.math.ucla.edu/pub/camreport/cam09-83.pdf
(Формализация системы патчей DARCS с использованием обратных полугрупп)
Как написано для/с SQLite, так и развивается. Относительно молодая DVCS со встроенным баг-трекингом и вики. Есть сайт: https://www.fossil-scm.org/ Очень популярна при выборе "что, если не гит", с мотивацией https://sqlite.org/whynotgit.html
darcs
DVCS на хаскеле. Есть сайт: http://darcs.net Система контроля версий с алгеброй патчей и публикациями вида ftp://ftp.math.ucla.edu/pub/camreport/cam09-83.pdf
(Формализация системы патчей DARCS с использованием обратных полугрупп)
>>239277
Писали те же люди что и SQLite, поэтому охуено братан. Гит нинужен.
>Как написано для/с SQLite
Писали те же люди что и SQLite, поэтому охуено братан. Гит нинужен.
>>239280
Да не только. Исходники SQLite - в Fossil. Fossil хранит данные - в SQLite. Типичные курица-яйцо а началось все как обычно с CVS
>те же люди
Да не только. Исходники SQLite - в Fossil. Fossil хранит данные - в SQLite. Типичные курица-яйцо а началось все как обычно с CVS
>>239134
Какой-то очередной гит-хейтер. Пост полон субъективизма, желчи и передергиваний.
Какой-то очередной гит-хейтер. Пост полон субъективизма, желчи и передергиваний.
>>239175
OpenJDK - это "гигантский" проект, а Линукс - это так, хобби-поделка на пару экранов кода, да?
OpenJDK - это "гигантский" проект, а Линукс - это так, хобби-поделка на пару экранов кода, да?
>>239305
Скачиваю архивом:
https://github.com/dmlloyd/openjdk - 185мб
https://github.com/torvalds/linux/ - 189мб
Про разницу в объеме истории я молчу.
Алсо, https://twitter.com/feross/status/459259593630433280
Скачиваю архивом:
https://github.com/dmlloyd/openjdk - 185мб
https://github.com/torvalds/linux/ - 189мб
Про разницу в объеме истории я молчу.
Алсо, https://twitter.com/feross/status/459259593630433280
>>239301
Линукс по факту в одной репе не содержится, полную историю разве что у Линуса в мейл-листах можно собрать
Линукс по факту в одной репе не содержится, полную историю разве что у Линуса в мейл-листах можно собрать
>>239338
Линукс не на гитхабе хостится, алло. А на kernel.org. И там кроме линусовского мейнлайна ещё куча деревьев у мейнтейнеров https://git.kernel.org/pub/scm/
Алсо Facebook от таких реп перелез на hg
Линукс не на гитхабе хостится, алло. А на kernel.org. И там кроме линусовского мейнлайна ещё куча деревьев у мейнтейнеров https://git.kernel.org/pub/scm/
Алсо Facebook от таких реп перелез на hg
>>239347
Ты блядь может уже глаза откроешь? У опенждк точно так же еще туева хуча реп, основная зеркалируется на гитхабе. "Большая кодовая база" "гигантского" опенждк - это 185мб сорцов в основной репе, а хобби-поделка торвальдса - это 189мб сорцов в основной репе. Нет бы блядь просто сказать "ок, это был хуевый пример".
Алсо,
-.\\
Алсо, у фейсбука не хг как таковой, а собственная них-поделка на его основе
>https://github.com/dmlloyd/openjdk - 185мб
>https://github.com/torvalds/linux/ - 189мб
>Mercurial популярен у контор с большой кодовой базой: Mozilla, Facebook, разработка ОpenJDK также ведется в Hg
>https://github.com/dmlloyd/openjdk - 185мб
>https://github.com/torvalds/linux/ - 189мб
Ты блядь может уже глаза откроешь? У опенждк точно так же еще туева хуча реп, основная зеркалируется на гитхабе. "Большая кодовая база" "гигантского" опенждк - это 185мб сорцов в основной репе, а хобби-поделка торвальдса - это 189мб сорцов в основной репе. Нет бы блядь просто сказать "ок, это был хуевый пример".
Алсо,
>Линукс не на гитхабе хостится
>только что дали ссылку на официальное(с)(тм) зеркало линукса на гитхабе
-.\\
Алсо, у фейсбука не хг как таковой, а собственная них-поделка на его основе
>>239301
>>239312
>>239380
Это конечно показательно, что при гиге у мозиллы и 50 с хуем гигах у фейсбука доебываются до 200 метров у jdk. OpenJDK и внутренняя кухня HotSpot вообще хреновый пример, Mercurial там использовался исключительно из-за вкусовщины - в 2006-2008 годах это был самый популярный выбор у JavaEE. Да и не монорепа там, хотя два года назад пытались слить весь лес воедино.
А сравнивать монорепы с гитхабовским слепком linux kernel вообще бред это как не различать repo и working copy, туда попадают лишь результаты слияния патчей, всей истории ни в одном репозитории полностью нет.
>>239312
>>239380
Это конечно показательно, что при гиге у мозиллы и 50 с хуем гигах у фейсбука доебываются до 200 метров у jdk. OpenJDK и внутренняя кухня HotSpot вообще хреновый пример, Mercurial там использовался исключительно из-за вкусовщины - в 2006-2008 годах это был самый популярный выбор у JavaEE. Да и не монорепа там, хотя два года назад пытались слить весь лес воедино.
А сравнивать монорепы с гитхабовским слепком linux kernel вообще бред это как не различать repo и working copy, туда попадают лишь результаты слияния патчей, всей истории ни в одном репозитории полностью нет.
>>239299
То ли дело у гитхаб-утят.
Больше пяти команд не надо.
@
Git подходит для всего. Проблем никогда не бывает, это все - заговор
@
Освоить git - дело пяти минут, это может сделать даже слепоглухонемая макака.
На деле выходит правда, что ничего кроме github и не видали и пользоваться не могут... гитом в принципе тоже.
То ли дело у гитхаб-утят.
Больше пяти команд не надо.
@
Git подходит для всего. Проблем никогда не бывает, это все - заговор
@
Освоить git - дело пяти минут, это может сделать даже слепоглухонемая макака.
На деле выходит правда, что ничего кроме github и не видали и пользоваться не могут... гитом в принципе тоже.
Как на меркуриале локально перекинуть данные на другой пк? В git нашёл способ:
git stash save myWork
git stash show -p > myWork.txt
git apply myWork.txt
git stash clear
А как с хг так же?
git stash save myWork
git stash show -p > myWork.txt
git apply myWork.txt
git stash clear
А как с хг так же?
>>239418
Блин, сонный уже. Не данные перекинуть, а изменения. Идеально было бы коммит локальный
перекинуть
Блин, сонный уже. Не данные перекинуть, а изменения. Идеально было бы коммит локальный
перекинуть
>>239419
hg export для генерации патча, например
hg export -r 123:125 > exported.diff
возьмет изменения ревизий с 123 по 125 и сгенерирует патч exported.diff
hg import для применения патча, например
hg import exported.diff --no-commit накатит изменения из exported.diff на рабочую копию, но без коммита
hg export для генерации патча, например
hg export -r 123:125 > exported.diff
возьмет изменения ревизий с 123 по 125 и сгенерирует патч exported.diff
hg import для применения патча, например
hg import exported.diff --no-commit накатит изменения из exported.diff на рабочую копию, но без коммита
>>239411
Как и, не поверишь, у мозиллы. Как и у фейсбука по сути (потому что повторюсь, у них там своя поделка, и выбирали они по принципу "лично нам проще все перепилить будет").
Не ебу, что ты в итоге хотел сказать, если честно.
>>239416
Найс проекции, держи в курсе.
>Mercurial там использовался исключительно из-за вкусовщины
Как и, не поверишь, у мозиллы. Как и у фейсбука по сути (потому что повторюсь, у них там своя поделка, и выбирали они по принципу "лично нам проще все перепилить будет").
>не монорепа там
>сравнивать монорепы с гитхабовским слепком linux kernel вообще бред
>не монорепа там
Не ебу, что ты в итоге хотел сказать, если честно.
>>239416
Найс проекции, держи в курсе.
Да
>>239644
Mercurial сервер на Rust, зовется Mononoke. А еще куча расширений для mercurial, доступных на bitbucket.org/facebook, ну и патчей заслали. То бишь не своя поделка, а допиливание общей.
>своя поделка
Mercurial сервер на Rust, зовется Mononoke. А еще куча расширений для mercurial, доступных на bitbucket.org/facebook, ну и патчей заслали. То бишь не своя поделка, а допиливание общей.
>>239848
Там автор совершенно поехал, реализует в fossil форумы по email. Подумай, стоит ли перекатываться на DVCS, где решения принимают подобные люди.
Нет rebase ни в каком виде. А так, для мелких проектов в принципе норм.
Там автор совершенно поехал, реализует в fossil форумы по email. Подумай, стоит ли перекатываться на DVCS, где решения принимают подобные люди.
> Какие подводные?
Нет rebase ни в каком виде. А так, для мелких проектов в принципе норм.
Подскажите, пожалуйста.
Git
Значит у меня есть две ветки.
branch 1: A
branch 2 : \ - B -C
Буквами обозначаются комиты. Дальше я чекаутюсь на ветку branch 1 и мёрджу в неё branch 2. И вместо того чтобы сделать степ форвард она говорит что у меня конфликт в одном файле. Подскажите, как мне вместо того чтобы слеплять вместе файл из говна и палок двух разных веток просто использовать полностью файл из ветки branch 2 ?
По логике вещей можно чекаутится между комитами а не между ветками? Подскажите последовательность команд плиз
Git
Значит у меня есть две ветки.
branch 1: A
branch 2 : \ - B -C
Буквами обозначаются комиты. Дальше я чекаутюсь на ветку branch 1 и мёрджу в неё branch 2. И вместо того чтобы сделать степ форвард она говорит что у меня конфликт в одном файле. Подскажите, как мне вместо того чтобы слеплять вместе файл из говна и палок двух разных веток просто использовать полностью файл из ветки branch 2 ?
По логике вещей можно чекаутится между комитами а не между ветками? Подскажите последовательность команд плиз
Анон спасай, научи уму разуму, недавно с подобной проблемой писал, но теперь еще страннее все.
добавляю локально файлы в проект ну и изменяю уже залитые в первый раз.
делаю
add .
commit -a -m "text"
push origin master
все залито все красиво, пишет мне.
захожу в удаленный репозиторий, новых файлов нет, изменения в существующих есть. коммит отображается, если заходишь в него, пишет про изменения тех не отображаемых файлов.
что я делаю не так?
добавляю локально файлы в проект ну и изменяю уже залитые в первый раз.
делаю
add .
commit -a -m "text"
push origin master
все залито все красиво, пишет мне.
захожу в удаленный репозиторий, новых файлов нет, изменения в существующих есть. коммит отображается, если заходишь в него, пишет про изменения тех не отображаемых файлов.
что я делаю не так?
>>241345
-a нинада, оно не коммитит новые файлы
а так смотри документацию, пиши в консоли git help <команда>, там все написано, например git help commit напишет тебе
-a, --all
Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.
-a нинада, оно не коммитит новые файлы
а так смотри документацию, пиши в консоли git help <команда>, там все написано, например git help commit напишет тебе
-a, --all
Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.
>>241703
спасибо, но я видимо с ветряными мельницами боролся, но все равно не понятно.
В общем зашел в репозиторий с другого пк(не залогинился) и перкрасно вижу все файлы, а если логинюсь то вижу только первые.. эээ это какие-то косяки На битбакете, или там настроить чего надо?
спасибо, но я видимо с ветряными мельницами боролся, но все равно не понятно.
В общем зашел в репозиторий с другого пк(не залогинился) и перкрасно вижу все файлы, а если логинюсь то вижу только первые.. эээ это какие-то косяки На битбакете, или там настроить чего надо?
Вообще гит иногда подкидывает проблемы. Погляди, пользуется ли у тебя IDE соурс контролом. И если да, то отключи это в ИДЕ. Я заметил, что если ИДЕ пользует соурс контрол, то лучше делать всё через иде, а если хочешь через терминал, то отрубай соурс контрол в ИДЕ.
>>241989
Он почти закончил уже. Но я надеюсь, что "e-mail форумы" постигнет такая же судьба, как и предыдущие гениальные идеи. Ни сама fossil, ни sqlite (использующие fossil для кода), не пользуются встроенным багтрекером (разработка идет в мэйллистах). Багтрекер все еще поддерживается, но он неудобен, за ним невозможно следить, он легко заспамливается. На данный момент он фактически не развивается и нужен лишь, чтобы хвастаться, мол "смотрите, у нас есть векторный распределенный багтрекер. То же самое и со встроенной вики - убожество без задач. Ее основной юзкейс на данный момент - сделать "Welcome to my repository", как README.md на гитхабе. После того, как появилась возможность рендерить в веб-интерфейсе .wiki и .md файлы из репозитория (и даже из чекаута), можно поставить /doc/trunk/README.md главной страницей и вообще не пользоваться вики.
Я пользуюсь fossil очень-очень давно, практически с самого начала, но в последние годы все чаще хочется сжечь и переписать форкнуть и повыкидывать оттуда всякий бесполезный мусор, запиленный вместо решения насущных проблем.
Он почти закончил уже. Но я надеюсь, что "e-mail форумы" постигнет такая же судьба, как и предыдущие гениальные идеи. Ни сама fossil, ни sqlite (использующие fossil для кода), не пользуются встроенным багтрекером (разработка идет в мэйллистах). Багтрекер все еще поддерживается, но он неудобен, за ним невозможно следить, он легко заспамливается. На данный момент он фактически не развивается и нужен лишь, чтобы хвастаться, мол "смотрите, у нас есть векторный распределенный багтрекер. То же самое и со встроенной вики - убожество без задач. Ее основной юзкейс на данный момент - сделать "Welcome to my repository", как README.md на гитхабе. После того, как появилась возможность рендерить в веб-интерфейсе .wiki и .md файлы из репозитория (и даже из чекаута), можно поставить /doc/trunk/README.md главной страницей и вообще не пользоваться вики.
Я пользуюсь fossil очень-очень давно, практически с самого начала, но в последние годы все чаще хочется сжечь и переписать форкнуть и повыкидывать оттуда всякий бесполезный мусор, запиленный вместо решения насущных проблем.
>>239087 (OP)
Аноны, вопрос есть.
Допустим есть у меня папка с проектом NetBeans IDE 8.2 javafx и я хочу выложить исходник на гитхаб.
Какие папки не нужные и какие оставить? Оставить только src и build.xml, manifest.mf?
Что делать с папками nbproject и build?
Аноны, вопрос есть.
Допустим есть у меня папка с проектом NetBeans IDE 8.2 javafx и я хочу выложить исходник на гитхаб.
Какие папки не нужные и какие оставить? Оставить только src и build.xml, manifest.mf?
Что делать с папками nbproject и build?
>>242264
...и получится медленный, кривой гит. ;)
>форкнуть и повыкидывать оттуда всякий бесполезный мусор
...и получится медленный, кривой гит. ;)
>>242595
Очень портабельный и весьма удобный гит без зависимостей.
Очень портабельный и весьма удобный гит без зависимостей.
>>242582
.gitignore
.gitignore
Вот читаю ProGit, в чем прикол rebase?
Каким образом это более чистая история? С merge понятно - человек сделал ответвление, локально у себя накоммитил пока работал, и потом влил в основную ветку. А с rebase - какой-то долбаеб 3-4 раза коммитил в основную ветку. Не понятно как и зачем.
Но вот тут уже вроде более полезный случай, но сразу вопрос - а почему не сделать ответвление от мастера сразу? Зачем делать ветку для изменения клиента, основываясь на коммите из ветки об изменении сервера? Человек создает проблему, чтобы решить ее.
>cleaner history
Каким образом это более чистая история? С merge понятно - человек сделал ответвление, локально у себя накоммитил пока работал, и потом влил в основную ветку. А с rebase - какой-то долбаеб 3-4 раза коммитил в основную ветку. Не понятно как и зачем.
>второй пик
Но вот тут уже вроде более полезный случай, но сразу вопрос - а почему не сделать ответвление от мастера сразу? Зачем делать ветку для изменения клиента, основываясь на коммите из ветки об изменении сервера? Человек создает проблему, чтобы решить ее.
>>247254
РИБЕЙЗ НИНУЖОН!!!1
НИКАКИМ, НИНУЖНО!!11
Ну там же написано прямо на твоей картинке, в серверной ветке запилили фичу, но в мастер пока не вмерджили, а тебе уже сейчас надо начать работать на клиент-кодом, который использует эту фичу. Ну а потом вмерджат - ты сразу хоп-хоп, чики-брики и в дамки.
>в чем прикол rebase?
РИБЕЙЗ НИНУЖОН!!!1
>Каким образом это более чистая история?
НИКАКИМ, НИНУЖНО!!11
>Зачем делать ветку для изменения клиента, основываясь на коммите из ветки об изменении сервера?
Ну там же написано прямо на твоей картинке, в серверной ветке запилили фичу, но в мастер пока не вмерджили, а тебе уже сейчас надо начать работать на клиент-кодом, который использует эту фичу. Ну а потом вмерджат - ты сразу хоп-хоп, чики-брики и в дамки.
40 Кб, 787x95>>247345
А если не троллить?
А, ну тогда понятно.
Ещё вопрос по этому пику. Почему это не нужны снапшоты на remote repository? Раз это collaboration point, то там как раз должны быть все эти снапшоты,чтобы с них fetchить и пушить к ним, нет?
>НИНУЖОН 1!!11!11
А если не троллить?
>работать на клиент-кодом, который использует эту фичу
А, ну тогда понятно.
Ещё вопрос по этому пику. Почему это не нужны снапшоты на remote repository? Раз это collaboration point, то там как раз должны быть все эти снапшоты,чтобы с них fetchить и пушить к ним, нет?
>>247860
Нихуя не понял вопрос. В ремот репе нет рабочей копии, ну блядь, стейджинг эрии, сырых вычекаутенных сырцов, потому что ну типа он ремот, непосредственно в нем никто не кодит, все кодят на своих машинах и пушат туда. Перечитай короче, ты неправильно понял походу.
Нихуя не понял вопрос. В ремот репе нет рабочей копии, ну блядь, стейджинг эрии, сырых вычекаутенных сырцов, потому что ну типа он ремот, непосредственно в нем никто не кодит, все кодят на своих машинах и пушат туда. Перечитай короче, ты неправильно понял походу.
37 Кб, 530x508Решил я значит перейти на bitbucket
>>239296
Что это подразумевает? Создать несколько папок и в каждой чтобы была отдельная гита? Ну наверное можно и так сделать. Только зачем?
Что это подразумевает? Создать несколько папок и в каждой чтобы была отдельная гита? Ну наверное можно и так сделать. Только зачем?
>>249733
Тю, обиделась :)
Тю, обиделась :)
Няши, подскажите пожалуйста название "последнего большого проекта на Hg, который ушёл на другую систему контроля версий". Я помню, я читал 2-3 года назад новость, а найти не могу, потому что в названии было не про "последний большой проект", а просто название этого проекта
1
>>258910
Идет обсуждение миграции OpenJDK. Но пока только обсуждение.
Идет обсуждение миграции OpenJDK. Но пока только обсуждение.
Ананасы, вопрос по гиту.
Есть команда создания ветки git checkout -b branchname
Тут узнал что есть такой вариант ещё git branch new existing
Она создаёт новую ветку основываясь на старой.
В чём различие будет? Поясните, пожалуйста.
Есть команда создания ветки git checkout -b branchname
Тут узнал что есть такой вариант ещё git branch new existing
Она создаёт новую ветку основываясь на старой.
В чём различие будет? Поясните, пожалуйста.
>>241200
самому стало интересно, а там оказыается какойто израиль https://stackoverflow.com/questions/914939/simple-tool-to-accept-theirs-or-accept-mine-on-a-whole-file-using-git
Хорошо что для этих целей использую жидбрейнс поделки
самому стало интересно, а там оказыается какойто израиль https://stackoverflow.com/questions/914939/simple-tool-to-accept-theirs-or-accept-mine-on-a-whole-file-using-git
Хорошо что для этих целей использую жидбрейнс поделки
>>270368
наверно это создаст новую ветку на основе той, в которой ты сейчас.
Ну а во втором варианте ты сам укажешь основу.
Но это не точно.
>git checkout -b branchname
наверно это создаст новую ветку на основе той, в которой ты сейчас.
Ну а во втором варианте ты сам укажешь основу.
Но это не точно.
>>239101
Git - индустриальный стандарт. Это говно ещё лет на 10. Есть надежда, что он переродится во что-то юзабильное с ветками. Но пока жрём кактусы.
>>239134
Даже если утонет github, его заменитель будет тоже поддерживать git.
sad but true, но это красноглазое говно будет с нами ещё долго.
>>239175
Mercurial няшка, но его не используют.
Git - индустриальный стандарт. Это говно ещё лет на 10. Есть надежда, что он переродится во что-то юзабильное с ветками. Но пока жрём кактусы.
>>239134
Даже если утонет github, его заменитель будет тоже поддерживать git.
sad but true, но это красноглазое говно будет с нами ещё долго.
>>239175
Mercurial няшка, но его не используют.
>>239347
в случае git нельзя сказать что "что то где то хостится"
да, есть репа на kernel.org, есть на гитхабе, но есть и у десятков тысяч кодеров и все они равноправны
я правильно понимаю?
в случае git нельзя сказать что "что то где то хостится"
да, есть репа на kernel.org, есть на гитхабе, но есть и у десятков тысяч кодеров и все они равноправны
я правильно понимаю?
>>239848
мне не нравится, что fossil позиционируется как комплексное решение, помимо vc там еще и багтрекер, вики, форум..
причем в исходниках проекта это выглядит все как монолит..
не самый лучший подход imho
мне не нравится, что fossil позиционируется как комплексное решение, помимо vc там еще и багтрекер, вики, форум..
причем в исходниках проекта это выглядит все как монолит..
не самый лучший подход imho
>>242264
да, да
причем весь этот функционал в исходниках кода объединен в один проект и все это написано на дедушкином си
да, да
причем весь этот функционал в исходниках кода объединен в один проект и все это написано на дедушкином си
>>270551
Git создавался именно что с расчетом, что никакого единого источника истины нет и все репозитории равноправны. На деле же в большинстве случаев заводят какой-нибудь origin-репозиторий (на гитхабе ли, на локальном сервере и т.п.) и всю работу проводят через него, игнорируя возможность, например, напрямую заслать коммит в vasya/master минуя origin/master
У линукса в этом плане гибридная модель, васяны засылают патчи равноправным мейнтейнерам, мейнтейнеры работают со своими репами и засылают патчи Линусу, Линус впиливает патчи в свою репу на своем условном комплюхтере. Формально все равноправны, реально с комплюхтера Линуса репа зеркалируется на kernel.org, а оттуда на гитхаб, ты можешь форкнуть/собрать любую репу, но пользуются все Линусовской
Git создавался именно что с расчетом, что никакого единого источника истины нет и все репозитории равноправны. На деле же в большинстве случаев заводят какой-нибудь origin-репозиторий (на гитхабе ли, на локальном сервере и т.п.) и всю работу проводят через него, игнорируя возможность, например, напрямую заслать коммит в vasya/master минуя origin/master
У линукса в этом плане гибридная модель, васяны засылают патчи равноправным мейнтейнерам, мейнтейнеры работают со своими репами и засылают патчи Линусу, Линус впиливает патчи в свою репу на своем условном комплюхтере. Формально все равноправны, реально с комплюхтера Линуса репа зеркалируется на kernel.org, а оттуда на гитхаб, ты можешь форкнуть/собрать любую репу, но пользуются все Линусовской
>>270681
Я фоссил давно юзаю, встроеной вики и доками пару раз пользовался, мне не мешает, а вот залупа вроде гит с 2 миллиардами коммандами и параметрами меня вымораживает.
Я фоссил давно юзаю, встроеной вики и доками пару раз пользовался, мне не мешает, а вот залупа вроде гит с 2 миллиардами коммандами и параметрами меня вымораживает.
>>270739
Расскажи юзкейс. Почему нельзя было отредактировать documentation.md и закомитить?
> встроеной вики и доками пару раз пользовался
Расскажи юзкейс. Почему нельзя было отредактировать documentation.md и закомитить?
>>270745
Я доками пользуюсь через браузерный просмотровщик маркдауна, запущенный сервер фоссила не нужен.
>Почему нельзя было отредактировать documentation.md и закомитить?
Я доками пользуюсь через браузерный просмотровщик маркдауна, запущенный сервер фоссила не нужен.
Эт самое, а даунский ответ у вас спросить можно? Вот работаю я на РАБоте по окологитфлову, под каждую фичу свою ветку создаю. Допустим, сделал фичу 1, потом 2, 3, 4, у каждой своя ветка. И тут на пятой я обнаружил, что на первой ветке где-то обосрался, потом починил все это, а как мне дальше изменения применить к остальным веткам? Не вручную мержить же.
>>289207
Потом не мерджнуть фичу5 в фичу1 без дополнительного коммита разве нет? Лучше git rebase
Потом не мерджнуть фичу5 в фичу1 без дополнительного коммита разве нет? Лучше git rebase
>>289213
Да я просто мимо шел, лол.
Да я просто мимо шел, лол.
134 Кб, 500x713Какая система контроля версий хороша для бинарников? Или проще складывать по папочкам v1, v2?
>>290781
Git LFS
Git LFS
>>290781
Для бинарников - любая централизованная из адекватных, что SVN, что TFVC, что Perforce.
С децентрализованными либо страдать (раздувать локальную копию репозитория), либо костылями прикручивать, аки Git LFS (что означает наличие централизованного сервера с бинарями и дополнительную еблю с репой для поддержки этого дела)
Для бинарников - любая централизованная из адекватных, что SVN, что TFVC, что Perforce.
С децентрализованными либо страдать (раздувать локальную копию репозитория), либо костылями прикручивать, аки Git LFS (что означает наличие централизованного сервера с бинарями и дополнительную еблю с репой для поддержки этого дела)
>>290900
Возможно ли как-то без двойного копирования файлов? Ведь надо поднять репозиторий, а потом ещё с ним работать.
Возможно ли как-то без двойного копирования файлов? Ведь надо поднять репозиторий, а потом ещё с ним работать.
Господа, я тут дико обосрался на работе с гитом. Скачал репозиторий проекта, сделал свой ебучий таск, в процессе серанул несколько коммитов, затем с меня еще один человек коммит сделал, а потом я еще сверху. Собрался это в репозиторий запушить, а хуй там, оказалось у меня стоит мой дефолтный емейл, а репозиторий требует другой, который гитлабовский, а с моим запушить не дает. В общем, мне каким-то образом нужно теперь в этих коммитах изменить почту. Как это сделать без регистрации и смс максимально простым способом?
>>270368
Checkout -b это создать и перейти, две команды в одной. Как pull --rebase или commit -m
Checkout -b это создать и перейти, две команды в одной. Как pull --rebase или commit -m
>>295515
Rebase -i, засквошь в один, резетни хед и закоммить заново
Можно сразу резетнуть n-последних, если история важна
Rebase -i, засквошь в один, резетни хед и закоммить заново
Можно сразу резетнуть n-последних, если история важна
>>295515
Нет, поменять почту в коммитах нельзя (учитывается при подсчете sha-1 хеша) - поэтому нужно создать новые коммиты. Вариантов хренова туча,rebase, rebase -i ли, или же просто reset --soft... Особенно интересно вот это:
Это человек тебе коммит в твою локальную репу засунул? Или ты у себя сделал два коммита, потом чувак влил один коммент в репу проекта, а потом ты у себя еще два коммита сделал?
Нет, поменять почту в коммитах нельзя (учитывается при подсчете sha-1 хеша) - поэтому нужно создать новые коммиты. Вариантов хренова туча,rebase, rebase -i ли, или же просто reset --soft... Особенно интересно вот это:
>затем с меня еще один человек коммит сделал
Это человек тебе коммит в твою локальную репу засунул? Или ты у себя сделал два коммита, потом чувак влил один коммент в репу проекта, а потом ты у себя еще два коммита сделал?
Ребята, помогите советом.
Короче, я пилил на проекте в парадигме близкой к гитфлоу -- на каждую задачу отдельная ветка и все это постепенно мерджу в девелоп, а затем после тестов вливаю в мастер.
Случилось так, что я делал задачи A, B и C и завершая, каждую мержил с девелопом, в итоге у меня девелоп актуален на задаче С.
И тут шеф требует влить в мастер не все 3 задачи, а только B и C, а A как-нибудь потом. Проблема в том, что начиная очередную задачу, я отпочковывался от девелопа, так что ветка B уже сожержит в себе код ветки A, например, а ветка C уже содержит A и B.
Так как мне залить в мастер только B и C без кода ветки A и не обосраться, чтобы потом можно было безболезнено влить A?
Короче, я пилил на проекте в парадигме близкой к гитфлоу -- на каждую задачу отдельная ветка и все это постепенно мерджу в девелоп, а затем после тестов вливаю в мастер.
Случилось так, что я делал задачи A, B и C и завершая, каждую мержил с девелопом, в итоге у меня девелоп актуален на задаче С.
И тут шеф требует влить в мастер не все 3 задачи, а только B и C, а A как-нибудь потом. Проблема в том, что начиная очередную задачу, я отпочковывался от девелопа, так что ветка B уже сожержит в себе код ветки A, например, а ветка C уже содержит A и B.
Так как мне залить в мастер только B и C без кода ветки A и не обосраться, чтобы потом можно было безболезнено влить A?
>>295644
Создаешь 3 новые ветки для фич A, B, C на основе мастера.
А потом вилочкой сука чистишь все это дерьмо. Черри пикаешь нужные коммиты из старых фаршмачных веток в новые, сворачиваешь клубочком и плачешь.
На выходе будут 3 ветки с фичами готовые для мержа с мастером.
Создаешь 3 новые ветки для фич A, B, C на основе мастера.
А потом вилочкой сука чистишь все это дерьмо. Черри пикаешь нужные коммиты из старых фаршмачных веток в новые, сворачиваешь клубочком и плачешь.
На выходе будут 3 ветки с фичами готовые для мержа с мастером.
>>295694
Спасибо за совет.
Я тут пораскинул и вот еще что придумал.
Короче, я заливаю ветку С, то есть весь код, выковыривая код ветки А. Затем, когда придет время заливать задачу А, я откачусь на нынешнее состояние и сделаю мердж, но уже без выковыриваний.
Как идея?
Спасибо за совет.
Я тут пораскинул и вот еще что придумал.
Короче, я заливаю ветку С, то есть весь код, выковыривая код ветки А. Затем, когда придет время заливать задачу А, я откачусь на нынешнее состояние и сделаю мердж, но уже без выковыриваний.
Как идея?
Ананасы, такой вопрос по гиту.
Есть ветка dev, когда решаю что-то переписать/добавить новое то делаю ответвление от неё допустим feature, а потом мержу с ней и ветку удаляю.
Если я не буду удалять feature, а потом буду коммитить в dev и захочу переключиться на старую ветку feature, то коммитов в ней не будет.
Вопрос такой: как добавить коммиты из в dev в feature
Есть ветка dev, когда решаю что-то переписать/добавить новое то делаю ответвление от неё допустим feature, а потом мержу с ней и ветку удаляю.
Если я не буду удалять feature, а потом буду коммитить в dev и захочу переключиться на старую ветку feature, то коммитов в ней не будет.
Вопрос такой: как добавить коммиты из в dev в feature
>>297883
А нельзя только последний? Он не перетащит за собой остальные?
> Можешь cherry-pick'ом нужные коммиты перекинуть.
А нельзя только последний? Он не перетащит за собой остальные?
>>297909
Остальные не перетащит, в этом и фишка.
Он берет только те изменения, которые были внесены конкретным коммитом, без учета остальных и без слияния с веткой.
Остальные не перетащит, в этом и фишка.
Он берет только те изменения, которые были внесены конкретным коммитом, без учета остальных и без слияния с веткой.
>>297914
Тут еще главное не забыть что GIT тупо хранит снимки целых файлов, он понятия не имеет где и какая часть файла изменилась.
Иными словами если у тебя все коммиты редактировали один файл то каждый из них содержит в себе все изменения предыдущих.
>Он берет только те изменения, которые были внесены конкретным коммитом, без учета остальных и без слияния с веткой.
Тут еще главное не забыть что GIT тупо хранит снимки целых файлов, он понятия не имеет где и какая часть файла изменилась.
Иными словами если у тебя все коммиты редактировали один файл то каждый из них содержит в себе все изменения предыдущих.
Ананасы, как быть с форматированием кода. Я имею ввиду clang-format.
Знаю что в гите есть хуки для прекоммита и там можно, например, настроить вызов каких-то сторонних утилит тоже форматирование.
Но как тогда не отслеживать эти изменения?
Знаю что в гите есть хуки для прекоммита и там можно, например, настроить вызов каких-то сторонних утилит тоже форматирование.
Но как тогда не отслеживать эти изменения?
>>304534
У нас было вообще проще: мы настраивали редакторы чтобы те делали clang-format при сохранении. Работало в VSCode и QTCreator.
У нас было вообще проще: мы настраивали редакторы чтобы те делали clang-format при сохранении. Работало в VSCode и QTCreator.
Бандиты, суть такова:
Есть кучка офисных мудил в разных концах необъятной нашей родины. Они и близко не программеры, потому заставить их пользоваться git'ом не предоставляется возможным.
Но они совместно разрабатывают документы (преимущественно текст, изредка таблицы), шлют, ясен хуй, в формате docx все на всех. Раз в пару недель случается коллапс когда оказывается что одни редактировали одну версию, другие другую и тд.
Я с этим борюсь как могу тем, что выкладываю на интранетовский сайт самые свежие версии и прошу постоянно перед вдохновением что-то дополнить - скачивать с сайта последнюю версию, но помогает так себе.
Короче че я хочу:
1. запилить сайтец, смахивающий на гитхаб: ветки там, версии, великолепный diff
2. после загрузки юзером ебучего docx конвертировать этот docx в markdown чтобы выбросить всю ебучий мусор из области оформления ворда
3. делать diff с маркдауном последнего по времени загрузки файла, чтобы видно было чего добавили в браузере, может с чатиком / комментариями чтобы они пиздели прям друг с другом, а не со мной
4. генерить из этого маркдауна обратно docx чтобы васяны могли скачать и править его
всё.
А теперь внимание вопрос, может кто-то что-то уже видел похожее? Если оно будет стоить денег - не проблема.
Есть кучка офисных мудил в разных концах необъятной нашей родины. Они и близко не программеры, потому заставить их пользоваться git'ом не предоставляется возможным.
Но они совместно разрабатывают документы (преимущественно текст, изредка таблицы), шлют, ясен хуй, в формате docx все на всех. Раз в пару недель случается коллапс когда оказывается что одни редактировали одну версию, другие другую и тд.
Я с этим борюсь как могу тем, что выкладываю на интранетовский сайт самые свежие версии и прошу постоянно перед вдохновением что-то дополнить - скачивать с сайта последнюю версию, но помогает так себе.
Короче че я хочу:
1. запилить сайтец, смахивающий на гитхаб: ветки там, версии, великолепный diff
2. после загрузки юзером ебучего docx конвертировать этот docx в markdown чтобы выбросить всю ебучий мусор из области оформления ворда
3. делать diff с маркдауном последнего по времени загрузки файла, чтобы видно было чего добавили в браузере, может с чатиком / комментариями чтобы они пиздели прям друг с другом, а не со мной
4. генерить из этого маркдауна обратно docx чтобы васяны могли скачать и править его
всё.
А теперь внимание вопрос, может кто-то что-то уже видел похожее? Если оно будет стоить денег - не проблема.
Объясните пожалуйста ньюфагу, зачем нужно использовать в гитхабе именно КОНСОЛЬ, а не приложение или браузер? Это исключительно хотелка нашего препода, или есть реальные отличия? Заранее спасибо за ответ.
407 Кб, 1166x645Сделал простенький скрипт под винду дабы ускорить работу с частыми командами гита. Может быть кому то пригодится, а может кто то дополнит своим.
https://github.com/ta-tikoma/console-git-wrapper
https://github.com/ta-tikoma/console-git-wrapper
>>310588
было мотивировано тем что уже воротит от приложений браузеров типа github-desktop или gitkraken
было мотивировано тем что уже воротит от приложений браузеров типа github-desktop или gitkraken
>>310595
Bat скрипт он и там и там работает
Bat скрипт он и там и там работает
>>308828
Это да, но шибко оно с порталом и другой мс дрочью завязано. А у меня вся прочая инфраструктура уже готова, ей уже народ пользуется, и конвертировать все это безобразие в шароточку вообще желания ноль, как и припердоливать ее как-то сбоку.
Это да, но шибко оно с порталом и другой мс дрочью завязано. А у меня вся прочая инфраструктура уже готова, ей уже народ пользуется, и конвертировать все это безобразие в шароточку вообще желания ноль, как и припердоливать ее как-то сбоку.
2 Кб, 108x332Чёт накосячил вроде в гите с amend и получился пикрелейтед.
Как вернуть коммит в ветку?
Как вернуть коммит в ветку?
>>308430
Велосипед изобретаешь.
Шарепойнт сделали как раз для распределённой работы офисных планктош.
Ты будешь ебаться сто лет, и всё равно в итоге придёшь к примерно тому же.
И учти что планктошам насрать на твой маркап и дифф - им надо быстро делать и исправлять документы, а не разбираться в тонкостях команд гита.
>2. после загрузки юзером ебучего docx конвертировать ...
>3. делать diff с маркдауном последнего по времени загрузки файла, чтобы видно было чего добавили ....
>4. генерить из этого маркдауна обратно docx ...
Велосипед изобретаешь.
Шарепойнт сделали как раз для распределённой работы офисных планктош.
Ты будешь ебаться сто лет, и всё равно в итоге придёшь к примерно тому же.
И учти что планктошам насрать на твой маркап и дифф - им надо быстро делать и исправлять документы, а не разбираться в тонкостях команд гита.
>>318911
git rebase ?
git rebase ?
>>318911
Взять коммит без перезаписи истории — git cherry-pick. Если хочешь его засунуть в правильном порядке — да, через рибейз, с перезаписью истории.
Взять коммит без перезаписи истории — git cherry-pick. Если хочешь его засунуть в правильном порядке — да, через рибейз, с перезаписью истории.
Использую гит по назначению - как файлопомойку:
[alias]
save = "!git add -A . && git commit -a -m \"Save\" && git push"
[alias]
save = "!git add -A . && git commit -a -m \"Save\" && git push"
>>284625
Да, но вот я лично пока Darcs юзаю, пихуль сырой ещё пока.
Да, но вот я лично пока Darcs юзаю, пихуль сырой ещё пока.
>>262450
ну японцы умеют делать книжки не то что у нас
намного внятнее написано чем в мое время в шк
60 процентов хуй поми что в мои 15 лет матам нехуя не понимал
ну японцы умеют делать книжки не то что у нас
намного внятнее написано чем в мое время в шк
60 процентов хуй поми что в мои 15 лет матам нехуя не понимал
>>241859
я не такой большой начальник, что бы отдавать подобные приказы
я не такой большой начальник, что бы отдавать подобные приказы
>>318911
git rebase -i HEAD~4
git rebase -i HEAD~4
1 Кб, 323x80Сам гит работает, но не через командную строку
выдает error launching git: .
В гугле в похожих вопросах вместо пробелов стояли пояснения ошибок, типа не удается найти какой-то файл и тд, у меня же - ничего, просто пробелы
выдает error launching git: .
В гугле в похожих вопросах вместо пробелов стояли пояснения ошибок, типа не удается найти какой-то файл и тд, у меня же - ничего, просто пробелы
>>341905
У тебя походу не пробелы, а неподдерживаемые символы (локализация?) - висящая точка намекает. Попробуй сменить кодовую страницу на UTF-8 (в консоли же набери chcp 65001, обратно chcp 866)
А лучше забей на эту консоль а выбери вариант с bash через MSYS-2
У тебя походу не пробелы, а неподдерживаемые символы (локализация?) - висящая точка намекает. Попробуй сменить кодовую страницу на UTF-8 (в консоли же набери chcp 65001, обратно chcp 866)
А лучше забей на эту консоль а выбери вариант с bash через MSYS-2
>>341905
на каждом углу уже гит для винды прекомпилированный лежит и отлично работает. где версия Гита? где настройки консоли? если ты даже гит не можешь настроить может тебе рано ещё кодить?
на каждом углу уже гит для винды прекомпилированный лежит и отлично работает. где версия Гита? где настройки консоли? если ты даже гит не можешь настроить может тебе рано ещё кодить?
379 Кб, 1200x1600Пользователи православного Subversion есть? Могу помочь, объяснить что да как и так же объяснить где он лучше чем git.
>>343610
Хранить бинарники можно без ебли и костылей, а еще разграничивать права по доступу к кускам репозитория можно.
Так что всякую хрень типа ассетов, документальной инфы и специфичных бинарных артефактов складываем в SVN, а git уже для сорцов. Собирать результаты билда приходится правда костылями
Хранить бинарники можно без ебли и костылей, а еще разграничивать права по доступу к кускам репозитория можно.
Так что всякую хрень типа ассетов, документальной инфы и специфичных бинарных артефактов складываем в SVN, а git уже для сорцов. Собирать результаты билда приходится правда костылями
>>343653
perfect kitty
perfect kitty
13 Кб, 244x384>>343744
ну нахуя тебе гит?
ну нахуя тебе гит?
Такая ситуация: у нашего продукта существует несколько различных версий для разных клиентов, причем различия между ними иногда довольно большие. Но часто нужно оперативно и желательно одновременно обновлять все версии. Сейчас использую git с веткой на каждую версию. Периодически мерджу с апстримом, разруливаю конфликты, ломаю специфичные для ветки фичи, восстанавливаю их. Последний раз вообще разнес один и тот же коммит на все ветки cherry-pick'ом. Уверен, что для этого случая найдется более уместный инструмент, но постоянно надо, чтобы все работало не то, что вчера, а еще месяц назад, поэтому переезд, да и изучение может затянуться надолго. Возможно, нужно просто правильно использовать git.
Так вот: можно ли хранить в разных ветках разные наборы коммитов? И при объединении выбирать, какие коммиты принимать, а какие - нет? Задолбался все ломать и восстанавливать уже, помоги, анон!
Так вот: можно ли хранить в разных ветках разные наборы коммитов? И при объединении выбирать, какие коммиты принимать, а какие - нет? Задолбался все ломать и восстанавливать уже, помоги, анон!
>>347910
Мне кажется надо это разруливать на уровне кода приложения, а не плодить десяток веток, которые потом сложно поддерживать.
Мне кажется надо это разруливать на уровне кода приложения, а не плодить десяток веток, которые потом сложно поддерживать.
>>347915
То есть брать все из конфигурационных файлов? Там логика в некоторых версиях очень сильно меняется. Если громоздить кучу ифов, производительность пострадает (а она важна). Но это полбеды. Если для серверной части можно просто собирать разные билды с разными параметрами, то клиентская у нас - на скриптоте, поэтому при должном терпении один пользователь может либо подобрать настройки второго, либо вообще получить код, которого он видеть не должен.
Я нубик, пришел с фриланса в суровый Ънтерпрайз, сильно не пинайте, пожалуйста.
То есть брать все из конфигурационных файлов? Там логика в некоторых версиях очень сильно меняется. Если громоздить кучу ифов, производительность пострадает (а она важна). Но это полбеды. Если для серверной части можно просто собирать разные билды с разными параметрами, то клиентская у нас - на скриптоте, поэтому при должном терпении один пользователь может либо подобрать настройки второго, либо вообще получить код, которого он видеть не должен.
Я нубик, пришел с фриланса в суровый Ънтерпрайз, сильно не пинайте, пожалуйста.
>>347910
Вынеси различающиеся для клиентов места в отдельную библиотеку с версиями для каждого клиента, обновляй общее для всех в одном месте, для клиентов - когда надо. SRP же.
Вынеси различающиеся для клиентов места в отдельную библиотеку с версиями для каждого клиента, обновляй общее для всех в одном месте, для клиентов - когда надо. SRP же.
>>347910
Использовать вместо веток форки было бы гораздо удобнее, кстати.
Использовать вместо веток форки было бы гораздо удобнее, кстати.
В одной репе есть коммиты, которых нет в другой. При каждом изменении предлагает мерджить, уже заебался. Как бы привести их к одному виду, не перекидывая все файлы с правильной ветки в кривую? Чекаутнуться к коммиту, с которого пошло расхождение, и...?
А всякие хранилища артефактов, CI/CD и прочее - это сюда?
1
2
Подскажите программу которая по КД сохраняет избранный файл, как свои изменения, а не весь.
3
Спасибо, анончики. Вернули мне вкус к жизни.
А то я стал думать, что это я один старый пердун - дегенерат, который считает гит ебаной хуйней, а все остальные кончают от него радугой.
Оказывается, не один я такой.
А то я стал думать, что это я один старый пердун - дегенерат, который считает гит ебаной хуйней, а все остальные кончают от него радугой.
Оказывается, не один я такой.
>>377294
cron
cron
>>405783
А где конкретно в треде про это писали?
Я то уже сколько говорю что гита бесполезная игрулька для быдляков. Так мне в одном треде по хардкору разъяснили что аудиторы держат программистов за яйца и всем выдадут пизды если они не будут каждый пук складывать в гиту а то рабовладельцы не смогут акции на ипо выпустить. А я то малолетка и жизни еще не нюхал.
А где конкретно в треде про это писали?
Я то уже сколько говорю что гита бесполезная игрулька для быдляков. Так мне в одном треде по хардкору разъяснили что аудиторы держат программистов за яйца и всем выдадут пизды если они не будут каждый пук складывать в гиту а то рабовладельцы не смогут акции на ипо выпустить. А я то малолетка и жизни еще не нюхал.
>>406309
ты не спросил, как аудитор может понять, что сложено в гит?
а то, может, я туда складываю отчеты о том, как выебал его мамку
ты не спросил, как аудитор может понять, что сложено в гит?
а то, может, я туда складываю отчеты о том, как выебал его мамку
>>406446
Очевидным образом аудитор может заглянуть в логи гита и посмотреть все изменения которые вносились за всю историю разработки.
Очевидным образом аудитор может заглянуть в логи гита и посмотреть все изменения которые вносились за всю историю разработки.
>>409623
Русский - не твой родной?
Вопрос был:
Ты отвечаешь, как он может посмотреть.
Там аудитор - охуенный программист, который понимает код не хуже писунов этого кода (причем сразу ВЕСЬ, блядь, код, который туда складывают)?
Тогда хули он аудирует, а не кодописит?
А если он не такой крутой, то повторяю вопрос - как он поймет, что я там накодил?
Русский - не твой родной?
Вопрос был:
>как аудитор может понять, что сложено в гит
Ты отвечаешь, как он может посмотреть.
Там аудитор - охуенный программист, который понимает код не хуже писунов этого кода (причем сразу ВЕСЬ, блядь, код, который туда складывают)?
Тогда хули он аудирует, а не кодописит?
А если он не такой крутой, то повторяю вопрос - как он поймет, что я там накодил?
>>409637
Потому что "анализировать" результаты чужого труда почесывая яйца всегда во много раз проще чем что то делать самому своей собственной головой. И да не нужно быть ебаным Кормаком чтобы отличить КОД от отчетов про еблю мамок. Ах да - в сраку тебя ебал вместе с твоими тупорылыми вопросами дауна безмозглого.
>Тогда хули он аудирует, а не кодописит?
Потому что "анализировать" результаты чужого труда почесывая яйца всегда во много раз проще чем что то делать самому своей собственной головой. И да не нужно быть ебаным Кормаком чтобы отличить КОД от отчетов про еблю мамок. Ах да - в сраку тебя ебал вместе с твоими тупорылыми вопросами дауна безмозглого.
>>410071
Ох уж этот школьник с лабой1, хаха.
И правда школьник.
>анализировать" результаты чужого труда почесывая яйца всегда во много раз проще
Ох уж этот школьник с лабой1, хаха.
>еблю мамок
И правда школьник.
>>411000 жесть
15 Кб, 273x243>>343610
Здравствуйте уважаемый человек, могущий объяснить что да как.
Суть такова. Есть рабочая группа 5-10 человек, разрабатывают схемы и печатные платы в ИДЕ Altium. Altium поддерживает работу с SVN.
Каждая отдельная разработка (или проект изделия) содержит 10-20 ИДЕ-проектов печатных плат со схемами.
Плюс библиотека элементов, которая включается в каждый проект печатной платы. И для каждой разработки хорошо бы использовать одну и ту же самую библиотеку элементов.
Все данные - бинарные, объём репозитория будет расти очень быстро.
Вопрос в том, как правильно организовать svn-сервер:
Держать всё, и прошлые разработки и новые, в одном гигантском репо? (средний коммит 1Мб, при 10 коммитах юзера в день... Итого за год набежит 54Гб запросто)
Отдельные репо для каждой разработки? Но тут вопрос как синхронизировать либу компонентов, включаемую в каждый проект печатной платы. Когда юзер в ходе работы над проектом печатной платы добавляет компонент в библиотеку, этот новый компонент должен стать доступен остальным юзерам, которые могут быть заняты на другой разработке.
Второй вопрос, как правильно организовать репо для нескольких проектов.
"tags trunk branches" делать в корне репо, или делать внутри папки проекта свои "tags trunk branches" ?
Здравствуйте уважаемый человек, могущий объяснить что да как.
Суть такова. Есть рабочая группа 5-10 человек, разрабатывают схемы и печатные платы в ИДЕ Altium. Altium поддерживает работу с SVN.
Каждая отдельная разработка (или проект изделия) содержит 10-20 ИДЕ-проектов печатных плат со схемами.
Плюс библиотека элементов, которая включается в каждый проект печатной платы. И для каждой разработки хорошо бы использовать одну и ту же самую библиотеку элементов.
Все данные - бинарные, объём репозитория будет расти очень быстро.
Вопрос в том, как правильно организовать svn-сервер:
Держать всё, и прошлые разработки и новые, в одном гигантском репо? (средний коммит 1Мб, при 10 коммитах юзера в день... Итого за год набежит 54Гб запросто)
Отдельные репо для каждой разработки? Но тут вопрос как синхронизировать либу компонентов, включаемую в каждый проект печатной платы. Когда юзер в ходе работы над проектом печатной платы добавляет компонент в библиотеку, этот новый компонент должен стать доступен остальным юзерам, которые могут быть заняты на другой разработке.
Второй вопрос, как правильно организовать репо для нескольких проектов.
"tags trunk branches" делать в корне репо, или делать внутри папки проекта свои "tags trunk branches" ?
Умудрённый опытом анон, молю, подскажи охуенный git клиент.
У меня сложилось впечатление что есть некий тайный гит клиент не указанный вот в этом списке https://git-scm.com/download/gui/windows .
Поясню свою параноидальность: они все какие-то уебанские в край. Наиболее близок мне Git Extensions. Визуально в нем нет кучи свистоперделок с вырвиглазными цветами.
И ещё поясни про мердж. Пытался использовать winmerge и kdiff3 - и нихуя не получилось. Как код мерджат то? Даже в этом говне мамонта нет нихуя из списка фич ide которые помогают ориентироваться в коде и в итоге решать что делать с конфликтными местами.
В командной строке и блокноте как-то не особо эти задачи у меня получается решать.
p.s. вот winmerge с tortoise svn дружит на ура и понятно хотябы где были изменения, какой код добавлен, удален и куда уехал.... а с гитом не дружит
У меня сложилось впечатление что есть некий тайный гит клиент не указанный вот в этом списке https://git-scm.com/download/gui/windows .
Поясню свою параноидальность: они все какие-то уебанские в край. Наиболее близок мне Git Extensions. Визуально в нем нет кучи свистоперделок с вырвиглазными цветами.
И ещё поясни про мердж. Пытался использовать winmerge и kdiff3 - и нихуя не получилось. Как код мерджат то? Даже в этом говне мамонта нет нихуя из списка фич ide которые помогают ориентироваться в коде и в итоге решать что делать с конфликтными местами.
В командной строке и блокноте как-то не особо эти задачи у меня получается решать.
p.s. вот winmerge с tortoise svn дружит на ура и понятно хотябы где были изменения, какой код добавлен, удален и куда уехал.... а с гитом не дружит
>>420672
А чем tortoiseGIT не устраивает?
А чем tortoiseGIT не устраивает?
Хайль аноны. Есть ли какая-то программа, которая мне красиво построит карту репозитория? Чтоб со всеми мерджами, разноцветненькая и прочее
Вопрос по гиту
Есть один файл - постоянно меняется и он должен попадать в репозиторий. Но попадать не всегда, а только когда я этого захочу. т.е. при определенном состоянии я его буду отдельно коммитить.
В связи с чем вопрос: можно ли как-то сделать чтобы гит не следил за этим файлом? не gitignor, чтобы я мог спокойно написать git add . и добавилось все, кроме этого файла, а если надо то, чтобы я добавлял его индивидуально
Есть один файл - постоянно меняется и он должен попадать в репозиторий. Но попадать не всегда, а только когда я этого захочу. т.е. при определенном состоянии я его буду отдельно коммитить.
В связи с чем вопрос: можно ли как-то сделать чтобы гит не следил за этим файлом? не gitignor, чтобы я мог спокойно написать git add . и добавилось все, кроме этого файла, а если надо то, чтобы я добавлял его индивидуально
>>437708
Я б алиасами тупо ебнул на гит адд точка ексклюде файлнаме.
Я б алиасами тупо ебнул на гит адд точка ексклюде файлнаме.
42 Кб, 585x278>>437708
Добавляешь свой файл в .gitignore. После этого "git add ." будет добавлять в индекс всё, кроме него. А вот "git add -f <твой_файл>" будет вручную добавлять именно его (без -f просто ругнется и выдаст подсказку, так что не забудешь).
Добавляешь свой файл в .gitignore. После этого "git add ." будет добавлять в индекс всё, кроме него. А вот "git add -f <твой_файл>" будет вручную добавлять именно его (без -f просто ругнется и выдаст подсказку, так что не забудешь).
submodules — да или нет?
Кто работал с ними плотно laba1?
У меня создалось впечатление, что в это дерьмо лучше не лезть, но может у кого есть противоположный опыт.
Кто работал с ними плотно laba1?
У меня создалось впечатление, что в это дерьмо лучше не лезть, но может у кого есть противоположный опыт.
>>439189
А других вариантов особо нет, когда куча разных команд ебашит. Но удаленная зависимость им не подходит.
А других вариантов особо нет, когда куча разных команд ебашит. Но удаленная зависимость им не подходит.
>>439217
В принципе, цель состоит в том, чтобы ебашила одна команда.А сабмодули подаются, как способ решения компоновок разных их версий и бранчей для финального продукта.
В принципе, цель состоит в том, чтобы ебашила одна команда.А сабмодули подаются, как способ решения компоновок разных их версий и бранчей для финального продукта.
>>438306
после git add -f этот файл стал добавляться и по git add .
Почему так? И как сделать то, что я написал?
после git add -f этот файл стал добавляться и по git add .
Почему так? И как сделать то, что я написал?
69 Кб, 689x345>>440716
Тогда сложнее. Твоя ситуация не очень характерна для гита, ты хочешь "включать/выключать" файл, при том что этот файл уже есть в дереве коммита. Тебе поможет служебная команда update-index, через нее будешь "включать/выключать", через опцию --[no-]assume-unchanged. Выполнять после каждого коммита. Можешь "git update-index --assume-unchanged test.txt" добавить в post commit хук. git help update-index тебе в помощь.
Еще момент - git add и git status работают через одни и те же механизмы. Если ты "выключишь" файл, то он не будет добавляться через git add . , но и не будет отображаться как измененный через git status
Тогда сложнее. Твоя ситуация не очень характерна для гита, ты хочешь "включать/выключать" файл, при том что этот файл уже есть в дереве коммита. Тебе поможет служебная команда update-index, через нее будешь "включать/выключать", через опцию --[no-]assume-unchanged. Выполнять после каждого коммита. Можешь "git update-index --assume-unchanged test.txt" добавить в post commit хук. git help update-index тебе в помощь.
Еще момент - git add и git status работают через одни и те же механизмы. Если ты "выключишь" файл, то он не будет добавляться через git add . , но и не будет отображаться как измененный через git status
39 Кб, 210x140>>239087 (OP)
Ну что гитоебы, гит официально стал пидерским, по своему велению весь ваш говногод будет заблочен.
On which countries and territories are U.S. government sanctions applied?
Crimea, Cuba, Iran, North Korea, and Syria.
https://help.github.com/en/articles/github-and-trade-controls
Ну что гитоебы, гит официально стал пидерским, по своему велению весь ваш говногод будет заблочен.
On which countries and territories are U.S. government sanctions applied?
Crimea, Cuba, Iran, North Korea, and Syria.
https://help.github.com/en/articles/github-and-trade-controls
5 Кб, 48x48>>442950
ГитХаб только, не гит. Он последнее время всякие акции в поддержку ЛГБТ проводит, так что да.
>гит официально стал пидерским
ГитХаб только, не гит. Он последнее время всякие акции в поддержку ЛГБТ проводит, так что да.
>>443120
Не, но гит тоже говно, на хуй эта ебола, где для того чтобы не поломать нужно читать книгу в 1000 страниц.
>гит
Не, но гит тоже говно, на хуй эта ебола, где для того чтобы не поломать нужно читать книгу в 1000 страниц.
>>443123
Поправил, не благодари.
>где для того чтобы не поломать нужно не быть умственно отсталым дебилом
Поправил, не благодари.
>>239087 (OP)
Я вообще не шарю.
Поясните, что такое гит, пожалуйста. Из вики нихуя не понял.
Это БД с исходниками благодаря которым ты можешь модифицировать свою программу? Из этих исходников можно собирать и другие программы?
Поясните я тупой
Я вообще не шарю.
Поясните, что такое гит, пожалуйста. Из вики нихуя не понял.
Это БД с исходниками благодаря которым ты можешь модифицировать свою программу? Из этих исходников можно собирать и другие программы?
Поясните я тупой
86 Кб, 720x540>>443942
про гит не знаю не смогу пояснить сорри братан
могу пояснить за гитхаб - это такая буржуйская организация с котом мутантом на лого которая гнобят крымчан и продаёт лгбт футболки
про гит не знаю не смогу пояснить сорри братан
могу пояснить за гитхаб - это такая буржуйская организация с котом мутантом на лого которая гнобят крымчан и продаёт лгбт футболки
>>443942
Система контроля версий. Как ты хранишь каждую новую ревизию своего проекта? Либо никак, либо копируя полностью по папочкам, верно? И тот, и другой подход неудобен очевидно, для чего и используют такие системы.
Система контроля версий. Как ты хранишь каждую новую ревизию своего проекта? Либо никак, либо копируя полностью по папочкам, верно? И тот, и другой подход неудобен очевидно, для чего и используют такие системы.
Мой вопрос очень тонко проходит по теме контроля версий, поэтому если сочтете, что ему тут не место, то не бейте.
Короче говоря есть приложение версии, скажем, 2.1_ru и 2.7_engb. Отличаются, кроме локализации, парой небольших функций. Два раза одно приложение ставить не хочу, т.к. занимаю драгоценное место диска одинаковой информацией. Поэтому решил копать в сторону контроля версий и переключаться между ветками, но я не знаю чем воспользоваться (слышал только про гит, но т.к. он сохраняет не дифф, а "снимок" мне кажется, что это будет тот же самый перерасход места или я просто не понял как он работает) и не уверен что вообще игра стоит свеч.
Короче говоря есть приложение версии, скажем, 2.1_ru и 2.7_engb. Отличаются, кроме локализации, парой небольших функций. Два раза одно приложение ставить не хочу, т.к. занимаю драгоценное место диска одинаковой информацией. Поэтому решил копать в сторону контроля версий и переключаться между ветками, но я не знаю чем воспользоваться (слышал только про гит, но т.к. он сохраняет не дифф, а "снимок" мне кажется, что это будет тот же самый перерасход места или я просто не понял как он работает) и не уверен что вообще игра стоит свеч.
>>444880
Если приложения содержат одинаковые файлы, то гит сохранит их только единожды, это он умеет нативно. Довольно часто различия между двумя версиями затрагивают десяток файлов, а сотни и тысячи остальных файлов те же. Контентно-адресуемая файловая система, которой является гит, может в таком случае существенно сократить расход дискового пространства.
Ну и хотя во всяких "введениях в гит" пишут, что он сохраняет "снимки", он еще и жмет всё содержимое в т.н. .pack-файлы. В целом, для экономии места он имеет смысл. Только ведь сама программа git тоже занимает место на диске, тебя это не смущает?
>т.к. он сохраняет не дифф, а "снимок" мне кажется, что это будет тот же самый перерасход места
Если приложения содержат одинаковые файлы, то гит сохранит их только единожды, это он умеет нативно. Довольно часто различия между двумя версиями затрагивают десяток файлов, а сотни и тысячи остальных файлов те же. Контентно-адресуемая файловая система, которой является гит, может в таком случае существенно сократить расход дискового пространства.
Ну и хотя во всяких "введениях в гит" пишут, что он сохраняет "снимки", он еще и жмет всё содержимое в т.н. .pack-файлы. В целом, для экономии места он имеет смысл. Только ведь сама программа git тоже занимает место на диске, тебя это не смущает?
>>445018
Программа весит 20 гигов, если из этих 20 я сэкономлю 10-16, будет уже заебись.
Программа весит 20 гигов, если из этих 20 я сэкономлю 10-16, будет уже заебись.
>>239087 (OP)
Сколько оперативки и места на диске занимает виртуалка с линуксом и гит сервером? У меня она за 13Гб перевалила на работе (убунта без графического интерфейса). Сейчас встал вопрос об установке дома, но ресурсов мало (i3, 16Gb, HDD). Разве что оперативки вроде хватает, а вот SSD нет, да и места на диске свободного не так уж много. Вот думаю, то ли ставить виртаулку, то ли плюнуть и поискать какой-нибудь гитсервер в интернете, где есть бесплатные приватные репозитории.
Сколько оперативки и места на диске занимает виртуалка с линуксом и гит сервером? У меня она за 13Гб перевалила на работе (убунта без графического интерфейса). Сейчас встал вопрос об установке дома, но ресурсов мало (i3, 16Gb, HDD). Разве что оперативки вроде хватает, а вот SSD нет, да и места на диске свободного не так уж много. Вот думаю, то ли ставить виртаулку, то ли плюнуть и поискать какой-нибудь гитсервер в интернете, где есть бесплатные приватные репозитории.
>>448532
У Bitbucket же вроде были? Или закончились?
У Bitbucket же вроде были? Или закончились?
Блядь, чот уже глаз дергается. Ебучий Jenkins наотрез отказывается коннектится к репозиторию в битбакете. HTTPS пробовал, SSH проверял, Credentials указывал, RSA ключи делал, жопой на компьютер садился, пиво пил, в бубен хуярил. В прошлый раз вообще без проблем все сконнектилось, а сейчас вообще пизда-нога. Есть два варианта - я неправильно указываю путь(Да я уже по всякому перепробовал) и плагин git ебет мозги. И да, это просто подключение, без webhook'a
>>451970
Короче, аноны, вы не поверите. Сегодня зашел, а оно уже работает и ошибка пропала. Я нихуя не делал. 5 дней убивался, а оно само взяло и заработало. В такие моменты я ненавижу ИТ.
Короче, аноны, вы не поверите. Сегодня зашел, а оно уже работает и ошибка пропала. Я нихуя не делал. 5 дней убивался, а оно само взяло и заработало. В такие моменты я ненавижу ИТ.
>>239087 (OP)
1. Какой гит клиент лучший? Пользуюсь Fork, но он, например, не дает засквошить 5 коммитов подряд - приходится по одному сквошить.
2. Что почитать про кубернетис\докер? Незнакомые слова и выкладкой я не занимался. Максимум что знаю что дженкинс это тулза на жабе которая принимает проект и как то собирает. Ну чтобы вкатываться в это дело, с чего лучше стартовать.
1. Какой гит клиент лучший? Пользуюсь Fork, но он, например, не дает засквошить 5 коммитов подряд - приходится по одному сквошить.
2. Что почитать про кубернетис\докер? Незнакомые слова и выкладкой я не занимался. Максимум что знаю что дженкинс это тулза на жабе которая принимает проект и как то собирает. Ну чтобы вкатываться в это дело, с чего лучше стартовать.
Анон, есть локал проект, нужно чтобы после коммита в бд записывалось сообщение коммита, автор и дата. Как это и возможно ли сделать?
>>452623
SVN или Perforce. Ну или специализированные, например Alienbrain или Adobe VersionCue
SVN или Perforce. Ну или специализированные, например Alienbrain или Adobe VersionCue
>>452623
Меркуриал хранит дельты в том числе и для бинарных файлов. Вопрос только в том, что там фотошопе - будут ли файлы при изменении полностью обновляться или частично.
>>452585
Да можно - это называется commit hook. Есть в git, Mercurial, SVN.
Commit hook это просто скрипт который испольняется во время коммита, если верент 0 - коммит пройдет, иначе сфейлится. Если у тебя линукс то реализовать его можно на любом скриптовом языке который есть в системе: bash, perl, Python, Ruby... Если винда - то придется писать бат файл который вызовет твою программу или писать в бат файле логику.
Меркуриал хранит дельты в том числе и для бинарных файлов. Вопрос только в том, что там фотошопе - будут ли файлы при изменении полностью обновляться или частично.
>>452585
Да можно - это называется commit hook. Есть в git, Mercurial, SVN.
Commit hook это просто скрипт который испольняется во время коммита, если верент 0 - коммит пройдет, иначе сфейлится. Если у тебя линукс то реализовать его можно на любом скриптовом языке который есть в системе: bash, perl, Python, Ruby... Если винда - то придется писать бат файл который вызовет твою программу или писать в бат файле логику.
5 Кб, 553x123Что произойдет при попытке мержа из dev1 в master, если dev2 уже была смержена?
>>457211
Ничего не произойдёт, придётся разгребать конфликт слияния. Или не придётся, в зависимости от того, что в ветке было.
Ничего не произойдёт, придётся разгребать конфликт слияния. Или не придётся, в зависимости от того, что в ветке было.
>>457232
Если ты хочешь гарантированно избежать конфликтов, то перед пул реквестом в мастер вмержи его в dev1.
>в зависимости от того, что в ветке было
Если ты хочешь гарантированно избежать конфликтов, то перед пул реквестом в мастер вмержи его в dev1.
>>457244
Это понятно, я просто не пойму, в каком месте коммиты из dev2 окажутся в мастере после мержа dev1. В середине или в конце?
Это понятно, я просто не пойму, в каком месте коммиты из dev2 окажутся в мастере после мержа dev1. В середине или в конце?
>>457247
Коммиты из dev2 окажутся в master до мержа dev1. Там же на картинке явный мерж dev1 в master, за один комит до dev2 в master.
По идее те 3 коммита которые общие для dev1 и dev2, не должны вызывать конфликтов, но бывают исключения на сложных мержах.
и вообще способность git-а резолвить конфликты СИЛЬНО преувеличена
Коммиты из dev2 окажутся в master до мержа dev1. Там же на картинке явный мерж dev1 в master, за один комит до dev2 в master.
По идее те 3 коммита которые общие для dev1 и dev2, не должны вызывать конфликтов, но бывают исключения на сложных мержах.
и вообще способность git-а резолвить конфликты СИЛЬНО преувеличена
ап
а
>Speaking as someone who lost an entire day to SVN merge problems, I do not like it. I actually started using git or mercurial when forced to use SVN, then did a git checkout last-svn-sync && svn update && git checkout HEAD && svn checkin. At least if I had merge problems I still had a backup then.
Так и есть или челик ниасиливает?
>>462696
Как по мне - способность git-а разрешать конфликты сильно преувеличена. Да получше чем SVN, но не идеально. Бывает так что один раз вмержил изменения из мастера, порезолвив все конфликты, перед пул реквестом снова мержишь мастер и получаешь ровно те же, порезолвленные конфликты.
Как по мне - способность git-а разрешать конфликты сильно преувеличена. Да получше чем SVN, но не идеально. Бывает так что один раз вмержил изменения из мастера, порезолвив все конфликты, перед пул реквестом снова мержишь мастер и получаешь ровно те же, порезолвленные конфликты.
Ярчайшие представители сексуальных меньшинство из BitBucket анонсировали, что они скоро дропнут Mercurial в пользу Git.
Кто какие тулзы юзал для конвертации Mercurial в Git?
Кто какие тулзы юзал для конвертации Mercurial в Git?
652 Кб, 1291x879>>470838
Спасибо анончег.
Спасибо анончег.
>>470959
Используйте клауд, говорили они.
Клауд это надежно, говорили они.
Обо всем позаботятся наши инженеры, говорили они.
Мы сами позаботимся об обновлениях, говорили они.
Как говорил Столлман:
Используйте клауд, говорили они.
Клауд это надежно, говорили они.
Обо всем позаботятся наши инженеры, говорили они.
Мы сами позаботимся об обновлениях, говорили они.
Как говорил Столлман:
> Google Docs работает не на вашем компьютере, так что вы кладёте свои документы на чей-то сервер и этот кто-то имеет контроль над обработкой ваших данных. Это ошибка. Вы должны работать со своими документами на своём компьютере при помощи собственной копии свободной программы, которая находится под вашим контролем.
110 Кб, 1280x720>>471483
Типа гитоговно не так работает. Поставил fossil и смотрю на гитоутят с презрением.
>Google Docs
Типа гитоговно не так работает. Поставил fossil и смотрю на гитоутят с презрением.
>>471519
гитоговно работает хуже, очевидно
но никто не мешает тебе мастер гит поставить на СВОИХ серверах
>Типа гитоговно не так работает.
гитоговно работает хуже, очевидно
но никто не мешает тебе мастер гит поставить на СВОИХ серверах
>>471556
Ебал я в рот такого франкенштейна оживлять. Там наверное манул на 500 страниц, к манулу по гиту на 500 страниц. Короче, скоро в вузах специальность будет, администрирование гит.
>мастер гит поставить на СВОИХ серверах
Ебал я в рот такого франкенштейна оживлять. Там наверное манул на 500 страниц, к манулу по гиту на 500 страниц. Короче, скоро в вузах специальность будет, администрирование гит.
>>471636
Конечно, мне нужно джве комманды пуш и коммит, но потом если что пойдет не так бегать с порванной жопой по аналогичным трхедикам.
>Но тебе же не нужны все 500 страниц
Конечно, мне нужно джве комманды пуш и коммит, но потом если что пойдет не так бегать с порванной жопой по аналогичным трхедикам.
>>471579
Поэтому я на своем серваке держу цвс или свн и в хуй не дую.
За 20 лет программирования за деньги еще ни разу не видел ситуации, в которой гит мне дал бы того, чего не дал бы даже доисторический цвс.
Уж на что я матерился на цвс, но на гит я матерюсь чаще и больше.
Поэтому я на своем серваке держу цвс или свн и в хуй не дую.
За 20 лет программирования за деньги еще ни разу не видел ситуации, в которой гит мне дал бы того, чего не дал бы даже доисторический цвс.
Уж на что я матерился на цвс, но на гит я матерюсь чаще и больше.
>>471781
Вероятно когда 200500 макак со всего света срут без координации своим гвнокодом в репу, то гит даст преимущество, но я не уверен.
>в которой гит мне дал бы того
Вероятно когда 200500 макак со всего света срут без координации своим гвнокодом в репу, то гит даст преимущество, но я не уверен.
>>472000
Ну да, в треде это уже где-то упоминали. Гит заточен под бородатых олдов из 70-х, пишущих монструозное ядро линукс всей своей пиздабратией по всему миру, а не под молодых шутливых веб-макак с пет-проектами. Но гитхаб так расхайпал систему, что теперь все используют гит.
Ну да, в треде это уже где-то упоминали. Гит заточен под бородатых олдов из 70-х, пишущих монструозное ядро линукс всей своей пиздабратией по всему миру, а не под молодых шутливых веб-макак с пет-проектами. Но гитхаб так расхайпал систему, что теперь все используют гит.
>>472000
Ну, меня бог миловал
У меня с гитом постоянно какая-то засада
Наверняка, мне объяснят корифеи, что я нихуя не умею им пользоваться, но и по хую
Ни с одной другой системой контроля версий мне не приходилось спрашивать коллег, видят ли они мои изменения в репе.
А с гитом иной раз приходится
>>472044
Еще раз - 20 лет промышленного программирования, причем тут молодые с пет-проектами?
В общем, может, когда-нибудь мне толком объяснит, чего я себя лишаю, не пользуясь гитом на постоянной основе
Ну, меня бог миловал
У меня с гитом постоянно какая-то засада
Наверняка, мне объяснят корифеи, что я нихуя не умею им пользоваться, но и по хую
Ни с одной другой системой контроля версий мне не приходилось спрашивать коллег, видят ли они мои изменения в репе.
А с гитом иной раз приходится
>>472044
>не под молодых шутливых веб-макак с пет-проектами.
Еще раз - 20 лет промышленного программирования, причем тут молодые с пет-проектами?
В общем, может, когда-нибудь мне толком объяснит, чего я себя лишаю, не пользуясь гитом на постоянной основе
>>471781
Ну вот ты и стал стариком, не желающим развиваться. Был бы молодым, тебе бы пригорело и ты бы сидел и изучал, пока не понял. А тут "эээ йоба я старый и самый умный тут, у меня же 20 лет епты, не понимаю - нахуй это". Скоро превратишься в тех динозавров, которые в 50 лет на делфи 7 сидят.
В основном нормальных веток кода. Эксперименты, коммиты с отладочным кодом, мержи-хуержи, все этого и лишаешь.
>За 20 лет программирования за деньги еще ни разу не видел ситуации, в которой гит мне дал бы того, чего не дал бы даже доисторический цвс.
Ну вот ты и стал стариком, не желающим развиваться. Был бы молодым, тебе бы пригорело и ты бы сидел и изучал, пока не понял. А тут "эээ йоба я старый и самый умный тут, у меня же 20 лет епты, не понимаю - нахуй это". Скоро превратишься в тех динозавров, которые в 50 лет на делфи 7 сидят.
>В общем, может, когда-нибудь мне толком объяснит, чего я себя лишаю, не пользуясь гитом на постоянной основе
В основном нормальных веток кода. Эксперименты, коммиты с отладочным кодом, мержи-хуержи, все этого и лишаешь.
Парни, пожалуйста. Хочу строить красивую "карту" репозитория. Чтоб ветки были, сличния, коммиты хотя бы точечками xnj, обозначались. Хочется посмотреть на то, что мы делали все эти годы. Не уже ли нет никаких готовых решений для этого?
>>474947
Под гит, разумеется. Конкретнее - залито все это на гитхаб. Ну я не верю, что нет готовой визуализации
Под гит, разумеется. Конкретнее - залито все это на гитхаб. Ну я не верю, что нет готовой визуализации
>>474949
Мы юзали gfc.io, но по факту, набольших проектах, это совершенно бесполезная херня из-за особенностей работы с ветками. Получаешь нечитаемый граф.
Мы юзали gfc.io, но по факту, набольших проектах, это совершенно бесполезная херня из-за особенностей работы с ветками. Получаешь нечитаемый граф.
>>474947
Самое простое что есть - это gitk (идет в стандартной поставке гита). Если вы хоститесь на гитхабе, то там есть встроенный функционал, и думаю 100% есть у гитлаба и битбакета.
Красивость так себе, но граф коммитов все способы показывают.
Самое простое что есть - это gitk (идет в стандартной поставке гита). Если вы хоститесь на гитхабе, то там есть встроенный функционал, и думаю 100% есть у гитлаба и битбакета.
Красивость так себе, но граф коммитов все способы показывают.
если на основе репо свн создать гит, то в свне не появится никаких признаков этого (не считая логов подключения и выкачивания ревизий)?
И на сколько чувствителен git-svn к обрывам линии при клонировании/обновлении репо?
И на сколько чувствителен git-svn к обрывам линии при клонировании/обновлении репо?
Как в .gitignore запретить файлы с определенным расширением по всему проекту, но разрешить их в одной конкретной папке?
Почему когда я пушу на гитхаб в ветку отличную от мастера, то в статистике моей активностиповышающей мое ЧСВ это не помечается?
53 Кб, 723x360>>476553
Потому что нехуй повышать ЧСВ вне мастера такие правила у гитхаба.
https://help.github.com/en/articles/why-are-my-contributions-not-showing-up-on-my-profile
Потому что нехуй повышать ЧСВ вне мастера такие правила у гитхаба.
https://help.github.com/en/articles/why-are-my-contributions-not-showing-up-on-my-profile
Я как-то пропустил событие, а оказывается уже с января этого года Гитхаб предлагает приватные репозитории бесплатно:
https://github.blog/2019-01-07-new-year-new-github/
Ограничения небольшие, для одиночек несущественные:
Теперь Битбакет не нужен.
https://github.blog/2019-01-07-new-year-new-github/
Ограничения небольшие, для одиночек несущественные:
>private projects with up to three collaborators per repository for free
Теперь Битбакет не нужен.
67 Кб, 700x700Посоны, нид хелп по git.
Владею им на уровне Google-джуниор.
Ситуация: работаю над одним проектом из офиса и из дома, почти каждый день и там и там.
Как организовать работу, чтобы не терять изменения и когда надо сливать код из двух версий в одну без проблем? покомандно, если можно.
Пробовал через бранчи - но блять при слиянии постоянно возникают конфликты, и в итоге нихуя не получается слить в одну ветку таким образом, чтобы код остался и из дома, и из офиса. Гуглить заебался просто.
Подскажите, что мне делать в этой абсолютно типичной ситуации?
спасибо
Владею им на уровне Google-джуниор.
Ситуация: работаю над одним проектом из офиса и из дома, почти каждый день и там и там.
Как организовать работу, чтобы не терять изменения и когда надо сливать код из двух версий в одну без проблем? покомандно, если можно.
Пробовал через бранчи - но блять при слиянии постоянно возникают конфликты, и в итоге нихуя не получается слить в одну ветку таким образом, чтобы код остался и из дома, и из офиса. Гуглить заебался просто.
Подскажите, что мне делать в этой абсолютно типичной ситуации?
спасибо
>>478982
Нормально писать код, чтобы не вызывать конфликтов?
Сделай ветку "alwaysfetch", сделал изменения в офисе -- запушил в эту ветку изменения. Пришел домой -- пульнул, внес изменения, запушил в эту ветку. И так каждый раз.
Или сделай буффер-ветку и ветки для офиса/дома и пушь в них соответственно, ресолвя конфликты лишь при мерже в буффер. А с буфера уже в тестинг или куда ты там после этого мержишь.
Вообще твоя проблема именно в том, что ты пишешь код асинхронно, затрагивая одни и те же части кода в разных "версиях", тем самым вызывая проблемы при мерже. Поэтому или следи за тем как пишешь код или делай васянство с ветками, как я выше описал
Нормально писать код, чтобы не вызывать конфликтов?
Сделай ветку "alwaysfetch", сделал изменения в офисе -- запушил в эту ветку изменения. Пришел домой -- пульнул, внес изменения, запушил в эту ветку. И так каждый раз.
Или сделай буффер-ветку и ветки для офиса/дома и пушь в них соответственно, ресолвя конфликты лишь при мерже в буффер. А с буфера уже в тестинг или куда ты там после этого мержишь.
Вообще твоя проблема именно в том, что ты пишешь код асинхронно, затрагивая одни и те же части кода в разных "версиях", тем самым вызывая проблемы при мерже. Поэтому или следи за тем как пишешь код или делай васянство с ветками, как я выше описал
>>479007
Я так и делаю, только в мастер. И блять через раз возникают какие-то блядские конфликты, которые не связаны с написанным кодом (допустим появился новый файл в офисной версии, и появился другой новый файл в домашней версии), и мне приходится вручную копировать файлы, т.к. git просто не дает сделать merge. Только какие-то жесткие ресеты и т.д.
При этом, код у меня лежит удалённо на сервере с Debain 9, и правлю я его с Win10 phpStorm, который сука так же создает локальную копию. Сетап супер уебанский, но хуле ещё делать я не знаю. Может, подключить удаленный диск локально и как-то напрямую его править без ебучей VCS, а делать бекапы?
>сделал изменения в офисе -- запушил в эту ветку изменения. Пришел домой -- пульнул, внес изменения, запушил в эту ветку
Я так и делаю, только в мастер. И блять через раз возникают какие-то блядские конфликты, которые не связаны с написанным кодом (допустим появился новый файл в офисной версии, и появился другой новый файл в домашней версии), и мне приходится вручную копировать файлы, т.к. git просто не дает сделать merge. Только какие-то жесткие ресеты и т.д.
При этом, код у меня лежит удалённо на сервере с Debain 9, и правлю я его с Win10 phpStorm, который сука так же создает локальную копию. Сетап супер уебанский, но хуле ещё делать я не знаю. Может, подключить удаленный диск локально и как-то напрямую его править без ебучей VCS, а делать бекапы?
>>479025
в phpStrom я git отрубил, т.к. это добавляло новый уровень пиздеца.
Делаю коммиты вручную так:
git add .
git commit -m "Hue moe"
git push origin master
в phpStrom я git отрубил, т.к. это добавляло новый уровень пиздеца.
Делаю коммиты вручную так:
git add .
git commit -m "Hue moe"
git push origin master
>>479025
В одну из таких ебаных операций я тупо потерял код, написанный за день. Без возможности его вернуть. Охуенная система контроля версий, надежная блять как швейцарские часы.
>Только какие-то жесткие ресеты и т.д.
В одну из таких ебаных операций я тупо потерял код, написанный за день. Без возможности его вернуть. Охуенная система контроля версий, надежная блять как швейцарские часы.
115 Кб, 700x754>>239087 (OP)
Чет ору с трхеда, легче копипастнуть файл и создать его копию, чем пердолится с этим гитом превозмогая здравый смысл и время.
Чет ору с трхеда, легче копипастнуть файл и создать его копию, чем пердолится с этим гитом превозмогая здравый смысл и время.
>>239411
Я работаю на довольно известную компанию с кастомной монорепой, у нас в ней хранится абсолютно вся история. Но вот бранчей по факту нет, вернее есть какое-то подобие, но rebase в привычном понимании нет от слова совсем. Скучаю по гиту пиздец.
>>479090
Если ты в одиночку работаешь над проектом, то разумеется. Но и только до тех пор, пока не решишь параллельно пилить несколько крупных фичей.
Я работаю на довольно известную компанию с кастомной монорепой, у нас в ней хранится абсолютно вся история. Но вот бранчей по факту нет, вернее есть какое-то подобие, но rebase в привычном понимании нет от слова совсем. Скучаю по гиту пиздец.
>>479090
Если ты в одиночку работаешь над проектом, то разумеется. Но и только до тех пор, пока не решишь параллельно пилить несколько крупных фичей.
>>479090
А когда у тебя фича в трех файлах?
А когда у тебя фича в трех файлах?
>>479145
Ты не понял. Вот у тебя проект в хотя бы десятке файлов. Фичи большие и меняют логику 5 из них, и при этом, возможно, они пересекаются, то есть меняют один и тот же участок кода, но разными способами. Пилишь ты их несколько месяцев, при этом, скорее всего, параллельно фиксишь мелкие баги в мейнстриме. С отдельными файлами ебанешься на отличненько такое разруливать и мержить потом. И это ты один проект свой колупаешь. А представь теперь несколько человек над ним параллельно работают.
Ты не понял. Вот у тебя проект в хотя бы десятке файлов. Фичи большие и меняют логику 5 из них, и при этом, возможно, они пересекаются, то есть меняют один и тот же участок кода, но разными способами. Пилишь ты их несколько месяцев, при этом, скорее всего, параллельно фиксишь мелкие баги в мейнстриме. С отдельными файлами ебанешься на отличненько такое разруливать и мержить потом. И это ты один проект свой колупаешь. А представь теперь несколько человек над ним параллельно работают.
>>479195
они менее популярны
они менее популярны
>>479195
Линейные (SVN) хуже тем, что там то же самое копирование папочек, это чисто механизм бэкапа, а не контроль версий.
Меркуриал хуже тем, что они в рамках "простоты для пользователя" понаделали какой-то хуйни, когда pull/commit/push делается просто, а все остальное - ужасно. Когда понимаешь, что гит - это блокчейн-граф, он резко перестает быть сложным.
Fossil не трогал, может оно и хорошо для мелких проектов, но, опять же, если git работает, зачем париться.
Линейные (SVN) хуже тем, что там то же самое копирование папочек, это чисто механизм бэкапа, а не контроль версий.
Меркуриал хуже тем, что они в рамках "простоты для пользователя" понаделали какой-то хуйни, когда pull/commit/push делается просто, а все остальное - ужасно. Когда понимаешь, что гит - это блокчейн-граф, он резко перестает быть сложным.
Fossil не трогал, может оно и хорошо для мелких проектов, но, опять же, если git работает, зачем париться.
Как жить с гитом, если на проекте есть репа фактически с одной веткой? Туда нон-стоп летят сотни коммитов, пока ты свой коммит добавишь, уже сново нужно делать пулл, но нет, у вас конфликт, а конфликта нет, тк файлы разные, но все равно мержите плииииз, никаких пушей, и если успел помержить до нового пуша кем нибудь, то ты пушишь мерж реквестом, и все коммиты становятся как будто твои.. ВТФ?
>>479210
Я бы энфорсил git-flow и ротацию RelEng роли среди всех fulltime контрибьюторов. Пусть еще сперва только у владельца репы будут права на запись в мастер, но его задача будет лишь аппрувить мерж релиз ветки.
Я бы энфорсил git-flow и ротацию RelEng роли среди всех fulltime контрибьюторов. Пусть еще сперва только у владельца репы будут права на запись в мастер, но его задача будет лишь аппрувить мерж релиз ветки.
>>479555
это мой личный проект, находится на стадии разработки. не вижу причин не пушить в мастер, а городить ветки
это мой личный проект, находится на стадии разработки. не вижу причин не пушить в мастер, а городить ветки
Чем Git Kraken лучше Github Desktop? Почему я должен за него заплатить?
Ну и вообще, какой по вашему мнению лучший графический клиент и почему
Ну и вообще, какой по вашему мнению лучший графический клиент и почему
>>479566
Тред начинается с
>>478982
Тебе с таким подходом вообще SVN нужен. Вот серьезно.
https://sliksvn.com/signup/
>это мой личный проект
Тред начинается с
>>478982
>Пробовал через бранчи
Тебе с таким подходом вообще SVN нужен. Вот серьезно.
https://sliksvn.com/signup/
11 Кб, 420x170Ёб твою мать... Open source, хули. Free software. Жрите, не подавитесь.
>>481566
Тебе повезло, что ты не имел дел с win api, или например ole. После этого стал бы молиться Столлману перед сном.
Тебе повезло, что ты не имел дел с win api, или например ole. После этого стал бы молиться Столлману перед сном.
>>481715
Слава богу, Столлман никакого отношения к git не имеет!
Слава богу, Столлман никакого отношения к git не имеет!
>>479131
Piper говно.
Piper говно.
>>479131
Пользуй fig, будет зависимость.
Пользуй fig, будет зависимость.
>>481566
LIterally unplayable.
LIterally unplayable.
>>482245
Ну, мне-то можешь не рассказывать, и сам знаю
Ну, мне-то можешь не рассказывать, и сам знаю
27 Кб, 757x135В последнем Git-e v2.23 команду `checkout` разделили на две. Из-за того, что она выполняет 2 функции сразу: смену ветки и восстановление файлов в рабочем дереве. Теперь есть `git switch [-c]` и `git restore`. Ну и старую ессно оставят, для обратной совместимости.
https://github.blog/2019-08-16-highlights-from-git-2-23/
https://github.blog/2019-08-16-highlights-from-git-2-23/
>>490687
Помню в комментариях каких-то кто-то написал себе алиасы подобные, так его за такое говноедом обозвали или что-то такое.
Вот думаю до сих пор почему? Или это сущность русни или просто долбоёбы?
Помню в комментариях каких-то кто-то написал себе алиасы подобные, так его за такое говноедом обозвали или что-то такое.
Вот думаю до сих пор почему? Или это сущность русни или просто долбоёбы?
>>507153
пусть тонит
пусть тонит
Оказывается, скрипт миграции с Mercurial на Git есть в самом репозитории гита, причем написан очень давно. Скрипт на пистоне:
https://github.com/git/git/tree/master/contrib/hg-to-git
Ну и в книге ProGit есть описание миграции, там другой скрипт используется: >>470838
Битбакет прекращает поддержку Меркуриала к 1 июня 2020 года:
https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
https://github.com/git/git/tree/master/contrib/hg-to-git
Ну и в книге ProGit есть описание миграции, там другой скрипт используется: >>470838
Битбакет прекращает поддержку Меркуриала к 1 июня 2020 года:
https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
>>512377
Гит для пидоров
Гит для пидоров
14 Кб, 499x206Помогите. Имел тупость сделать initial commit без gitignore и в проект попал весь мусор из IDE и скомпилированных файликов.
Добавил гитигнор, (git add .) (git commit -m "foo") (git push),
а мусорные файлы так и остались в проекте. Что делать? Пробовал и чистить гитигнор и заново делать.
вот gitignore https://pastebin.com/addWZvE9
Добавил гитигнор, (git add .) (git commit -m "foo") (git push),
а мусорные файлы так и остались в проекте. Что делать? Пробовал и чистить гитигнор и заново делать.
вот gitignore https://pastebin.com/addWZvE9
>>518905
Простите, я сам сделал.
git rm --cached /папки и файлы/
Вы наверное уже набирали развернутые ответы своими благородными руками, а я вас подвёл.
Простите, я сам сделал.
git rm --cached /папки и файлы/
Вы наверное уже набирали развернутые ответы своими благородными руками, а я вас подвёл.
>>518916
Bсе равно окончательно помогла ide, некоторые файлы светились красным как неиндексируемые, хотя были в гитигноре. Мне помогло ПКМ -> Git -> add to .gitignore
Bсе равно окончательно помогла ide, некоторые файлы светились красным как неиндексируемые, хотя были в гитигноре. Мне помогло ПКМ -> Git -> add to .gitignore
>>519240
Ты совсем дебил? Тебе работу делать и деньги зарабатывать, или в трушность играть?
Тебя ебет, на чем он написан? Ты в данном случае конечный пользователь, тебе вот куда уперлась инфа о том, на чем написано приложение, которым ты пользуешься, чтобы сократить 10 минут ебли до одного клика мыши?
>трушнее
Ты совсем дебил? Тебе работу делать и деньги зарабатывать, или в трушность играть?
>github desktop на electron написан, это плохо
Тебя ебет, на чем он написан? Ты в данном случае конечный пользователь, тебе вот куда уперлась инфа о том, на чем написано приложение, которым ты пользуешься, чтобы сократить 10 минут ебли до одного клика мыши?
287 Кб, 600x315Луший гуй - Fork, быстра, чОтка, без всяких электронов
>>520463
Ну хуй знает, я пользовался им и чувствовал себя ламером!
Консольный гит все равно нужно знать, не везде на галерах гуёк юзают. И под линукс есть только неофициальная реализация.
Вообще консоль всегда мощнее и понятнее гуя, где нужно тыкаться в кнопочки, галочки и прочие controls, но естественно в консоль выше порог вхождения и она более задротская.
Ну хуй знает, я пользовался им и чувствовал себя ламером!
Консольный гит все равно нужно знать, не везде на галерах гуёк юзают. И под линукс есть только неофициальная реализация.
Вообще консоль всегда мощнее и понятнее гуя, где нужно тыкаться в кнопочки, галочки и прочие controls, но естественно в консоль выше порог вхождения и она более задротская.
>>520472
Ну так разберись со своим комплексом неполноценности.
Чего блять? При чем тут галера вообще? От тебя требуется вовремя коммитить и вовремя мерджить, кому нахуй какая разница, как ты это делаешь -- пердолясь в срачельник консолькой, или нажав на одну кнопку? Тут вопрос ставится о минимизации количества времени, которое ты потратишь на выполнение этих действий, а не на то, насколько "трушно" ты закоммитил свою feature1. Знать надо возможности, которые git предоставляет, и уметь ими пользоваться, а не зубрить формат очередной охуительной консольно-пердольной команды.
В любую иде не из каменного века по дефолту встроены базовые возможности для работы с VCS, которых тебе хватит для примерно 90% случаев.
Дружище, скажи честно, тебе 15 лет? Ты сам ради простейшего действия аж три поста написал в /зк/, настолько твоя любимая консоль мощная и понятная. А мог бы ткнуть в кнопку и не ебать себе мозг, причем это ты мог бы сделать, даже будучи в стельку бухим. Объясни мне, в чем мощь и понятность инструмента, для использования которого надо держать в голове два десятка разных команд, опций для этих команд, формат аргументов, которые они принимают, последовательность, в которой их нужно выполнить, когда есть инструмент с двумя кнопками, которые позволяют делать все ровно то же самое, только быстрее, интуитивнее и без пердолинга в срачельник?
Если б ты промышлял писанием каких-нибудь скриптов на баше, или прочей подобной хуйней, тогда пердолирование консоли еще как-то оправдано. Но если ты код пишешь в одном месте (в ide), а версии пердолишь в другом (в консоли), то ты просто разрываешь свой workflow, таким образом уменьшая производительность своего труда.
>я пользовался им и чувствовал себя ламером
Ну так разберись со своим комплексом неполноценности.
>Консольный гит все равно нужно знать, не везде на галерах гуёк юзают
Чего блять? При чем тут галера вообще? От тебя требуется вовремя коммитить и вовремя мерджить, кому нахуй какая разница, как ты это делаешь -- пердолясь в срачельник консолькой, или нажав на одну кнопку? Тут вопрос ставится о минимизации количества времени, которое ты потратишь на выполнение этих действий, а не на то, насколько "трушно" ты закоммитил свою feature1. Знать надо возможности, которые git предоставляет, и уметь ими пользоваться, а не зубрить формат очередной охуительной консольно-пердольной команды.
>И под линукс есть только неофициальная реализация
В любую иде не из каменного века по дефолту встроены базовые возможности для работы с VCS, которых тебе хватит для примерно 90% случаев.
>консоль всегда мощнее и понятнее гуя
Дружище, скажи честно, тебе 15 лет? Ты сам ради простейшего действия аж три поста написал в /зк/, настолько твоя любимая консоль мощная и понятная. А мог бы ткнуть в кнопку и не ебать себе мозг, причем это ты мог бы сделать, даже будучи в стельку бухим. Объясни мне, в чем мощь и понятность инструмента, для использования которого надо держать в голове два десятка разных команд, опций для этих команд, формат аргументов, которые они принимают, последовательность, в которой их нужно выполнить, когда есть инструмент с двумя кнопками, которые позволяют делать все ровно то же самое, только быстрее, интуитивнее и без пердолинга в срачельник?
Если б ты промышлял писанием каких-нибудь скриптов на баше, или прочей подобной хуйней, тогда пердолирование консоли еще как-то оправдано. Но если ты код пишешь в одном месте (в ide), а версии пердолишь в другом (в консоли), то ты просто разрываешь свой workflow, таким образом уменьшая производительность своего труда.
>>520614
Ты пиздишь, либо инструмент не с двумя кнопками, а с кучей меню и подменю, либо в консоли это делается так же быстро
Ты пиздишь, либо инструмент не с двумя кнопками, а с кучей меню и подменю, либо в консоли это делается так же быстро
>>520615
Доебался до фигуры речи. Окей, пусть будет с десятью кнопками, которые все подписаны, расположены эргономично и каждая из которых эквивалентна пяти пердокомандам, что это меняет?
Доебался до фигуры речи. Окей, пусть будет с десятью кнопками, которые все подписаны, расположены эргономично и каждая из которых эквивалентна пяти пердокомандам, что это меняет?
>>520614
Какая разница, консоль или гуй, если я забыл гитигнор делать, файлы надо от индекса вручную отрывать.
У меня в IDE есть, для обычных коммитов сойдет.
Так бля понятное дело, я ведь ньюфаг в консольном гите. Я интуитивно в ней разобрался, только посмотрел короткий гайд, где показаны add commit push pull, про последние три я и так знал.
И на говнокомпах 32-бит не запустишь гит десктоп.
Для пердоленья со слиянием и разбиением веток думаю можно скачать, а базовые вещи типа коммита буду лучше делать из ide'шного терминала.
Какая разница, консоль или гуй, если я забыл гитигнор делать, файлы надо от индекса вручную отрывать.
>В любую иде не из каменного века по дефолту встроены базовые возможности для работы с VCS, которых тебе хватит для примерно 90% случаев.
У меня в IDE есть, для обычных коммитов сойдет.
>Дружище, скажи честно, тебе 15 лет? Ты сам ради простейшего действия аж три поста написал в /зк/, настолько твоя любимая консоль мощная и понятна
Так бля понятное дело, я ведь ньюфаг в консольном гите. Я интуитивно в ней разобрался, только посмотрел короткий гайд, где показаны add commit push pull, про последние три я и так знал.
И на говнокомпах 32-бит не запустишь гит десктоп.
Для пердоленья со слиянием и разбиением веток думаю можно скачать, а базовые вещи типа коммита буду лучше делать из ide'шного терминала.
>>520675
А в гуе ты бы просто выделил untracked файлы и сделал remove.
На говнокомпах 32 бит и четыре гб ОЗУ не заюзать, при том что тупо браузер + андроид студия отжирают три, и что теперь?
Так блять, мердж - это как раз самое главное, для чего вообще git и нужен, если ты работаешь над проектом больше, чем в одно рыло.
Но зачем, если есть кнопочка commit, которая сделает то же самое, только в сто раз быстрее?
>я забыл гитигнор делать, файлы надо от индекса вручную отрывать
А в гуе ты бы просто выделил untracked файлы и сделал remove.
>И на говнокомпах 32-бит не запустишь гит десктоп.
На говнокомпах 32 бит и четыре гб ОЗУ не заюзать, при том что тупо браузер + андроид студия отжирают три, и что теперь?
>Для пердоленья со слиянием и разбиением веток думаю можно скачать
Так блять, мердж - это как раз самое главное, для чего вообще git и нужен, если ты работаешь над проектом больше, чем в одно рыло.
>базовые вещи типа коммита буду лучше делать из ide'шного терминала
Но зачем, если есть кнопочка commit, которая сделает то же самое, только в сто раз быстрее?
>>520880
Альт таб делать не быстрее. Ты же сам сказал не разрывать workspace.
> Но зачем, если есть кнопочка commit, которая сделает то же самое, только в сто раз быстрее?
Альт таб делать не быстрее. Ты же сам сказал не разрывать workspace.
>>520899
Push надо тыкаться на тулбаре vcs -> git -> push
А pull и commit удобно вверху расположены.
Ну хоткеями еще могу.
Push надо тыкаться на тулбаре vcs -> git -> push
А pull и commit удобно вверху расположены.
Ну хоткеями еще могу.
>>520910
Емнип, в идее тулбар конфигурабельный, так что можешь туда и пуш вытащить.
Емнип, в идее тулбар конфигурабельный, так что можешь туда и пуш вытащить.
>>520899
Я перед коммитом запускаю gitk и смотрю, что я исправлял, а потом коммичу.
Я перед коммитом запускаю gitk и смотрю, что я исправлял, а потом коммичу.
Вы коммитите каждое маленькое изменение, или только когда какой-то кусок функционала закончен? Фиксапы и аменд-коммиты часто применяете?
4 Кб, 933x135Жёлтый строка коммит - инициализвация.
Потом красный, небольшой фикс хуиты.
Следующий красный тоже небольшой фикс хуиты (которую забыл поправить в предыдущем). Его решил сделать через commit --amend, но что-то пошло не так (наверное я свой пароль неправильно набрал в консоли) и нихуя не вышло закоммитить.
Он предложил мне сделать пул. В итоге специально что-то изменил (название переменной чтобы изменение было) и решил опять через --amend. уже ввёл пароль внимательнее и всё ок.
Но вот вышла такая хуита на пикче.
Как это исправить?
Потом красный, небольшой фикс хуиты.
Следующий красный тоже небольшой фикс хуиты (которую забыл поправить в предыдущем). Его решил сделать через commit --amend, но что-то пошло не так (наверное я свой пароль неправильно набрал в консоли) и нихуя не вышло закоммитить.
Он предложил мне сделать пул. В итоге специально что-то изменил (название переменной чтобы изменение было) и решил опять через --amend. уже ввёл пароль внимательнее и всё ок.
Но вот вышла такая хуита на пикче.
Как это исправить?
>>523121
Перед коммитом, перед пушем, перед началом работы, после окончания работы, да и вообще каждые полчаса, чтобы уж точно не обосраться.
Перед коммитом, перед пушем, перед началом работы, после окончания работы, да и вообще каждые полчаса, чтобы уж точно не обосраться.
>>523320
Можно скриптик на баше, чтобы каждые 20 минут пуллил, надо своему девопсу сказать.
Можно скриптик на баше, чтобы каждые 20 минут пуллил, надо своему девопсу сказать.
>>523013
Тебе теперь мерджить наверное
Тебе теперь мерджить наверное
>>239087 (OP)
Только так и делаю, лол. Юзаю гит черз гуй, сказали какие кнопки жать, жму. Если нужно сделать что-то, что еще не делал, делаю физический бекап на всякий случай.
>Второй, третий пик
Только так и делаю, лол. Юзаю гит черз гуй, сказали какие кнопки жать, жму. Если нужно сделать что-то, что еще не делал, делаю физический бекап на всякий случай.
>>239087 (OP)
По моему за такие названия уже бы уволили их. Никто так не называет, надо конкретно описать, что пофиксил. Короче, мем хуйня, сажа треду
>1 пик
По моему за такие названия уже бы уволили их. Никто так не называет, надо конкретно описать, что пофиксил. Короче, мем хуйня, сажа треду
Тред мертвый, но все же спрошу. Объясните на пальцах, как работать с Git-ом командой. Везде пишут, что задача проект дробится на задачи и над проектом в одно время работают N человек, которые создают N веток. У меня вопрос: Как мерджить в master, чтобы код добавлялся, но не выпиливал куски другого кода. Объясню еще проще: Если проект разбить условно по версиям:
Path1 version = 1.0
Path2 version = 1.0
Path3 version = 1.0
Над проектом работает 3 человека, каждый работает над своим куском. Когда начинаем мерджить в master, то что получается:
Мерджит 1 человек свой Path1:
Path1 version = 1.1 (условно)
Path2 version = 1.0
Path3 version = 1.0
Мерджит 2 человек свой Path2:
Path1 version = 1.0 (тут должен быть 1.1, но когда человек начинал разрабатывать проект, то версия его ветки была 1.0 и соответственно ее и замещает в master)
Path2 version = 1.1
Path3 version = 1.0
Спасибо за ответ
Path1 version = 1.0
Path2 version = 1.0
Path3 version = 1.0
Над проектом работает 3 человека, каждый работает над своим куском. Когда начинаем мерджить в master, то что получается:
Мерджит 1 человек свой Path1:
Path1 version = 1.1 (условно)
Path2 version = 1.0
Path3 version = 1.0
Мерджит 2 человек свой Path2:
Path1 version = 1.0 (тут должен быть 1.1, но когда человек начинал разрабатывать проект, то версия его ветки была 1.0 и соответственно ее и замещает в master)
Path2 version = 1.1
Path3 version = 1.0
Спасибо за ответ
27 Кб, 480x360>>555394
поясни за выше сказанное
поясни за выше сказанное
>>555394
уже разобрался с помощью наших забугорных друзей. Спасибо за наводку
уже разобрался с помощью наших забугорных друзей. Спасибо за наводку
12 Кб, 352x318Фигня ваш github desktop, я уже давно ПБшнул ветку, замерджил с мастером и удалил, а он все ее показывает. И это я еще вручную переключил на мастер, а так он там остался и хотел послать эту ветку на remote. fetch делал.
>>239087 (OP)
На хуй вы этотговно используете, на работе понятно, а для своих проектов нахуя?
На хуй вы этотговно используете, на работе понятно, а для своих проектов нахуя?
>>556914
Можно сделать ветку, чтобы попробовать сделать то, в чём не уверен. Чтобы можно было работать над проектом с любого компа.
Можно сделать ветку, чтобы попробовать сделать то, в чём не уверен. Чтобы можно было работать над проектом с любого компа.
>>556930
Что мешает сделать то же самое, используя официальный клиент гита, а не залупу от филиала мокросовт?
Что мешает сделать то же самое, используя официальный клиент гита, а не залупу от филиала мокросовт?
>>557467
Я думал у тебя претензии к самой VCS вне работы.
Я думал у тебя претензии к самой VCS вне работы.
Допустим у меня есть mvc проект с ~10 ветками, каждая ветка - кастомизация проекта под каждого клиента. У каждого клиента могут быть общие одинаковые части (до 90%), а могу быть разные общие части, а может вообще их не быть. Ещё у каждолго клиента есть отличия в базе данных. Соответсвенно, когда у меня баг в смежной части, допустим у 6 веток, то мне нужно либо вручную менять файлы, либо мерджить с конфликтами. Какой тут выход?
>>568051
Наглядная демонстрация на сколько оверхайпнута гита как и тестопараша - все равно что пытаться пилить дерево штопором и удивляться почему ничего не получается.
Наглядная демонстрация на сколько оверхайпнута гита как и тестопараша - все равно что пытаться пилить дерево штопором и удивляться почему ничего не получается.
>>568312
Кароче буду пытаться через controller injection в net mvc делать, и привести всё на этой параше галере к нормальному состоянию, хорошо хоть dynamic завезли.
Кароче буду пытаться через controller injection в net mvc делать, и привести всё на этой параше галере к нормальному состоянию, хорошо хоть dynamic завезли.
.git/config в принципе только локально существует и никакие изменения в нём при push/pull'е не уходят на сервер?
задача собственно имея одну локальную промежуточную копию репо с одного адреса пулить на другой пушить и что бы тот с которого беру не знал о втором
задача собственно имея одну локальную промежуточную копию репо с одного адреса пулить на другой пушить и что бы тот с которого беру не знал о втором
>>568051
У меня похожая ситуация, только там на поддержке проект написаный каким-то клоуном, где приходится держать два варианта. Изменения переношу черрипиком, в процентах 90 случаев без конфликтов. Второй (возможно) вариант - через патчи, но у меня не получилось с ними нихуя сделать. В общем гит для такой хуйни не предназначен.
У меня похожая ситуация, только там на поддержке проект написаный каким-то клоуном, где приходится держать два варианта. Изменения переношу черрипиком, в процентах 90 случаев без конфликтов. Второй (возможно) вариант - через патчи, но у меня не получилось с ними нихуя сделать. В общем гит для такой хуйни не предназначен.
>>568051
git rebase чем не устраивает? Не получается без конфликтов, выноси общую логику.
git rebase чем не устраивает? Не получается без конфликтов, выноси общую логику.
Гитхаб выпустил в бету свою CLI-утилиту `gh`. Любители попердолиться в заднюю консоль должны оценить.
https://github.blog/2020-02-12-supercharge-your-command-line-experience-github-cli-is-now-in-beta/
https://github.blog/2020-02-12-supercharge-your-command-line-experience-github-cli-is-now-in-beta/
>>599761
Х-Хуита. Сейчас бы Issue и Pull request через консольку делать, эх. Тут пока синтаксис gitbash с unix осваивал, думаю охуею, а они "утилитку" выкатили
Х-Хуита. Сейчас бы Issue и Pull request через консольку делать, эх. Тут пока синтаксис gitbash с unix осваивал, думаю охуею, а они "утилитку" выкатили
Ананасы, объясните такую мне штуку.
Вот, допустим, загрузил я код на гитхаб и у себя на компе репозиторий удалил, но потом возникла необходимость что-то сделать (исправить код, добавить или убрать что-то).
Что мне нужно будет сделать для этого?
Просто git clone, внести правки и git push?
Вот, допустим, загрузил я код на гитхаб и у себя на компе репозиторий удалил, но потом возникла необходимость что-то сделать (исправить код, добавить или убрать что-то).
Что мне нужно будет сделать для этого?
Просто git clone, внести правки и git push?
>>608689
да
да
>>601955
это для задротов консоли. Мне вообще похуй - я и в UI потыкаю. Тупо поебать
это для задротов консоли. Мне вообще похуй - я и в UI потыкаю. Тупо поебать
GCC переехал с SVN на Git, перенесли 280 тысяч коммитов. Вроде пока крупнейшая миграция.
https://www.phoronix.com/scan.php?page=news_item&px=GCC-Is-On-Git
https://www.phoronix.com/scan.php?page=news_item&px=GCC-Is-On-Git
>>239134
Скозала самопровозглашенная ойти-илитка в каментах швабры?
GIT к 2018-му году еле-еле догнал SVN по внедрениям, и то только благодаря помойке-гитхабу и массовому закрытию олдфажных публичных репозиториев, державших много SVN-ов. В оффлайне SVN до сих пор лидирует, лол, причем не только в "мелких" проектах и "бедном" энтерпрайзе (что бы этот ваш гит делал без помощи таких мощных ярлычков, а?)
>На данный момент - default version control system
Скозала самопровозглашенная ойти-илитка в каментах швабры?
GIT к 2018-му году еле-еле догнал SVN по внедрениям, и то только благодаря помойке-гитхабу и массовому закрытию олдфажных публичных репозиториев, державших много SVN-ов. В оффлайне SVN до сих пор лидирует, лол, причем не только в "мелких" проектах и "бедном" энтерпрайзе (что бы этот ваш гит делал без помощи таких мощных ярлычков, а?)
>>614623
Без причин неинтересно. Может барин из майкрософт приказал.
Без причин неинтересно. Может барин из майкрософт приказал.
>>239087 (OP)
Мимовкатывальщик.
Загуглю в тред.
Есть у меня С проект. Собирается в 4х конфигурация.
Хочется сделать версионность сборок "как правильно".
Сейчас просто меняю ручкой в хедере. И выглядит у меня это как
#define VERSION_MINOR 30
#define VERSION_MAJOR 0
У меня есть уютненький гит, я даже его всегда поддерживаю в актуальном состоянии.
Как правильно будет реализовать сборку мастер(ну или какой нибудь еще) ветки, с правильным и логичным переносом версии.
То есть:
Получил изменения в мастер.
Запустил скриптик.
Получил бинарник, в который зашита (current_version + 1)
Мне на ум приходят какие то велосипеды, вроде держать отдельный файл с данным для скрипта и тд.
Но какая то жопа же, не?
Мимовкатывальщик.
Загуглю в тред.
Есть у меня С проект. Собирается в 4х конфигурация.
Хочется сделать версионность сборок "как правильно".
Сейчас просто меняю ручкой в хедере. И выглядит у меня это как
#define VERSION_MINOR 30
#define VERSION_MAJOR 0
У меня есть уютненький гит, я даже его всегда поддерживаю в актуальном состоянии.
Как правильно будет реализовать сборку мастер(ну или какой нибудь еще) ветки, с правильным и логичным переносом версии.
То есть:
Получил изменения в мастер.
Запустил скриптик.
Получил бинарник, в который зашита (current_version + 1)
Мне на ум приходят какие то велосипеды, вроде держать отдельный файл с данным для скрипта и тд.
Но какая то жопа же, не?
>>617471
А как ты подругому сделаешь? Скрипт подвязываешь к хуку (git hook) там чекаешь ветку (скрипт вызываешь после мерджа в мастер) там можно просматривать сообщение (например вызывать скрипт только если в сообщении есть слово release или типа того).
> какая то жопа же, не
А как ты подругому сделаешь? Скрипт подвязываешь к хуку (git hook) там чекаешь ветку (скрипт вызываешь после мерджа в мастер) там можно просматривать сообщение (например вызывать скрипт только если в сообщении есть слово release или типа того).
>>617487
GIT я знаю плохо, команды гуглю.
Но как я понимаю, нет какого нибудь
git get commit number -master
Что бы его впихнуть в версию?
>git hook
>если в сообщении есть слово release
GIT я знаю плохо, команды гуглю.
Но как я понимаю, нет какого нибудь
git get commit number -master
Что бы его впихнуть в версию?
вот скажите нахрен нужня эта дрочильня с командной строкой, почему нельзя делать в визуальном редакторе?
>>618807
Можно, конечно. Спокойно в два клика коммитить/пушить, слушая фоном кукареканье про ненастоящих программистов.
Можно, конечно. Спокойно в два клика коммитить/пушить, слушая фоном кукареканье про ненастоящих программистов.
>>618807
мимо гитлох, очень не любивший консольный пердолинг
1.
Гит это просто система. К ней куча гуйморд есть.
И в половине из них разрабы не осилили и половино пердольного функционала.
У меня тоже бомбит, даже с учетом того, что я нехуя не умею, не хватает стандартного Гитхаб Виндовс.
2.
Автоматизация сборки. Я вот >>617530 >>617471
Заебался свой проект руками собирать, решил сделать батники под всю хуйню, а как ты ее из гуя будешь батниками вызывать?
У меня вот в проекте есть чисто гуй тулза и она из просто тулзы, превратилась в тулзу которая ебет мозги.
мимо гитлох, очень не любивший консольный пердолинг
1.
Гит это просто система. К ней куча гуйморд есть.
И в половине из них разрабы не осилили и половино пердольного функционала.
У меня тоже бомбит, даже с учетом того, что я нехуя не умею, не хватает стандартного Гитхаб Виндовс.
2.
Автоматизация сборки. Я вот >>617530 >>617471
Заебался свой проект руками собирать, решил сделать батники под всю хуйню, а как ты ее из гуя будешь батниками вызывать?
У меня вот в проекте есть чисто гуй тулза и она из просто тулзы, превратилась в тулзу которая ебет мозги.
>>618807
У меня обычно всякие непонятные ситуации возникают, и в итоге все равно приходится вручную через консольку, но в иде смотрю диффы, очень удобно.
У меня обычно всякие непонятные ситуации возникают, и в итоге все равно приходится вручную через консольку, но в иде смотрю диффы, очень удобно.
895 Кб, 2400x1272Гитхаб выпустил из беты свое мобильное приложение:
https://github.blog/2020-03-17-github-for-mobile-is-now-available/
Если ты смелый ловкий умелый модный зумер с лопатой вместо тилибона, ты просто обязан делать пулл-реквесты в перерывах между тиктоком.
https://github.blog/2020-03-17-github-for-mobile-is-now-available/
Если ты смелый ловкий умелый модный зумер с лопатой вместо тилибона, ты просто обязан делать пулл-реквесты в перерывах между тиктоком.
>>636398
Гисты тоже можно делать?
Гисты тоже можно делать?
>>636398
Ссылки на гитхаб репу нет? лол
Ссылки на гитхаб репу нет? лол
>>636398
Надеюсь, теперь на гитхабе рядом с пуллреквестом будет отображаться маленькое яблоко, при наведении на которое будет всплывать сообщение "Отправлено с iPhone".
Надеюсь, теперь на гитхабе рядом с пуллреквестом будет отображаться маленькое яблоко, при наведении на которое будет всплывать сообщение "Отправлено с iPhone".
> Последний оппик
Батя грит у него скрпит был на, который клал файлики с кодом в папку, которая называлась "дата-время"
>был на
На первой работе в 1998
Так, ананасы, пришла одна мысля связанная с гитом.
При работе с каким-то проектом возникает необходимость вести заметки и всякие примечания которые могут быть полезны сейчас или позже (например, если столкнулся с похожей проблемой в другом проекте, то можно будет заглянуть в заметки и глянуть как я её исправлял).
Придумал вот такое: для всех заметок, любых проектов, есть один репозиторий, в котором название ветки - проект.
Ответвление, думаю, не нужно. Ведь с программой работаешь в одном месте, а здесь ты только записываешь результаты или решения.
Когда проект стал не нужен, то либо удаляешь ветку либо архивируешь её ( https://stackoverflow.com/questions/1307114/how-can-i-archive-git-branches ) и при необходимости можно будет вернуться.
Правда, я не придумал что можно сделать с мастер веткой. Думаю в ней можно хранить общую инфу какую-то: что за ветки, к чему они относятся, какие ветки в архиве и тд.
Где я обосрался?
При работе с каким-то проектом возникает необходимость вести заметки и всякие примечания которые могут быть полезны сейчас или позже (например, если столкнулся с похожей проблемой в другом проекте, то можно будет заглянуть в заметки и глянуть как я её исправлял).
Придумал вот такое: для всех заметок, любых проектов, есть один репозиторий, в котором название ветки - проект.
Ответвление, думаю, не нужно. Ведь с программой работаешь в одном месте, а здесь ты только записываешь результаты или решения.
Когда проект стал не нужен, то либо удаляешь ветку либо архивируешь её ( https://stackoverflow.com/questions/1307114/how-can-i-archive-git-branches ) и при необходимости можно будет вернуться.
Правда, я не придумал что можно сделать с мастер веткой. Думаю в ней можно хранить общую инфу какую-то: что за ветки, к чему они относятся, какие ветки в архиве и тд.
Где я обосрался?
>>641093
Не пояснил. Обычно у меня лично заметки это всякие todo.txt/bugs.txt, т.е. набор текстовых файлов.
Не пояснил. Обычно у меня лично заметки это всякие todo.txt/bugs.txt, т.е. набор текстовых файлов.
>>641093
Ты бы ещё предложил построить БД поверх гита. Зачем он вообще здесь? Достаточно создать по папке для каждого проекта, а в папках хранить файлы с заметками.
Ты бы ещё предложил построить БД поверх гита. Зачем он вообще здесь? Достаточно создать по папке для каждого проекта, а в папках хранить файлы с заметками.
>>641100
Всё лежит в одном месте что нужно сейчас и может быть интересно потом.
Всё лежит в одном месте что нужно сейчас и может быть интересно потом.
>>641093
Зачем городить ветки если можно просто хуярить все в один файл? Или несколько, если тебе так нужно разделять по проектам.
Зачем городить ветки если можно просто хуярить все в один файл? Или несколько, если тебе так нужно разделять по проектам.
102 Кб, 383x350>>641093
Чувак, система заметок уже встроена в Git, правда об этом мало кто знает. Внутри оно устроено странновато на первый взгляд (как отдельная ветка, ссылающаяся на объекты-коммиты, хранящие заметки о других объектах), но снаружи это выглядит как и надо, как заметки, связанные с коммитами, тегами, деревьями или блобами:
http://alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html
https://git-scm.com/docs/git-notes
Чувак, система заметок уже встроена в Git, правда об этом мало кто знает. Внутри оно устроено странновато на первый взгляд (как отдельная ветка, ссылающаяся на объекты-коммиты, хранящие заметки о других объектах), но снаружи это выглядит как и надо, как заметки, связанные с коммитами, тегами, деревьями или блобами:
http://alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html
https://git-scm.com/docs/git-notes
>>641093
Ты обосрался везде, и пытаешься забивать гвозди микроскопом. Гит - это средство для хранения истории структуры папок на диске и больше ничего. Для описанной тобой задачи прекрасно подходят папки и файлы - для каждого проекта создаёшь папку, создаёшь папку «архив», куда складываешь ненужные проекты, и т.д., в общем организуешь структуру, в удобном тебе виде. И всю эту структуру трекаешь гитом: переместил проект в архив и сделал коммит «перемещен проект Х в архив» и так далее. Гит даст тебе возможность отката действий, параллельной работы над одним файликом с возможностью сравнить и обьединить эту работу и т.д.
Если структура в виде папок и файликов тебя не устраивает и тебе нужны какие-то более широкие возможности - тебе не в гит. Судя по твоему описанию ты себе выдумал будто «ветки» в гите это какая-то особая структура для хранения или отображения файлов. Нет, это совсем не для этого, так не работает и приспособить это для решения твоих плохо сформулированных задач не получится
Ты обосрался везде, и пытаешься забивать гвозди микроскопом. Гит - это средство для хранения истории структуры папок на диске и больше ничего. Для описанной тобой задачи прекрасно подходят папки и файлы - для каждого проекта создаёшь папку, создаёшь папку «архив», куда складываешь ненужные проекты, и т.д., в общем организуешь структуру, в удобном тебе виде. И всю эту структуру трекаешь гитом: переместил проект в архив и сделал коммит «перемещен проект Х в архив» и так далее. Гит даст тебе возможность отката действий, параллельной работы над одним файликом с возможностью сравнить и обьединить эту работу и т.д.
Если структура в виде папок и файликов тебя не устраивает и тебе нужны какие-то более широкие возможности - тебе не в гит. Судя по твоему описанию ты себе выдумал будто «ветки» в гите это какая-то особая структура для хранения или отображения файлов. Нет, это совсем не для этого, так не работает и приспособить это для решения твоих плохо сформулированных задач не получится
>>239087 (OP)
Слегка оффтопичное:
А может кто-то знает как запустить AppVeyor локально?
Наиболее официальный путь желателен.
Сижу на прыщах но надо одну кроссплатформу жырную прогнать через CI.
Слегка оффтопичное:
А может кто-то знает как запустить AppVeyor локально?
Наиболее официальный путь желателен.
Сижу на прыщах но надо одну кроссплатформу жырную прогнать через CI.
Анон, я ньюфаг.
Если на код ревью у меня запросили изменения, то что мне делать тогда? Просто запушить в ту же ветку?
Если на код ревью у меня запросили изменения, то что мне делать тогда? Просто запушить в ту же ветку?
>>656545
Стандартная практика же. На том же битбакете просто появится запись "updated" со списком новых коммитов, пуллреквест так и будет висеть.
Стандартная практика же. На том же битбакете просто появится запись "updated" со списком новых коммитов, пуллреквест так и будет висеть.
Ананасы, а есть ли для гита, какой-нибудь встраиваемый в репозиторий багтрекер, наподобие расширения "b" для меркуриала?
что за расширение можно здесь глянуть: http://www.digitalgemstones.com/projects/b/
---
что за расширение можно здесь глянуть: http://www.digitalgemstones.com/projects/b/
---
Анончики, еще вопрос. На гитхабе можно как-нибудь увидеть нормальное дерево коммитов всех ветвей репы?
(что-нибудь вроде того, что по gitk --all выводиться)
(что-нибудь вроде того, что по gitk --all выводиться)
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 12 июня 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 12 июня 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.