>>1035893 (OP)
несколько раз пытался использовать mercury, git, svn. Блядь, ну не прет у меня никак. Заебывает пуши делать и писать, что же я там исправил. Да и так и не понял, нахер они нужны мне лично. Ладно бы контора стопицот целовек.

Вот у тебя ОП много проектов? У меня около десятка приборов и на каждый программа нижнего уровня и у некоторых верхнего. У некоторых еще программа для настройки. Все по папочкам разложено, старые версии в архивах. Куча реадмишек. Блядь, ну не удобно мне все это в гит скидывать. Как вы до этого доходите?

>>1035893 (OP)
В приличном обществе это не обсуждается. Само собой любой программист обязан уметь работать с гитом в консоли. Если на собеседование приходит хер, который никогда их не юзал - для галочки спрашиваем еще пару-тройку вопросов и отпускаем к хуям.

>>1035899
Тебе лет 40 и ты пилишь софт для микроконтроллеров и СКАДА?
Может тебе оно и правда не надо, лол.

>>1035893 (OP)
Пытался вкатиться гит, но не осилил.
Храню версии в папках на компьютере.

>>1035919
Вкатился в гит, зависимость есть. Там ничего сложного. Судя по контенту гитхаба, гитом научились пользоваться даже хипсторы, они там дотфайлы с алиасами шэлла хранят со своих эпплов.

>>1035902
> обязан уметь работать с гитом в консоли

Ой, не пизди, достаточно знать названия команд.

Работать в сосноле - сорт оф изврат, когда речь заходит о визуализации всех этих диффов, бранчей-хуянчей, и т.д.

>>1035926

Ну может, в редких случаях сосноль бывает нужна.

Если случай не редкий - автоматизируй, хуй, или ищи норм. инструмент.

>>1035893 (OP)
Оп, ты что, дурак? Может, ты еще предложишь обсудить компьютеры на основании того, что все разработчики используют компьютер?
>>1035926
Ну вообще-то он прав. Если разработчик не знает add, status, checkout, push, pull, merge, stash, cherry-pick, иметь понятие зачем нужен rebase и что такое log, то возникают сильные подозрения в его компетенции.

> Работать в сосноле - сорт оф изврат, когда речь заходит о визуализации всех этих диффов, бранчей-хуянчей
Но и ты имеешь поинт. Консоль - заебись и удобно. Но проблемы, связанные с диффом - диффы, хистори и решение конфликтов, конечно, намного удобнее решать в CVS-инструментах. Сам использую гит баш и CVS-плагин иде для решения диффопроблем. Брат жив, тимлид счастлив.

>>1035929
> VCS
не проснулся

>>1035929
> достаточно знать названия команд.
> перечисляет команды

Ну так о том и речь, базвордами владеть надо. Где с ними работать - вкусовщина, а не пиздец обязан уметь, кстати rebase не нужен - деструктивные команды вообще нахуй не нужны.

>>1035932
> rebase не нужен - деструктивные команды вообще нахуй не нужны
Два чая. Жутко бесит, когда мержеров время от времени кусает бешеная псина и они требуют объединять коммиты в пр.

Но то, что он не нужен не означает, что не нужно знать зачем нужен рибейз.

>>1035935
Рибейз топик, если начал что-то делать в локальной ветке и внезапно докинули говна.

И нахуя мне все это, если просто тестирую как написать? Тогда и ctrl+z хватит

>>1035893 (OP)
Хуй знает зачем это тред. Любое более менее вменяемый разработчик с 3-5 годами опыта знает git, mercurial и cvs/svn опционально.

>>1036144
>любой

>>1035899
заставляет более упорядоченно мыслить, например я кодаю и вижу что опа тут можно кое-че поправить - но не правлю, вместо этого делаю пометку, забиваю хуй и делаю только то что касается текущего бранча. или пришла мне в головую ебанутая идея - бранчирую чтобы мастер не засирать, и если она не прокатила то и хуй с ней. без гита не представляю как можно жить.

>>1036239
>На самом деле в треде можно пощупать температуру по больнице: вот некоторые не юзают source control вообще. Было бы неплохо, чтобы народ также рассказал про свою деятельность: кровавый тырпрайз, смузихлебство, байтоебство, мамкин борщ с фрилансиком или что иное... ну и стек конечно же (подозреваю довольно сильно коррелирует)

Занимался сириус статистическим анализом, работали на аутсорс конечно же на оче крупную американскую контору.

Была своя самописная система управления проектами с макросами встраивающими нужную информацию в код.

Как правило каждый программист работал над одной небольшой программой в проекте, который состоял из дестяка - нескольких десятков таких программ.
Системы контроля версий - не было.

Делали бекабы постоянные.
Откатывать изменения приходилось всего раз и по жуткому проебу одного разработчика.

Планировали ввести систему контроля версий SVN, не знаю, ввели ли.
Все и так работало, и подходящих трудовых ресурсов под рукой не было...

Честно говоря, меня гит как-то не очень вдохновляет.
Я не могу проникнутся его суть.

Для совместной работы по моему он не подходит.

>>1035920
Судя по контенту гитхаба, некоторые личности собирают код, деплоят и перезапускают продакшн коммитами в репу с изменением комментария asadadsa на lk;k;l
>>1035902
>>1036144
>>1036297
>>1035935
А камрады пояснят про свою работу и используемый стек? Особенно интересно про должность мерджера

Вы бы кинули Где почитать про все это, а то стыдно. Я думал гит для бэкапов кода, чтобы не потерять в случае каких то корявых изменений, а там еще кучу всего. Дайте книжку или статью с реальными примерами, в идеале на русском, будем благодарны всем pr. (И не выебывайтесь про русский, понимать текст это одно, но тонкости работы сложнее, тот же tdd когда на русском прочел столько всего понял что пропустил в оригинале)

>>1036302
Вот как ты описал я так и делаю.

>>1036309
Что нужно прочесть чтобы понять соль шутки?

ПАМАХИТЕ

Удаленный дев сказал коммитить в бранч
Коммичу в бранч
Коммиты через какое то время пропадают о чем меня извещает тестер
В логах как будто я изменение пробелов закоммитил
Не выдержал, смерджил в мастер и запушал

Что это было?

вообще довольно часто мои коммиты пропадали из ремота. особенно после того, как я делал пул (другой дев со мной коммитил). в логах ничего не отображается, никакой потери данных, но мои фиксы исчезают и после пула их нет даже в моей локальной папке. что за хуйня творится?

>>1036302
Кровавый банковский тырпрайз. По принятию пров есть определенный регламент, включающий успешный билд на CI и обязательные апрувы от разных групп людей (в зависимости от пр и его контента) - команды, архитекторов бд, архитекторов приложений, команды мержеров и другие группы лиц.
> интересно про должность мерджера
Нечто среднее между архитекторами и код стайл адвокатами - ревьювят все пры и без апрува из их команды не вливается ничего.

>>1035920
>дотфайлы с алиасами шэлла хранят со своих эпплов
Эх, а раньше диск Цэ на винде расшаривали в DC++...

Почему кстати используют Github, а не bitbucket? Мне нравится последний тем, что не удаляют репозитории даже нелегальные (исходники opera presto, например) и с приватными репозиториями лучше чем у гитхаба.

Бля, это пиздец какой-то, я не могу себе это даже представить. скип какой-то, что происходит при конфликтамх, почему именно ветка Б перепишет твою ветку при конфликте. Этот гит нужно как отдельный язык изучать. У меня плохо работает пространственное представление.
https://habrahabr.ru/post/161009/

git

для пидоров
л
я

п
и
д
о
р
о
в

>>1036383
Или там notabug.org, savannah или тысячи других.

ПАМАХИТЕ Я НИАСИЛЯТОР НЕ МОГУ ОТЛИЧИТЬ РЕБЕЙЗ ОТ ЧЕРРИ ПИК КАК ВООБЩЕ В РЕМОТ РЕПУ ИЗ СВОЕГО БРАНЧА КОММИТЫ ПУШИТЬ?

всем привет я девочка)) :*)

А нет каких-то принципиально новых систем контроля версий? Ну, не знаю, может что-то на хаскеле использующее особую идеологию...

>>1036310
Сорцы над которыми работал обезьян изменились, и он неможет просто внести измениния из своего репа, нужно делать мердж.

Обезьяна это не устраивает и он перезаписывает репозиторий целиком своей версией, убивая все изменения внесенные другими.

>>1036444
Почему git позволяет --force в push?

>>1036441
>Это как я понимаю удобно для разработчиков одиночек
наркоман, гитапараша как раз для этих целей и не удобна

>>1036441
> Гит же не является централизованной системой контроля версий.
Ну это уже слишком толсто.

научите меня работать с ветками, молю. я больше не выдержу коммитов в мастер.
пытался через чекаут создать ветку branch. потом сделал
git -u push origin branch

но через какое-то время мои коммиты пропадают с remote

>>1036449
>>1036459
Прошу пояснить этот момент.

Разработчику необязательно хранить целиком весь репозиторий у себя?

Я могу поднять сервер, назначить логины\пароли\права доступа для разных групп и пользователей?

