Здравствуйте, Lexey, Вы писали: L>А что нужно было делать тем, кто начал программировать, когда Git'а еще даже в планах не было? Все бросить, и ждать его появления?
Здравствуйте, Sinix, Вы писали:
S>- или периодически страдают все.
Точно. Я периодически страдаю от того, что нугеты не в репе. Забираешь последнее, а оно нифига не компилируется. Сидишь, тупишь пару минут, потом вспоминаешь, что некоторым скрягам жаль места на серверах гитхаба, материшься и начинаешь заниматься восстановлением. Иногда с приключениями. git виноват, фули
Если нам не помогут, то мы тоже никого не пощадим.
читал?
S>С своей стороны — использую только тортойз и только стандартные fetch&Rebase/Push с галочками по умолчанию
Поставь GitExtensions. Он хоть и слегка мрачноват, но обладает правильной организацией работы с гитом. Все остальные подходы, включая интергацию в студии и тот же тортойз до правильного подхода работы с кодом ещё не доросли.
Ещё несколько советов для начинающих:
— Скачайте, поставте и синтегрируйте с GitExtensions P4Merge. Это лучший в мире 3-way merge tool. Простой интерфейс. Умный merge, зачастую без напряга домёрдживает то, что не смог git.
— Для того, чтобы не путаться что куда мёрджится, запомнить одну простую вещь — ВСЕГДА изменяется только текущий бранч. Т.е. чтобы смёржить, черепикнуть, ребейзнуть что-либо и сложить эти изменения там где нужно, это где нужно нужно сделать текущим бранчем. Со временем это становится и так ясно, но новички часто путаются. Это правило позволяет быстро разрулить путаницу.
— Работая с git думайте о коде как о дереве комитов, дереве версий вашего кода, а не о дереве каталогов. Именно этот подход изначально реализуется в GitExtensions. Это вскоре позволит понять идеологию easy branching и научиться жонглировать комитами как угодно. Т.е. представьте, что перед вами дерево версий вашего кода и вы имеете быстрый доступ к любой из них. У этого есть один недостаток — после этого работа с другими типами VCS становится решительно удручающей.
— Если сложно сразу смёржить два комита, то попробуйте мёржить сначала промежуточные комиты. Иногда это позволяет обойтись без ручного мёрджа вообще.
— Делайте частые комиты. Легче будет мёрджить и вам и остальным. Здесь главное правило — код безусловно должен оставаться компилируемым и желательно рабочим в частях, которые не затрагиваются комитом. В git есть такая волшебная фича как bisec. Она отлично работает только если комиты мелкие, компилируемые и рабочие. Под рабочестью понимается рабочие юнит тесты. Если в вашем комите есть ваш временно не рабочий тест, то заигнорьте его, пока он не станет рабочим.
— Поставьте расширялки для студии
Git Diff Margin — позволяет видеть текущие участки изменения в коде, просматривать предыдущую версию и легко откатывать при необходимости выбранные участки прямо в редакторе.
GitExtensions — лёгкая интерграция с GitExtensions.
— У git очень много возможностей. Пока не парьтесь. Для начала вам нужно знать что такое Pull, Push, Fetch, Rebase, Merge и понимать что такое двух стадийный комит. Всё остальное придёт с опытом.
— Уверенно забейте на командную строку git и пользуйтесь интегрированными штучками или приложенями типа GitExtensions. Чай не 2005-й год.
Если ещё что-нибудь вспомню допишу.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Точно. Я периодически страдаю от того, что нугеты не в репе.
???
Свежая студия ж автоматом делает restore для отсутствующих пакетов.
IT>- Уверенно забейте на командную строку git и пользуйтесь интегрированными штучками или приложенями типа GitExtensions. Чай не 2005-й год.
Здравствуйте, Sinix, Вы писали:
S>Всё остальное — ок, но вот это не работает. Всё равно рано или поздно приходится лезть в консоль и чинить последствия "гуй страшен? Да вы на сам git посмотрите!!!"
И этого я тоже никогда не видел Хотя припоминаю, что был период, когда GitExtensions почти не развивался. Но это было 3-4 года назад.
S>Их бывает по несколько лет не чинят. Нафиг нужен инструмент, который даже правильно консольную команду выбрать не может?
Как вы это всё находите? Единственный баг, который довелось наблюдать — это в какой-то из версий не отображалось меню 'GitHub'. И всё
Видимо GitExtensions каким-то образом умеет отвечать на ненависть ненавистью, а на любовь любовью.
Из всех гитовский гуёв, которые доводилось использовать, а это ещё 4-5 штук, этот самый адекватный.
Что касается TortoiseGit, то более бестолковой идеи, чем копировать интерфейс старых CVS трудно придумать. Убогий интерфейс, дерево комитов запрятали фиг знает куда, сходу и не найдёшь. Тупая калька с TortoiseSvn. Не удивительно, что пользователи TortoiseGit постоянно косячат с репозиторием. Это уже можно воспринимать как индикатор — раз чел косячит, значит либо TortoiseGit, либо TFS, дерево комитов никогда не видел и понятия не имеет что это такое.
Если полное отторжение GitExtensions, то можно ещё попробовать любимый интерфейс AVK от Atlassian — SourceTree. Хотя вещь и довольно громоздкая и аляпистая, но как минимум обладает правильным подходом.
Если нам не помогут, то мы тоже никого не пощадим.
S>>Ну и в git extensions всё хорошо, кроме багов типа вот этих IT>И этого я тоже никогда не видел Хотя припоминаю, что был период, когда GitExtensions почти не развивался. Но это было 3-4 года назад.
Примерно тогда я его активно и щупал. Надо для разнообразия второй шанс дать.
S>>Их бывает по несколько лет не чинят. Нафиг нужен инструмент, который даже правильно консольную команду выбрать не может? IT>Как вы это всё находите? Единственный баг, который довелось наблюдать — это в какой-то из версий не отображалось меню 'GitHub'. И всё IT>Видимо GitExtensions каким-то образом умеет отвечать на ненависть ненавистью, а на любовь любовью.
Везёт мне так
Если серьёзно, то про ненависть речь не идёт, скорее недоумение: чисто вспомогательная штука, которая требует осторожности на порядок больше, чем основной инструмент — это ж фейл полный
IT>Что касается TortoiseGit, то более бестолковой идеи, чем копировать интерфейс старых CVS трудно придумать.
Он идеально попадает в целевую аудиторию. Ну, когда команда — это не 5 гиков, а ещё и биз-аналитики, QA и прочие творческие личности.
Вот им ничего кроме двух кнопок "забрал изменения" + "отправил своё" лучше не выдавать. Репо целее будет
Нет другого толкового клиента, который ещё и прощает ошибки типа "промахнулся мимо пункта меню" или "тыкнул не туда" — все потенциально деструктивные действия спрашиваются и иногда переспрашиваются.
А заводить какой-то другой клиент под себя... можно, но тогда появляется другая проблема: не получается помочь, когда человек всё-таки накосячит, т.к. сам эти менюшки в первый раз видишь.
IT>Это уже можно воспринимать как индикатор — раз чел косячит, значит либо TortoiseGit, либо TFS, дерево комитов никогда не видел и понятия не имеет что это такое.
Вот за эту позицию все, кроме товарищей увлечённых разработчиков, гит дружно и не любят. Не священная корова, что ж оно внимания требует, как пульт АЭС?
Здравствуйте, Sinix, Вы писали:
S>Он идеально попадает в целевую аудиторию. Ну, когда команда — это не 5 гиков, а ещё и биз-аналитики, QA и прочие творческие личности. S>Вот им ничего кроме двух кнопок "забрал изменения" + "отправил своё" лучше не выдавать. Репо целее будет
Тогда SourceTree точно лучше. В отличие от тортилочного гита он много чего предварительно чекает и не дает сделать совсем уж глупости.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Если нам не помогут, то мы тоже никого не пощадим.