>наркоман, гитапараша как раз для этих целей и не удобна
А вроде именно так пиарилась.

>>1036464
>А вроде именно так пиарилась.
просто торвальдс нарокоман

>>1036307
man git
Не можешь в английский - закончи вуз, пидор.

Еб твою мать, блять.

>>1036432

Фотокарточку пизды в студию, с подписью и датой.

>>1036383
Спасибо, анончик, зарегался, доволен!

>>1035899
Можно просто коммитить всё без коммента, чтобы можно было потом откатиться назад. Этакий load-save, как в играх.

>>1035899
> Заебывает пуши делать и писать, что же я там исправил.

Нахуй не пиши, делаешь фичу в своем бранче, на эксперементы под-бранчи. Оче удобно переключатся между веточками и ничего не проебать, не надо по два раза одну мыслю писать.

Дескприпшен коммитов нахуй не нужен, пока не пушишь результат. Комментуруй коммиты - хуй1, пизда, хуй2, азазазаз, лалка - все ок, это твоя локальная веточка.

Сделал фичу, и мержишь из подветочки в свою веточку. Переписываешь историю коммитов, чтобы у тимлида встал, отправляешь пул-реквест.

Пушить по десять раз на дню - идите в нахуй, я неготово.

>>1036560
> Комментуруй коммиты - хуй1, пизда, хуй2, азазазаз, лалка
> Переписываешь историю коммитов
Охуенно, теперь предлагают комментировать джважды вместо одного раза. Даже одного раза много было.

>>1036438
>особую идеологию
К.У.Е?

>>1036565

enter тебе нажать лишний раз - слишком шложно?

Чукча не писака, чукча - программист.

>>1036567
Не сложно, а нахуй не нужно. Коммент к коммиту - лишняя информация, бесполезная совершенно. Сделать её обязательной пиздец как тупо было. Коммент должен быть к пушам и слияниям. Ещё бы обязательный коммент к каждой модификации файла сделали, ёбта.

>>1036572

> Коммент к коммиту - лишняя информация, бесполезная совершенно

В стадной разработке - метаинформация облегчает жизнь. Британские ученые доказали.


> Сделать её обязательной пиздец как тупо было

Ну ты же программист, епт. Напиши скрипт, чтобы "" пустая строка автоматом добавлялась, если коммента нету. Алиас к шкрипту и профит. Или погугли, ты наверняка не один такой, кто enter осилить не смог.

>>1036575
> делай хаки к тому, что должно отключаться и быть выключенным по умолчанию

>>1036578

GUI

>>1036579
HUI

>>1036447
Потому что в умелых руках бензопила - полезный инструмент, а в руках дебилов даже карандаш смертельно опасен.

>>1036383
Гитхаб лучше сделан. Битбакет в принципе справляется, но мне не оч комфортен стиль продуктов атлассиана, неинтуитивно, приходится копать чтобы найти что нужно, а в гитхабе такого почти нет: щёлкнул и сразу получил что хотел, не напрягая голову.

>>1036383
Что лучше впарили, то и жрут

Я девочка и не могу в гит. Научите за фотку писи?

Borland starteam

>>1036661
Давай. Я бы полизал.

Какой во всем этом смысл, если git clone в 2017 году не может в продолжение загрузки (по крайней мере когда я смотрел) да и в целом представляет из себя монструозную конструкцию?

>>1036566
Не знаю что это, но видимо не это.

>>1036761
Лол, какая-то другая система контроля версий может?

Git везде используется, пишется лично Линусом и поддерживается в Windows в Visual Studio и Team Foundation Server. А еще есть github с удобным графическим клиентом.
Остальные системы нинужны.

>>1037142
Где unix-way? То есть качать отдельными инструментами с возможностью докачивать.

>>1037154
git и есть unix-way, основной исполняемый файл только берет список параметров и передает их конкретной тулзе
то бишь git add --ignore-removal . вызовет git-add --ignore-removal . где git-add - отдельный испольняемый файл. И этой ебалы там 160 с хером штук, поэтому такие различия в синтаксисе комманд

>>1037185
>где git-add - отдельный испольняемый файл
Там скрипты помоему вапще.

>>1037268
Не, раньше было полно sh скриптов, сейчас все переписано на няшной сишке

Аноны, подскажите по markdown на гитхабе: как правильно сделать оглавление в readme? Вот у меня, допустим:
[CODE][раздел первый](#Раздел-первый-первый-раздел)
[раздел второй](#Раздел-второй-второй-раздел)

## Раздел первый первый раздел
## Раздел второй второй раздел[/CODE]
И половина работает, половина -- нет, не могу понять, чяднт?

>>1037154
И кому это может понадобиться в 2к17? У тебя что, инет через диалап до сих пор? Попроси выдать тебе репозиторий упакованный в архив и качай хоть частями, хоть целиком. И будет тебе без git clone.

>>1037526
>git clone
--depth=1

Что мне нравится в git - это субмодули. Можно накачать кучу библиотек в папку vendor, а потом их организованно так строить обновлять их все одной командой git submodule update

>>1037154

Была статья - мелкомягкие перепилили гит чтобы тот работал с террабайтами их индусского кода. Вообще, исходники открыты, раз тебе надо, то запили докачивание.

Совсем охренели, ругаться на бесплатный попен-сорс.

>>1037558
представте, какая кодовая база у майкрософт
они ведь сохраняют его аж с 84года
там просто сумашедший объем

>>1037566

Ну не в один репозиторий сохраняют (я надеюсь)

>>1037572
Было вроде около 20 реп (SourceDepot+TFS)
Стал один гитовский, под который пришлось запилить специальную файловую систему

>>1037963
Когда они уже опубликуют свои никому не нужные исходники?

>>1036557
Неверно, без -m ты сможешь закоммитить только хуй себе за щеку

Юзаю ртуть, паршивец для лохов и там нет бранчей.

>>1038128
>там нет бранчей
Шта?
Бранчи там есть, в отличие от гита
Гитовские поинтеры тоже есть - bookmarks

Гитаны, кто работал с git submodule? Удобно ли оно? Сильно ли удобнее чем стандартные пакетные менеджеры?

>>1038978

нипонял, это мне теперь репозиторий пересоздавать, если в персистентное хранилище условный пароль попадет?

>>1038978
джвачую, сам им пользуюсь, гитапараша нинужна

На работе TortoiseSVN онли пользовался. Одновременно человек 5 работало, так что хватало. Один раз долгую фичу пилил, хотел запилить ветку aka feature branch, но меня напрягало, что придётся всю недоветку хранить в репе.

На практике часто приходится консолью пользоваться? В том же гите? По какой причине?

>>1038989
Там есть shun для таких ситуаций - ты можешь удалять артефакты (конкретные версии файлов) и запретить своему репозиторию их когда-либо получать. Т.е., ты облажался, потом закомитил правильную версию без пароля, неправильную версию удолил. В результате в истории остались оба комита, все знают, что ты облажался, но первый комит ссылается на несуществующий артефакт.

>>1039033
> На практике часто приходится консолью пользоваться? В том же гите?
Каждые будни.
> По какой причине?
Удобнее для всего, кроме задач связанных с дифом.

>>1039081
>Удобнее для всего, кроме задач связанных с дифом.
Например?

>>1038978
О, это то я что искал! Хотя в общем есть принципиально новые идеи, но не суть. Суть в том, что есть подобное. Это, я потыкал его, очень удобно. Да, там есть веб-сервер и вообще идея удобная. но среди именно монстров-репозиториев нашел только chiselapp.com и он правда таки хорош минимализмом. По сравнению с gnu savannah намного лучше по удобству мне. А сам fossil мне показался просто очень удобным и теперь я таки начал напоминать зачем нужно все это и как это работает. Очень хорошо по сравнению с другими монстрами для меня опять же. Вот действительно хочется начать его использовать.

>>1038978
>>1039029
Может я на радостях, расскажите о своем опыте использования подробней, пожалуйста.

Мне с ветками не понятен один вопрос. Вот говорится, мол когда-то системы контроля версий создавали под ветку отдельную папку, что представляется очень простым и логичным, но как говорят, медленным. И тут люди решили напилить блобов и сделать дабы файлы не пойми как заменялись и такое подобное. Как это вписывается в семантику файловой системы?

>>1039121
>расскажите о своем опыте использования подробней, пожалуйста.
берешь и пользуешься, что рассказывать?

>>1039126
Как говорил наш замполит: "Ты хуй изо рта вынь прежде чем говорить с людьми!"

>>1038173
>Бранчи там есть, в отличие от гита
А я что написал? Паршивец и есть гит.

>>1036572
Просто напиши макрос под свой EDITOR чтобы он # убирал в сообщению к коммиту, которое git оставляет по умолчанию. Или прочитай проgit. Там наверное будет написано как дефолтный commit messag настроить.

>>1039153
>Как говорил наш замполит: "Ты хуй изо рта вынь прежде чем говорить с людьми!"
У Вас там хуи во рту держать распространенной практикой было?

>>1039153
Помню, как-то раз в компании один офицер рассказывал: "Вот был у нас в роте один хуй..."
А я говорю: "Уважаемый, правильно говорить не в роте, а во рту."

>>1039126
Этот подход сохранился в SVN. Научились быстро создавать "ветки"-папки и они ничего не весят.

>>1035929
>то возникают сильные подозрения в его компетенции.
>>1036144
>>1036239
Фриланс вебдев. 15 лет коммерческого опыта.
php/nodejs/go, js, html/css, mysql/sqlite/mongo
Не использую VCS совсем.

>>1039853
Фриланс как бы намекает, что твои проекты короткоживущие, а в команде ты не работаешь. В том и причина.

Анон, дабы не создавать отдельный тред запилю вопрос сюда.
У нас есть идея веб-проекта внутренний инструментарий с доступом со всех обьектов для нас, строителей, даже накидан костяк прошлым программистом и кое-как работает. Прошлый чел сьебался не пофиксив свои косяк, не доделав многого, поэтому мы переписываем договор и нанимаем нового. Как обезопасить себя от бекдоров, слива инфы и прочего недобросовестного отношения программиста-фрилансера? Идея такая - поднимаем какой-либо version control, куда этот программист пишет. Оттуда автоматом все перекидывается на продакшен сервер, ибо прогер все-равно один. В случае конфликтных ситуаций, подозрений итд, поднимаем логи, диффы и смотрим, был ли злой умысел и ебем его договором через суд или убеждаемся, что это был взлом и слив по другим каналам.
Так вот, вопрос - правильно ли я понимаю то, как эти системы работают? Можно ли будет посмотреть, когда была сделана правка, приведшая к печальным последствиям? Может ли программист как-то влиять на эти записи и удалить лог именно по спорной записи - т.е. она будет на продакшен сервере, а в логах version control ее не будет и он свалит все на прошлого программиста, мол это до меня было? И, так как система эта с нас - можете ли назвать плюсы и минусы той или иной системы и какая нам подойдет оптимально для этой задачи? Сам я не айти, разобрался лишь слегка на уровне покупки и запуска линукс сервера на centos.

>>1039888
судя по тексту программист не зря от вас съебался
>Сам я не айти
ну так съеби отсюда, или плати бабки за консультацию

>>1039888
Для начала: никому не нужен твой веб-проект.

Чтобы нельзя было удалить данные с системы контроля версий, нужно правильно настроить права на ней. Настройка зависит от системы.

Устанавливать на сервак сам собираешься?
Анализ изменений кода делать сам собираешься?

>>1036383
У них разная ценовая политика. Где больше подходит твоей команде, тот и юзаешь.

>>1039915
> Устанавливать на сервак сам собираешься?
Видимо да.
> Анализ изменений кода делать сам собираешься?
Это будет в случае, если база уплывет и будут подозрения в т.ч. на бэкдор. Будем нанимать в таком случае.

>>1039977
У тебя на самом деле 2 пути:
1. Учишься сам прогать.
2. Находишь деньги на проект, чтобы не кидать фрилансеров и не бояться за бекдоры.

>>1039981
Деньги есть, кидать не собираемся. Но работать просто на доверии я в рот ебал после того, как сьебался прошлый.

>>1039984
Тогда тебе просто нужно найти нормального спеца, раз такой пушистый.
Предыдущего как нашёл? Шоб нидораха был?

>>1039985
Спец тоже есть. Под него и пишем договор. Прошлый был по знакомству и без договора, увы увы.

Т.е. он спец = программист. Но ему надо предоставить нашу работающую систему контроля версий.

>>1039986
Я знаю только способ через SVN. Ставишь сервак с VisualSVN, там можно настроить права пользователей. Ну и вся настройка.
Соль в том, что в SVN по удалёнке сохранённые изменения практически нереально поменять, если не давать доступ к самому серваку с репозиторием.
В Git'е пердолинга с настройкой гораздо больше. + в Гите можно коммиты по удалёнке править, что тебе вообще не подходит.

>>1039888

Что значит не доделал? Сделал, но вам, как оказалось, нужно немножко другое? Это нормальный процесс разработки, вы платите за развитие своего продукта.

>>1039995
> Что значит не доделал?
Были указаны баги (мелочь всякая, типа ИТОГО не суммирует, хотя в форме прописана эта графа), на которые он согласился и написал что исправит без дополнительной платы. Напомнили ему через неделю и еще через две недели. В ответ были только обещания поправить и дальнейшая тишина.
>>1039994
> Соль в том, что в SVN по удалёнке сохранённые изменения практически нереально поменять, если не давать доступ к самому серваку с репозиторием.
Ага, спасибо! Почитаем сейчас.

>>1039994
> Ставишь сервак с VisualSVN
Гугл пишет, что он виндовый онли. Но я ведь могу развернуть у себя на центОС сервак, дабы не плодить сущностей. Выбирать любой не брошенный проект? Они все в базовой функциональности одинаковые, я так понимаю?

>>1040001
Это просто пакет всё в одном, с удобным гуем. Но вот, например:
https://www.howtoforge.com/tutorial/how-to-setup-a-svn-server-on-centos-6/

>>1040002
Спасибо за помощь! Буду разбираться дальше, наверное все же куплю часок-другой у какого-нибудь линуксоеба, дабы он в консультативной форме обьяснил чего и как и помог настроить.

>>1037154
Скачай репозиторий в архиве. Некоторые гит хостинги умеют

>>1040169

RAID 1, скрипт в кроне на синхронизацию папок с удаленным сервером. М?

>>1040178
Чего только не придумают, только бы не делать 2 лишних клика, чтобы запушить изменения.
И ещё миллион оправданий, почему комменты к комитам не нужны

>>1040189
>запушить
запетушить

>>1040305
Зачепушить

>>1040189

Ну я могу на коленке набросать говнокод за 5 минут, который будет работать, эдакий proof of concept, но в удаленный репозиторий такое просто не нужно добавлять.

>>1040461
Обязательно нужно. Бранчи придумали в том числе и для этого.

Все-таки гит - это только для веб-хипстеров, у которых каждая правка может разломать весь сайт, поэтому каждому выдается веточка, пуш в мастер запрещается, а каждая правка логгируется и содержит подробный коммент длиннее правки.

>>1040532

Нет, не нужно, тебе бы только захламить кодовую базу избыточным, нигде неиспользуемым кодом. Думаешь кому-то интересно читать твое говно?

>>1039033
Я в тортилле только логи смотрю. Вообще не могу этими гусями пользоваться. У гитхаба еще нормальный гуй. А так только консоль. Где там в гуи специализированные команды типа rebase искать хз

>>1040538
Лел, он разрабатывался (и используется) для ведра линупсов.

>>1040544

Линупсы разрабатываются по-почте до сих пор, не?

>>1040544
>для хипстеров, у которых каждая правка может разломать всё ядро, поэтому каждому выдается веточка, пуш в мастер запрещается, а каждая правка логгируется и содержит подробный коммент длиннее правки.

>>1040538
Блять, охуительная история просто. Я хуею с зк. Откуда вы вообще лезете, блять?

>>1040545
https://git.kernel.org/

Git же Торвальдс написал (автор линупсов).

>>1040541
> Думаешь кому-то интересно
Да. Когда возникнет вопрос, почему выбран вот этот конкретный способ реализации, и что имелось в виду в каком-то месте кода, можно проследить историю вплоть до прототипа и разобраться, а не спрашивать того, кто писал код десять лет назад, успев после этого уволиться и умереть.

> захламить кодовую базу избыточным, нигде неиспользуемым кодом
Ты что-то путаешь. В основной ветке неиспользуемого кода быть не должно (даже закомментированного). Для этого, как я уже говорил, есть бранчи, и их можно закрыть, когда дальнейшее развитие того же прототипа не предвидится. А размер репозитория особого значения не имеет, да и код жмется хорошо в любом случае.

>>1040551
Так.

>>1040538

А потом коммит ревьюится парой мейнтейнеров, и публично обсуждается каждая козявка, эт и есть опенсорс.

>>1040562
Я о статье на хабрахабре, там критикововалась методология разработки и ревью кода на ядро unix.

>>1040565
> публично обсуждается каждая козявка
Между тем, софт как был говном, так и остался.
> эт и есть опенсорс.

>>1040569
Охуенный софт, не пизди.

>>1040572
> aborted, core dumped

Почему удаленный дизайно-тесто-заказчик меня унизил, сказав что я учу гит и учу джиру? :( сравнение было с графиками и в пример привели меня. Это как-то обидно, я разработчик, а не командный юзер джиры и гита :/

>>1040573
Ты лучше вспомни СИНИЙ ЭКРАН СМЕРТИ, хотя, ты же школьник, уже не видел такого.

>>1040563
>Да. Когда возникнет вопрос, почему выбран вот этот конкретный способ реализации,

Если эту задачу уже решал то никаких прототипов не будет вообще, отдам решение. Если ты хочешь поговорить о методологии, то давай определимся, нужно ли документировать опыт. Ответ - не нужно, ибо долго и дорого для бизнеса.

> Для этого, как я уже говорил, есть бранчи,

Если тебе дали KPI на отрисовку котиков, то задача не плодить куст из 4 бранчей, где ты выбираешь библиотеку по рисованию, а отдать бранч который закроет таск. Три остальных бранча у себя оставь - никому нахуй не интересно, почему одна библиотека у тебя не завелась, вторая не подошла по интерфейсам, третья с кучей зависимостей. Потом на вечеринке в кругу задротов расскажешь, если к месту будет.

>>1040572
Монолитное говно с уязвимостями без принципа KISS.

>>1040581
> модульное ядро
> монолитное говно
Скорей бы сентябрь.

>>1040583
Ну, да, когда уязвимость в модуле дает root-доступ.

>>1040569
>Между тем, софт как был говном, так и остался.

Через годик новую версию выпустим в релиз, там не будет старых багов. Будем повторять пока не надоест, потом все перепишем и см. начало.

>>1040576
Видел. Только на винде я его видеть перестал, а на линуксе кернелпаники вижу периодически - качество опенсорсных дров как всегда на высоте.

>>1040611
Не знаю. У меня всё работает.

>>1040581
А что там такого сложного в ядре, что можно было сделать проще?

Непроебамп

Вкатился в опенсорс, сделал первый в жизни пулл реквест, и его приняли. Хочу продолжить работу над проектом, а тогда, я так понимаю, мне надо вытащить последнюю версию из родительского репозитория и работать в ней. Как это сделать правильнее?
Репозиторий на github. Я начал с того, что форкнул его, потом склонировал к себе на компьютер, дописал модули, запушил в свой репозиторий, оттуда уже делал пулл реквест. Прочитал, что надо из ветки мастер написать так:
$ git fetch upstream
Получаю такое:
fatal: 'upstream' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Что здесь подразумевается под upstream?

>>1050194
https://help.github.com/articles/syncing-a-fork/

>>1035893 (OP)
https://habrahabr.ru/post/336470/
>Пожалуйста, реализуйте пулл-реквесты и трекинг багов, охватывающие различные репозитории одного монодерева.
Они говорят, что им не нравится то, что это центрлизованно и хотят как в fossil, а пока должны мучить себя списками рассылки?

>>1036192
> вижу что опа тут можно кое-че поправить - но не правлю, вместо этого делаю пометку

А так можно в git? Или чем ты пользуешься?
И чем это отличается если в коде коммент TODO: написать?

Сап, пасаны. Имею удаленный репозитарий на сервере. Пушу туда изменения - выдал ошибку, мол, конфликт интересов, хотя я его с момента создания не менял, тем более, в продакшене. Хуй с ним, поправил его на сервере вручную был both modifed. Сегодня делаю очередной пуш - говорит, мол, файлы на сервере были модифицированы, отмена. В результате, все правки висят на сервере как "Изменения для коммита", пуш и пул говорят, что версии совпадают, а по логам нихуя. ЧЯДНТ? раньше такой хуйни не было.

>>1052614
Понял, что проебался, там есть bare и хуки. Только все равно нихуя не понятно, как это все там отобразить. Хардом сделать пуш? Как блять вообще управлять этим?

>>1052671
гит для пидоров, страдай

>>1052574
>А так можно в git? Или чем ты пользуешься?
да нет, просто записываю в .тхт файл или fixme коммент ставлю.

>>1052574
В жидее есть плагин для заметок.

>>1036557
Я тоже как-то на автомате добавляю ничего не комментируя: вместо коммента дата и время.
Зато потом можно восстановить какие когда изменения были, когда забацал какую-то функцию, отразить в ее версии эту инфу.

>>1053070
У коммитов и так есть таймштамп, додик

>>1035902
Ну и дураки. Обучить программиста программировать сложнее, чем научить любого хера с улицы делать коммиты. Если программист еще не умеет этого делать, значит в этом не было надобности или он только начинающий - для одиночной разработки (учебы) гит не нужен - это переизбыточность. А на гитхаб хуйней и поделками 2*2=4 засирать вредно для поиска нормальных вещей, да и вообще гитхаб тоже мало отношения имеет к языкам программирования и программированию вообще. Это ЧСВ соцсеть для петушков и инструмент для серьезных проектов, а не одиночных я-тут-себе-наваял программеров.

>>1053072
Он нужен для любого проекта больше хеллоуворлда (1000 строк). Бранчи вот редко нужны.

>>1053073
... при разработке в одиночку.

>>1053073
Что-то я пока что особой нужды в нем не испытываю. Заменил архивирование версий на сваливание скриптом в git. Очень редко когда смотрел историю какого-либо файла (всего несколько раз за несколько лет). Спрашивается - а нахуя он в общем-то нужен по большому счету?

>>1053077
А может мне просто нужна другая VCS, которрая умеет что-то более интересное, чем git, но я просто о ней не знаю?

>Заменил архивирование версий на сваливание скриптом в git
>архивирование версий
>Бранчи вот редко нужны
>на автомате добавляю ничего не комментируя
>и вообще гитхаб тоже мало отношения имеет к языкам программирования и программированию вообще
орнул с ванек-долбоебов, когда уже лето закончится

>>1053078
для вас долбоебов, умные люди придумали fossil, нет бля, хотим жрать говно, хотим git

>>1053079
Нахуй бранчи скажем для небольшого скрипта? - Ты ёбнутый?
Или для разработки в одиночку, когда нет других версий кроме тех, что ты сам делаешь, то есть нет чужого вмешательства и необходимости мержить версии разных долюоебов в одну?

>>1053080
>fossil
А чем он лучше?

>>1053084
всем

>>1053071
Ой, да ладно - просило что-то вводить, вот я и дал ему что-то. К тому же можно в своем формате сделать - у меня вот с миллисекундами. :) А вообще мне похуй - главное, что на автомате и меня не напрягает.

>>1053084
Конкретнее.
Кстати, в Fossil поддержка Unicode в именах файлов есть?
А то hg/Mercury вот обосрался.

>>1053088 -> >>1053086
ночные глюки

>>1053088
есть, скачай да попробуй.

>>1053083
соси хуй быдло руснявое, пиздуй иди документацию и философию гита и бранчей читать
>>1053084
ничем. придешь в любую контору вменяемую - будешь работать с гитом

>>1053094
>будешь работать с гитом
стильно, модно, молодежно. по факту каргокульт хипстоты.

>>1035893 (OP)
Пиздец, как бороться с мердж конфликтами? Возникают на пустом месте просто.

>>1053094
>философию гита
том #5, как из системы контроля версий сделать монструозное говно.

>>1053096
git mergetool

>>1053099
Бля, а я руками это всё переделывал в SmartGit

>>1053104
>как там в 2005?
заебись, не нужно читать книги и кучи форумов, что бы сделать элементарную операцию.

>>1053093
Понимаешь, во многих она заявлена - вот в hg она тоже вроде есть. Только оказывается не все символы поддерживаются - если встретит файл с неподдерживаемым символом, то тихо глюканёт, и следующие за ним в очереди файлы и каталоги добавляться в базу никогда не будут, и ты не узнаешь, если случайно не заметишь.
В общем, - Mercury - глючное опасное говно.

>>1053104
Блэт, я хотел чтобы конфликтов в принципе не было, а не продолжать ебаться с разрешением конфликтов на пустом месте

>>1053107
>не нужно читать книги и кучи форумов
просто твой мозг закостенел и не способен воспринимать новую информацию. новое вызывает дискомфорт, неуверенность - у дидов часто так бывает. ну ниче, накати пиваса и посмотри путина по телеку. я пришлю тебе открытку с мальдив

>>1053094
свинья не палится
>философию гита и бранчей читать
Вот есть каталог с кучей маленьких проектов, большинство которых - один файл. Какая нахуй философия, долбоеб? Ты предлагаешь эти сотни файлов каждый в свой каталог засунуть и в каждом отдельную git базу завести? И БРАНЧИТЬ маленькие файлы размером в сотню строчек, а иногда вообще в 10 строк?
Ты у мамы дурачок - так и скажи.

>>1053094
>ничем
А что в гит завезли возможность документирования проекта и багтрекинга?
А если гит/комп/свет глюканет во время работы гита - что будет с базой гита?

>>1053104

github с названием git* в начале и тербования HR на собеседованиях показать проекты на гитхабе всё порешали. Это не значит, что он лучший. Вон PHP тоже стандарт де-факто, но лучший ли он язык?..

>>1053110
>просто твой мозг закостенел и не способен воспринимать новую информацию
пятак, вещи должны быть простыми и эффективными, когда для вката в гит нужно прочитать джве книги это очень и очень плохо.

>>1053110
Тебе время девать некуда больше, чем читать ненужное?
Приши фотку как тебя там в жопу ебут с твоей мамашей

>>1053111
учись код организовывать как белый человек, а не крепостная пидорашка. ну и для монорепов есть решения - гугли
кстати я не хохол - твой детектор говно, неудивительно что ты не можешь гит понять лел

>>1053112
>А что в гит завезли возможность документирование проекта и багтрекинга
Внезапно да, и уже как пару лет
>А если гит.комп.свет глюканет во время работы гита - что будет с базой гита
А нихуя не будет. В самом худшем случае спилишь последний коммит.

>>1053117
Нет - может быть разрушена база.
А у Fossil транзакции.

>>1053115
так я только вчера твоей мамаше за щеку стрельнул, вылетело из жопы и так родился ты :)
>>1053114
вкатываться в любую вещь нужно постепенно. если будешь пытаться осилить сразу на 100% - продуктивность ноль - умрешь нищим не написав ни строчки велосипеда. прочитай про общие возможности чтобы знать что гуглить при случае и врубайся по ходу дела

>>1053116
>>гит ом пользуюсь, но он не устраивает
>не можешь гит поднять
Сразу видно - куришь слишком много марихуаны.

Что за монорепы? Ты новый термин придумал?

Интересно - а как по твоему ещё организовывать сборники мелких утилит?
А то, что в git это не продумали (даже несмотря на наличие GNU утилит) - говорит об их тупоголовости. Git полезен толко для крпных проектов, особенно распределенных между сотрудниками, а на мелких он практически бесполезен.

>>1053119
>вкатываться в любую вещь нужно постепенно.
ой, иди нахуй. ты наверное чтобы посрать сходить, тонны книг прочитал. твой гит не стоит затраченного на его изучение времени.

>>1053120
>Что за монорепы? Ты новый термин придумал?
https://www.google.com/search?q=Monorepo&pws=0&gl=us&gws_rd=cr
ээ ну ты выдал дидуль. ты наверн на анси с еще пописываешь на атлоне под лфс? вобщем я не буду с тобой дальше спорить - боюсь отупею. в биографии черкану про тебя строчку, каким ты был тупым, чтобы потомки знали

>>1053122
ребенок принес какую то хуйн

>>1053123
ю

>>1053122
А что не так с AMD?

>>1053121
>твой гит не стоит затраченного на его изу
все что тебе нужно сделать чтобы вкатиться это git init, git add, git commit, git push. и гит не мой, а линуса, ну и мне пох, я ж не дегрот

>>1053126
Ну я вот так вкатился давно.
И что?
Бесполезное говно же.

>>1052614
Бамп вопросу, поясните за bare, парни, все уже перечитал, вменяемой инструкции не получил.

>>1039862
Но опровергает тезис о том, что оптыный программер обязан знать git

>>1035902
>В приличном обществе это не обсуждается

сидит на Дваче
>приличный

>>1036566
>А нет каких-то принципиально новых систем контроля версий?
>К.У.Е
Что имелось в виду, не понял?

>>1036466
Да не, все правильно - git для независимых одиночек, работающих над какими-то общими проектами. Как Linux. Но проекты должны быть расшарены и доступны для форканья. То есть идеология форков или всеобщих проектов типа gnu.

А для работы структурированных компаний git это вобщем-то не совсем то что нужно. Может Fossil здесь получше будет.

Ну а для одиночек, которые никуда ничего не выкладывают git вообще переизбыточен, слишком сложен/запутан/много лишнего и потому не нужен.

>>1036459
Она ближе к децентрализованным.

>>1036467
В вузах английскому не учат, как и в школах, и на курсах.
Учить надо самому.

>>1037566
>сохраняют его аж с 84года
Ну тогда Билли как все остальные сохранял в версии каталогах или архивах, а не в VCS, я уверен.

>>1037148
> github с удобным графическим трояном
поправил ошибку

>>1038173
А в чем разница поясните?
И что еще Ртуть умеет интересного?

>>1053146
Пшел нахуй. Заебал русоб тухлый.

>>1053169
у тебя sqlite порвался
просто не будь тупым пидорашкой в след раз. а пока сосни макакер крепостной

Ну явно если покажешь работодателю http://chiselapp.com/ и напишешь вместо пше git какой-то fossil то он покрутит пальцем у виска, а если напишешь git, то придется работать с таким ненавистным github и прочем. Так разве что только на донаты от корпораций жить, как собственно и у автора fossil

>>1053249
К слову, fossil поддерживает Zed Shaw, известный по https://learncodethehardway.org/ и http://programming-motherfucker.com/

>>1053249
http://fossilrepos.sourceforge.net/
А, ну, еще sourceforge, но у него вроде репутация стала плохая.

>>1053146
>гит тред
Детектор почини,лол

>>1053321
что ты имеешь в виду? в 2017 version control это git - все остальные системы либо легаси либо кал, слепленный одиноким задротом в мамкином подвале, никем не используемый.

Я работал с SVN + тортик. На новом рабочем месте Git(Hub) используют. Мне страшно, если честно.

>>1053335
>в 2017 version control это git
нет. готовься лучше к школе.

>>1053185
ребенок, не рвись так.

>>1053094
> соси хуй быдло руснявое, пиздуй иди документацию и философию гита и бранчей читать
Нет смысла в миллионе бранчей, если они все превращаются в прямую линию мастера и затем удаляются.

>>1053185
>крепостной
От видеораба слышать такое смешно.
Ты такой злобный, потому что ущемлённый.

>>1053388
Ты же понимаешь, что ребенок стремится быть как все. При этом считает, что понимать не обязательно, разщ дяденьки-тетеньки в рекламе сказали что вещь топовая надо брать, то слушаться, не думая что в реальности это может быть калом.

>>1053866
не, от природы такой. что такое "видеораба"?
>>1053867
ого, посмотрите - пошла в ход тяжелая артиллерия угадывания возраста на анонимной борде. может мемчики запостишь еще, взрослый ты мой? я понимаю что в мясокомбинате в алтуфьево, где ты пишешь дрова для говномешалки 99 г выпуска, время остановилось, поэтому не обижаюсь и от ваньки в лаптях многого не ожидаю.

>>1053877
>угадывания возраста
Что там угадывать? Такие как ты умирают не повзрослев. Так что никто ничего не угадывает, - всё очевидно.

Но если интересно, я думаю, ты хипстер шлюха, хотя это и не важно, насекомые мне не интересны.

>>1053886
чини детектор, ванька. 27 лвл, жму 130 и живее всех живых - ржу в лицо деградантам вроде тебя и обоссываю

>>1053891
>жму 130
Ну "жми", "жми", не надорвись, убогое...

>>1053886
>насекомые мне не интересны
Ты странный тип.

>>1053894
ладно не ссы я ничего личного не имел в виду, абу разрешил https://www.youtube.com/watch?v=xTfDXA0Bras

Меня очень смущает активный форс гита всякими конторками, включая гейугол и негрософт, поэтому я хочу съебаться на битбукет и хг. В целом всё решено, но есть два вопроса:
1. Можно ли на битбукете иметь свои переменные? Типа ключи хранить или ещё что-нибудь.
2. Какие вообще интересные проекты со свободным участием на битбукете есть?

>>1058870
1. Можно.
2. Есть, но надо искать. Но в основном мелкие проекты, например такие https://bitbucket.org/ArmanHayots/olang

>>1059108
Так и не понял, про что проект.

>>1058870
Чоблять. Битбакет это тоже гит.

>>1059229
>Чоблять. Битбакет это тоже гит.

>>1058870
>hg

>>1059108
Чья-то лаба.

>>1059229

Но не социалочка, как гитхаб.

>>1037965
Если ты про исходники модификации гита то гугли gvfs, там сделано на уровне файловой системы, сам гит всегда думает что выкачал все файлы, но на самом деле они подгружаются по затребованию. Сорцы открыты.
Если тебе интересно когда выложат сорцы шиндошс - иди нахуй никогда.

>>1059318
>gvfs,
ебать гитодауны наркоманы. когда там гит ос?

>>1053251
т.е. человек, который сам не программирует, а лишь УЧИТ это делать? Так себе авторитет.

>>1053152
> Ну а для одиночек, которые никуда ничего не выкладывают git вообще переизбыточен, слишком сложен/запутан/много лишнего и потому не нужен.
С этим соглашусь, но у работодателя часто стали появляться строчки в требованиях, чтобы в резюме была ссылка на твой гит с проектами блять.

>>1053152
> одиночек, которые никуда ничего не выкладывают
> никуда ничего не выкладывают
Таким печь нужна.

>>1059481
Поддвачну >>1058870 , конторам как раз меркуриал удобнее. По сути это тот же SVN, только с децентрализацией и прочими плюшками.
Другое дело, что он куда надёжнее. На моей памяти за всё время ни разу не видел ситуаций, которые были с гитом - тот же merge hell или "все используем одинаковые сборки и версии гита, чтобы не было конфликтов". Да, есть непривычные после гита моменты, например можно сливать вместе только по две ветки за раз, нет отката коммита (нужно досылать исправляющий коммит), нет поддержки гитхабом (но bitbucket не хуже, а где-то и лучше), и вообще всё изначально строже - но к этому привыкаешь как к чему-то логичному.

>>1059395
Пф, ты ещё гуру всего нытия Джона Скита вспомни.

Я нахожу фоссил неплохим для личных проектов. Это реально система для одного-пяти человек, без наворотов, но стабильное как камень.

Что-то показания разнятся...
Кто-то говорит, что vcs не все используют
Кто-то говорит, что 100% людей уже сидят на гите (за референсом можно в тред-опросник пройти)
Кто-то говорит, что гит давно устарел и все давно переходят на Bazaar и Fossil
А какое же в действительности распределение? Кто на чем сидит? Пробовал смотреть опросник stackoverflow - так там вообще странная херня - судя по 2017 году все vcs кроме гита вымерли, судя по 2015 году - гит не особо то и продвинулся. Потому что в 2015 году вопрос был с множественным выбором, а в 2017 - с единственным.
Неужели народ, когда говорит, что использует в качестве vcs гит, лукавит - и на самом деле использует несколько разных систем.
Или все просто потому что резюме на гитхабе требуют?

>>1067501
Это как с реляционными базами данных. Они вроде бы не совсем прямо совершенны, где-то сложные, где-то легаси тянется, где-то всё ещё нерешённые проблемы. Однако они покрывают почти 100% потребностей, индустрия пользуется и не мычит.

>>1068401
Но ведь личности, утверждающие что MySQL лучше Oracle, сидят таки с MySQL а не Oracle

>>1069511
Хотел бы я тут видеть этих личностей.

>>1067501
>гит не особо то и продвинулся
в 2015 на вопросы отвечали 26к разрабов, в 2017 64к, т.е. рост около 250%

>>1069511
Это к чему аргумент?

Проясните по гиту. Есть репозиторий из пяти коммитов.
1. Можно ли объединить два коммита с сохранением всех последующих?
2. Можно ли удалить коммит как будто его и не было с сохранением изменений после него?

Как посмотреть сообщение последнего коммита (или всех коммитов) при выполнении "git pull .." ?

>>1070498
Можно.

>>1070545
Поподробнее пожалуйста.

>>1070498
И да и нет.
По факту ты создашь новые коммиты на основе старых (а старые можно будет достать пока GC их не соберет).
Провернут объединение коммитов/схлопывание (squash) и удаление - все это можно сделать интерактивным ребейзом (git rebase -i). Еще можно ручками поиграться с reset --mixed и cherry-pick
>>1070506
А ты не pull делай, а fetch

>>1070710
> По факту

По факту твоя мать хуй сосет же.

>>1070886
уроки поделал?

>>1070710
сделал fetch вместо pull.
Никакой разницы.

>>1070710
git log -1 помог

Задали в качестве домашки изучить в том числе stash. И если понимание остального можно показать удалённо комитами, то здесь непонятно. Ведь stash - это только локально на компе. Или можно придумать такой кейс, чтобы показать, что я поюзал заначку?

>>1071839
Начал работать в неправильной ветке, опомнился когда нахуярил 2000 строк говнокода. git stash, git checkout my-branch, git stash pop.

>>1059652
Кстати, в чем преимущество hg перед git и наоборот?

>>1053395
Все верно, у меня на мелких проектах в сотню строк только мастер и все.

>>1078640
Название короче на одну буквы. Других преимуществ нет, одни недостатки.

Ананас, а ты свою СКВ используешь ещё как-нибудь по мимо слежения за кодом?
Я имею ввиду ведение каких-либо заметок или ещё какое-либо версионирование файлов?

>>1035893 (OP)
Мамонт репортинг ин.
Пользуюсь контролем версий типа копирование папки + винрар. Еще ни разу не подвела. Когда начинаю новый "бранч", переименовываю старую папку с проектом в ~проект ну или ~~проект если уже занято, ~~~проект и так далее. Этакий стэк получается. Удаляю в корзину, соответственно даже если проебался, всегда можно восстановить. Надо только текущую папку переименовать в _~проект.
Каждый день папку архивирую с помощью winrar. Архив автоматом помечается текущим временем и датой, опционально название платформы, там win_ или lin_. Еще можно суффикс с названием фичи, например _joystickInput.
Пробовал эти ваши гиты. Настроили репу, кидали туда только коммиты/пуши, без изъебств с тэгами/бранчами/ребейзами. Через десяток коммитов гит сломался, с супер полезным сообщеним fatal: unable to read 0234mutherfuckinghash. Админ чето то там побегал, погуглил, какие то адовы детективы с бинарным поиском по дереву пропавшего блоба и подсовыванием ему пустышки. Наверное, это нормально для опенсорса, УНВР (у них все работает). Я же с усмешкой разархивировал нужную папку с проектом и продолжил работу.

>>1087958
>винрар
Тут ты и спалился, Рошаль. Уябывай со своим говном отсюда.

>>1087961
Работает - не трогай. 7zip уродлив как твоя мамаша, а так бы перекатился.

>>1087918

Заметки, совсем крохотные куски хода храню в scratches, ибо нечаво пихать всякое в VCS.

>>1087918
Не использую, а надо. Пихал заметки, тексты и ноты в гит, но постоянно забывал коммитить и забил.

Главная ценность гита - это возможность откатится назад всегда, что бы не произошло. И не будет такого "ой сука случайно удалил" и пиздец. Это при работе одному. Если работают двое-трое то гит уже точно нужен чтобы видеть чей код в проекте кто и когда его туда поместил, чтобы взъебывать за косяки тиммейтов/себя

>>1088030
В схеме с копиями папок/архивов по датам точно так же всегда можно откатиться. И в гите можно случайно удалить. Хуже того, оно может сломаться само и хуй ты его починишь.
Про менеджерские приколы про "взъебывать за косяки" оставлю без комментариев. Взрослые люди исправляют ошибки без пафоса, а не носятся по офису в попытках кого то обвинять.

>>1088036
Вот хуй знает какие у вас проблемы. У нас гитлаб стоит, уже год как работаю тут ничего не ломалось. Дело не в менеджерских приколах, иногда серьезно нужно просматривать код новичков, прежде чем применять их изменения на продакшен. тот же гитлаб например позволяет тебе легко посмотреть разницу между кодом проекта и тем который выкатил программист, не нужно выбирать руками нужные файлики и крутить их до новой строки.

>>1088030
Ну так-то в гите легко случайно затереть рабочую директорию. Алсо, черрипики ебаные бесят суки взять переключиться дрочить гит стопицот команд ебаных

>>1088075
Инструмент для код ревью - это функция редактора с поддержкой diff, такое умеют саблим, vscode, причем тут гит?

>>1053165
Да нет особой разницы, но ртуть чуточку лучше.

Ртуть более логична в коммандах, их тупо меньше и работают он без подводных камней. У ртути есть настоящие ветки, а не богомерзкие поинтеры на голову(в ней аж четыре способа ветвления на все случаи хипстерской жизни, лол). Еще ртуть действительно хранит всю историю изменений и при мердже веток всегда можно узнать откуда конкретно взялся вот этот кусок кода.

>>1053165
У hg есть нормальный гуй под линукс. Есть нормальные подремонтировать (модули)

>>1036297
> working area, stage area
Не знаю точно, но догадываюсь, что это. Прекрасно пользуюсь гитом 5 лет

>>1036449
> наркоман, гитапараша как раз для этих целей и не удобна
Чем это неудобна? Годами пилю проекты в одиночку и никаких проблем не заметил.

>>1038068
Вообще странно, зачем нужен свич m. Сделали бы просто git commit "bla bla bla"

>>1088172
Двачую. Жаль, что гит стал более хайпанутым только потому, что его написал Линус

>>1088219
>что его написал Линус
да всем на этого пингвина похуй, раскрутили это говно для поднятия бабок. лохам же можно и книги и курсы впаривать, и овер 100500 команд

>>1088223
Вангую переусложнение создано на ровном месте, как и всякие NodeJs и прочая хипстота.

>>1088307
>создано на ровном месте
типа того, это как с телефонами, впрочем как и весь маркетинг. пингвин запилил хуету на все случаи жизни, причем ее архитектуру допиливал по ходу пъесы и это только начало.

>>1094075
А все, сделал первый коммит и все нормально.

Подписался на тред. Юзаю консоль и только консоль. С хуками omz ничего больше и не надо, особенно с божественными командами gwip и gunwip.

>>1035893 (OP)
Как мне переименовать авторов всех коммитов в локальном репозитории?

>>1094492
А оно точно ничего другого не поломает?

>>1094535
Скопируй репу целиком и попробуй же.
Как минимум, ты перезаписываешь историю. Это значит, что у всех остальных всё поломается. Или же они должны подтянуть всё со стратегией "похуй на всё".

>>1094678
Так я не пушил еще, потому перед пушем и хочу переписать.

Спасибо за ответ.

Бамп хорошему треду.

>>1039888
>Как обезопасить себя от бекдоров, слива инфы и прочего недобросовестного отношения программиста-фрилансера?
Бля, не нанимать долбоебов, вот как! Сразу берешь на работу нормальных людей, экспертов в своей области, пишущих красивый код. Они такой хуйней не занимаются. И даешь им полную свободу в выборе решений. Мне даже не нужны бекдоры, чтобы разъебать твой сайт. Достаточно будет одного нефильтрованного поля для SQL-инъекции, чтобы похерить всю базу данных или залить те вирюсню на сайт. Многие безалаберные кодеры оставляют после себя ТЫСЯЧИ уязвимостей и любой мало-мальски грамотный хакер положит сайт в три секунды.

А насчёт "контролировать правки, вести журнал" и проч. - во-первых неэффективно, так как злонамеренный умысел будет сложно доказать (а чё я прост не знал что поле надо фильтровать!). А во-вторых, нормальный программист гиперконтроль не любит и съебуется тут же от таких, ибо не тебе его учить жизни. И твои "вот тут поменять кнопку" нахуй не нужны, ибо кого ты учишь? Он там может в 2000м получил корку веб-мастера, а ты втираешь ему какую-то дичь.

"Слив инфы" - тут без комментариев, обычный говносайт никому особо не нужен. Хороший, годный код нужен. Сорцы фейсбука, твитора нужны. А сорцы сайта какого-нибудь СтройИзбаПромТеха даром никому не нужен.

веб-фрилансер

>>1035893 (OP)
А можно заставить гит не записывать время коммита? Я сейчас подумал - что-то слишком дохуя инфы же. Можно по времени коммитов биоритмы вычислять, заказчики-начальники могут увидеть, почему я срок проебал\сонный весь день ходил, можно даже отслеживать передвижения, если таймзоны меняются. Паранойя. Зачем ему вообще время?

>>1100580
Может тогда настроить автоматические коммиты?

>>1100580
>Можно по времени коммитов биоритмы вычислять

Ты еще скажи: написать нейронку по токсичности комментариев определяющую критические дни у разработчик. Правда с монетизацией могут быть проблемы - фидбеком в виде простой благодарности от мужиков сыт не будешь, увы.

не страдай фигней

>>1100640
>разработчик

разработчиц*

>>1035929
Из всего списка не пользуюсь только rebase и cherry-pick. Может кто-нибудь из адекватных в треде объяснит просто зачем они нужны? Первый насколько я прочитал для того чтобы типа была читаемая история коммитов, но можно проебаться и при ребейзе в ремот люди потеряют часть своего кода. Везде советую т просто мерджить ветви крч. Просто жизненные ситуации, где мне может пригодиться ребейз?

>>1100663
Вообще говоря, тебе лучше гайдов на тему поискать. Но я могу попробовать объяснить.
Работаешь ты такой на ветке, где ещё много людей тусит (master). Запилил такую фиговину мелкую, пушишь на remote, а там кто-то уже в master коммит сделал. Можно remote-ветку вмержить в локальную, запушить ещё раз. Вместо этого можно rebase сделать, тогда локальная ветка будет выглядеть так, будто ты свои коммиты уже после коммитов того чувачка сделал. Такую ветку уже можно запушить.

Ну cherry-pick полезен бывает полезен, если ты пофиксил что-нибудь на одной ветке и при этом понадобилось этот же фикс в другую перенести. Или перенести фикс с одного удалённого репозитория на другой.

>>1100663
1) Rebase.
Ситуация 1. Тебе не нужно ебучее ветвление в git log'е, и не нужны мерж коммиты. git merge --ff (фастфовад) не всегда это может полечить, насчёт git merge --squash — честно, не знаю. Поэтому если ты слишком рано отошёл со своей фича-веткой от дева\мастера, начал работу и даже накоммитил, и в мастер что-то впихнули — рибейзишь себе дев\мастер.
Подвид этой ситуации — при git pull, который есть git fetch origin (допустим) + git merge origin (допустим) ты тоже не хочешь мерж коммит. Делаешь всегда git pull --rebase.
Ситуация 2. Ты мержишь к себе ветку и охуеваешь от количества конфликтов, не понимаешь, откуда они взялись. Чтобы разобраться в этом, ты можешь абортнуть мерж и сделать рибейз. Гит поэтапно будет коммит за коммитом показывать, где образовывались конфликты. Править их в итоге удобней, пожалуй, после мержа, но рибейз поможет разобраться.
1.1) Interactive Rebase. Вообще божественная команда, попробуй ещё захочешь. Допустим, ты сделал два коммита, и понял что их можно слить в один. Вызываешь git rebase -i head~3 (head~3 – основание, откуда идёт операция интерактивного рибейза). Коммиты отобразятся в немного необычном порядке, можешь открыть второе окошко терминала и сравнить с git log. И ты можешь влить самый молодой коммит в коммит постарше, написав f (fixup) или s (squash) напротив молодого. Всегда вливай молодой коммит в старый, не наоборот.

Или же ещё ситуация с интерактивным рибейзом. Допустим, ты работаешь в фича-ветке, отправил код на ревью и продолжаешь в ней же работать. Сделал коммит раз, работаешь дальше. Сделал коммит два. Вдруг посоны присылают замечание. Фиксишь его, коммитишь, хочешь запушить в ремоут это исправление. Но вот незадача, git push пушит ветку целиком. Тогда ты вызываешь git rebase -i head~4 (сбился со счёта, но идея должна быть понятна) и перемещаешь этот последний коммит (просто перетаскиваешь строчку) следующим за последний коммитом, который уже лежит в ремоуте. Подтверждаешь рибейз и делаешь git push origin <хэш фикса>:feature/hunta. Всё! Нужный коммит с фиксом запушен, остальные два лежат локально.

2) cherry-pick
Ты узнал, что коллега васян в своём форке сделал доработку, которая облегчит тебе жизнь, и даже о чудо оформил её в отдельный коммит. Добавляешь ремоут git remote add vasyan <URL репы>, git fetch --all, git log vasyan/feature/hunta, и далее git cherry-pick (хэш коммита с фиксом). Всё! Ты забрал себе только нужный коммит.

Ах да, интересная инфа. "deleted by us/them" допустим. Имеют разные значения для мержа и рибейза.

>>1100688
Вот, товарищ дело пояснил.
>>1100696
>head~4
Вместо такого изъёбства разумеется можешь просто писать хэш последнего коммита, который будет базой для рибейза.

>>1100696
ебать вы там наркоманы поехавшие. всегда знал, что гит для пидоров

>>1100696
Спасибо, вроде немного понял. Но нужно поэксперементировать одному прежде чем в офисе выебываться. У нас используют только слияние ветвей. Если кто-то сделал пуш в рабочую ветку до тебя соответственно делается git pull, на локале появляются изменения с удаленного репозитория, правятся конфликты если такие есть и потом делается коммит и пуш ветки. Постараюсь разобрать интерактивный ребейз.
>>1100688
Тебе тоже спасибо. cherry-pick позволяет грубо говоря забрать кусок кода который оформлен отдельным коммитом с одной ветки на другую, будь то удаленная ветвь какого-нибудь васяна уже на ориджине, или твоя локальная я правильно понял? Если так - полезная вещь.
>>1100702
Все еще хранишь код по папочкам с датами? Или по FTPшке выкачиваете с пацанами весь проект каждый раз перед тем как залить обратно. У меня есть пару проектов без гита на работе. Ммм это бесценное чуство, когда ты не знаешь актуальна ли твоя копия на локале или нет, а качать лень поэтому ты просто перекрестившись аплоадишь файлы с автозаменой.

>>1100722
>Все еще хранишь код по папочкам с датами
использую fossil и его 2.5 команды,

>>1100696
наркомания.

>>1100722
> Если кто-то сделал пуш в рабочую ветку до тебя соответственно делается git pull, на локале появляются изменения с удаленного репозитория, правятся конфликты если такие есть и потом делается коммит и пуш ветки
Вот как раз если ты сделал коммит и само собой не пушил — в этой ситуации поможет git pull --rebase. Если нет конфликтов — то всё он сам разрулит. Если есть — разрулишь их, и ёбаного мерж коммит месседжа не будет.
> будь то удаленная ветвь какого-нибудь васяна уже на ориджине, или твоя локальная я правильно понял?
Именно. Нужно будет только добавить и сфетчить ремоут ветку. После черрипика её можно удалить, git remote remove vasyan

>>1100748
git yoba -zdrloy -krasivo -popacansci

>>1100748
>Вот как раз если ты сделал коммит и само собой не пушил — в этой ситуации поможет git pull --rebase. Если нет конфликтов — то всё он сам разрулит. Если есть — разрулишь их, и ёбаного мерж коммит месседжа не будет.
Жизненно, обязательно попробую завтра и посмотрю что будет на графе.

>>1100756
Обязательно! Вообще это всё круто пробовать, если просто не сцать и в моменты когда в чём-то сомневаешься делать копию локальной ветки, просто git branch xyi.
Если ты даже как-то проебёшь локальную ветку (в ходе любой операции), то сможешь переключиться на копию и поставить её глядеть на ремоут, git branch --set-upstream-to xyi origin/foo. Тогда она локально будет xyi, а удалённо останется для всех origin/foo.
Ещё есть спасательная (ни дай Торвальдс, чтобы она пригодилась) команда git reflog... Просто выводит всю историю, с ней можно делать что угодно — смотреть, эпплаить, черрипикать, изготавливать из неё патчи и т.д.
Самое хуёвое, что можно сделать — это зачекаутить обратно файл(ы), в который ты уже вносил изменения, и ты их никогда не стэшил а они тебе вдруг нужны — например, git checkout -- file.sh или git checkout . (точка или -A). Тогда даже рефлог бессилен.

>>1100637
Не понял, как, зачем что ета вообще? Я хочу иметь обычный воркфлоу, просто не хочу, чтобы у коммитов было время. Например, пусть они все будут записываться со временем 00:00. Я так понимаю, можно через фильер-бранч это переписывать пост-фактум, но может есть какой-то более простой способ?

>>1100640
Да, иди нахуй.

>>1100696
> Ситуация 1.
Нахуя? Все просто пуллят-мерджат, в чем проблема вообще, что это решает?

> не хочешь мерж коммит
Тебя в детстве мерж коммиты покусали? Что в этом плохого, нахуя?

Решительно не понимат. У тебя просто фетиш какой-то или это реально для чего-то нужно?

>>1100696
>Ситуация 2.
>Править их в итоге удобней, пожалуй, после мержа, но рибейз поможет разобраться.
Ну то есть сам по себе рибейз все равно получается ненужен?

> 1.1) Interactive Rebase
Для этого же есть commit --amend, не?

> отправил код на ревью и продолжаешь в ней же работать
Это же неправильно. Зачем так делать?

> ты вызываешь git rebase -i head~4 (сбился со счёта
Это же наркомания какая-то, нет? Зачем эти хаки нужны? Ты делаешь пулл реквест - ребята его смотрят - отправляют тебе обратно. Ты переключаешься туда, фиксишь, делаешь пулл реквест, все повторяется. Ветки для этого и были придуманы.

Зачем эта наркомания с перестановкой коммитов в ветке? Это же как срать, не снимая свитер, не?

>>1100748
>ёбаного мерж коммит месседжа не будет
ДА ХУЛЬ ТЫ ПРИЕБАЛСЯ К МЕРЖ КОММИТАМ?! ГИТ ТАК РАБОТАЕТ, ХУЛИ ТЕБЕ В НИХ НЕ НРАВИТСЯ, ААААААА

>>1100764
>Самое хуёвое, что можно сделать — это зачекаутить обратно файл(ы)
Обжигался на этом, кстати. До сих пор не понимаю, почему оно не загорается красным, не начинает пиликать и кричать во весь голос "ТОБI ПIЗДА" перед тем, как перезаписывать локальные файлы.

>>1100817
>Тебя в детстве мерж коммиты покусали? Что в этом плохого, нахуя?
Вот я хуй знает. Тоже первый раз удивился когда от моего имени на гитлабе появилось тонна кода которого я не писал.

>>1100817
>Нахуя? Все просто пуллят-мерджат, в чем проблема вообще, что это решает?
Ты работаешь в репе с кем-то ещё. почему так получилось — оставим за скобками. Ты сделал коммит. И кто-то запушил в эту ветку. Что произойдёт при попытке пуша? Ошибка. Твой выход — либо резетнуть голова~ и застэшить получившееся, затем накатить мерж (он накатит автоматически фастфовадом), заэпплаить\попнуть стэш, закоммитить заново. Либо же сразу мержить. У тебя в итоге получится два коммита, и мерж коммит. На графе это будет выглядеть как отсоединившаяся и сразу заехавшая обратно ниточка.
А ещё ты можешь закоммитить и сделать git pull --rebase. Тогда у тебя не будет "ниточек" и лишних коммит месседжей, если будут конфликты — он сам всё разрулит.
>Тебя в детстве мерж коммиты покусали? Что в этом плохого, нахуя?
Это засоряет лог работы. А если ты смотришь это в режиме графа, git log --graph – то это более того, может создавать неверное представление о запиливании фичи. Ты можешь отбранчеваться от дева\мастера и пилить фичу, в то время как в дев\мастер что-то подливают. И у тебя будет длиннющее "метро" из-за твоей фичи, которое прервётся со вмерживанием твоей ветки в дев\мастер. Если ты будешь подливать себе мержем дев — "метро" ещё будет наезжать друг на друга. Если же ты будешь подливать себе дев рибейзом, по возможности, т.е. если нет конфликтов (об этом далее) — то ниточка создаст верное представление, чем же твоя фича отлиается от дева\мастера.
>>1100820
>Ну то есть сам по себе рибейз все равно получается ненужен?
Если мы говорим о разрешении конфликтов в сильно отставшей ветке — то в итоге ИМХО легче это дело всегда разрешить мержем. Но если у тебя всё настолько разъехалось и пусть ты даже эксперт в кодовой базе и в курсе всех фич, но всё равно не можешь понять, каким образом всё так разъехалось — рибейз тебе поэтапно "расскажет" о конфликтах.
>Для этого же есть commit --amend, не?
Он позволяет удобно переставлять местами коммиты? Объединять их, сливать в один, сразу выбрать несколько и менять их в один присест? А в интерактивном рибейзе это очень наглядно.
>Это же неправильно. Зачем так делать?
Допустим, я вотерфолльно пилю фичу, которую до последнего не буду вливать в дев, чтобы собирали регрессили всё сразу. Я запушил и закинул пуллреквест (из своего форка, или из ориджина, пофиг) с кусочком работы. И хочу продолжать далее с кодом, который только что запушил. Получается, по-твоему я должен разделить ветки на feature/sub_feature_first, закинуть её на пуллреквест, отбранчеваться от неё, пока идёт ревью, в ветку feature/sub_feature_second, и далее работать в ней? Можно конечно. Только тогда в случае правок в первой ветке мне нужно будет её рибейзить во вторую. Нет, можно, конечно, застэшить изменения и отбранчеваться во второй раз в feature/sub_feature_2_1, или же надёргать черрипиками — но что-то такое… А так берёшь и работаешь в той же ветке. Есть замечания и даже если ты уже накоммитил — правишь замечания, интерактивным рибейзом переносишь их ниже, сразу за уже запушенным коммитом, и пушишь только этот коммит с правками по замечаниям. Работаешь дальше(с).
>Ты переключаешься туда
А я не хочу переключаться. Я продолжают работать над этой фичей, просто делаю пуллреквесты размером поменьше.
>Зачем эта наркомания с перестановкой коммитов в ветке? Это же как срать, не снимая свитер, не?
Почему? Если речь идёт о коммите с правкой по замечаниям — то он логически относится к той части работы, которая располагается к историей ниже. Кроме того, чтобы не засорять историю коммитов коммитами-правками — то если НИКТО не работает больше в этой ремоут-ветке — ты имеешь полное право не только передвинуть такой коммит вниз, но и объединить его с последним запушенным в репу коммитом, и запушить его с форсом (только его!).

>>1101220
>почему так получилось — оставим за скобками
Так а я тебе еще раз скажу, что если у тебя "так получилось", то ты изначально все делал неправильно. Ну то есть получается, что сам создал проблему - сам ее решил. То есть таки ненужно. Я не спорю, бывают какие-то исключительные ситуации, но в таких случаях всегда можно погуглить. То есть в повседневной работе ребейз НЕНУЖЕН?

> Это засоряет лог работы.
Но по идее в логе же как раз нужно видеть те моменты, когда ты подлил себе изменения из мастера, разве нет? Если у тебя какая-то долгоиграющая ветка (хотя долгоиграющих веток по идее не должно быть у тебя, они должны быть на римоуте), то чтобы видеть реальную историю изменений, все подливания в нее мастера должны быть видны, не? А если у тебя не долгоиграющая ветка, а тебе просто нужно утащить хотфикс из мастера, то ты его черрипикаешь, об этом ты и сам писал.

>>commit --amend, не?
> Объединять их, сливать в один, сразу выбрать несколько и менять их в один присест?
Ну это же опять какая-то наркомания. Как будто заняться мне больше нечем, кроме как коммиты переставлять, э? Типичный сценарий: ты сделал коммит, работаешь дальше, готовишься делать следующий коммит и тут осознаешь, что облажался с прошлым коммитом и чего-то недокоммитил. Делаешь аменд, потом делаешь новый коммит, все. А переставлять коммиты нахуя надо, а?

> Получается, по-твоему я должен разделить ветки на feature/sub_feature_first, закинуть её на пуллреквест, отбранчеваться от неё, пока идёт ревью, в ветку feature/sub_feature_second, и далее работать в ней?
Ну да, блядь, гит же для такого воркфлоу и задуман, ветки именно так и работают, не? Плюс повторюсь, если у тебя какая-то долгая фича, то она не должна быть в локальной ветке.

> Только тогда в случае правок в первой ветке мне нужно будет её рибейзить во вторую.
Не понял, зачем? Если твой пулл реквест отфутболили, то ты переключаешься обратно, фиксишь, отправляешь. Если там еще какие-то изменения залили, делаешь пулл-мердж и т.д. Ну блин, все как и с мастером.

> А я не хочу переключаться.
Ну я ж говорю, получается, что выдумываете себе проблемы на ровном месте, просто потому что НИХАЧУ. Не понимат.

>>1101306
>ты изначально всё делал неправильно
Будто на репе один человек работает.

Я не вчитывался особо, но такое ощущение, что вы подвержены каким-то мантрам и сторонним мнениям. Git - это в первую очередь инструмент, решающий проблемы. Если есть способы и оба работают одинаково хорошо, то я выберу тот, который мне удобен или к которому я по-утиному привык. И уж точно не буду по приказу царя из-за бугра свой стиль работы менять и отсеивать альтернативы, потому что царь не хотел бы, чтобы так работали или царь сказал, что нинужна.

мимо