Здравствуйте, adontz, Вы писали:
A>Ну у меня большие проекты Иногда надо дать права только на часть.
Это как? Ну, то есть, если это один проект, то получив часть репозитория программист даже не сможет собрать приложение, чтобы протестировать свои изменения.
Если это части, собираемые независимо, то наверное стоит подумать о разделении на подпроекты (submodules)
Здравствуйте, DemAS, Вы писали:
DAS>Здравствуйте, adontz, Вы писали:
A>>Ну у меня большие проекты Иногда надо дать права только на часть.
DAS> Это как? Ну, то есть, если это один проект, то получив часть репозитория программист даже не сможет собрать приложение, чтобы протестировать свои изменения. DAS> Если это части, собираемые независимо, то наверное стоит подумать о разделении на подпроекты (submodules)
Я даю права на запись на часть проекта. Права на чтение имеют все.
Здравствуйте, adontz, Вы писали:
A>Я даю права на запись на часть проекта. Права на чтение имеют все.
Если на запись, то может использовать технологию, которая используется на GitHub?
Разработчик делает fork проекта, коммитит в него, а потом делает pull request в твой репозиторий.
А ты уже просмотривая эти pull request'ы решаешь — принимать их или нет.
В общем то, я понимаю, что если ты обычно не просматриваешь все коммиты, то это может быть излишней нагрузкой на тебя.
Здравствуйте, adontz, Вы писали:
DAS>> Это как? Ну, то есть, если это один проект, то получив часть репозитория программист даже не сможет собрать приложение, чтобы протестировать свои изменения. DAS>> Если это части, собираемые независимо, то наверное стоит подумать о разделении на подпроекты (submodules) A>Я даю права на запись на часть проекта. Права на чтение имеют все.
В git делается с помощью commit hooks.
Здравствуйте, DemAS, Вы писали:
DAS>В общем то, я понимаю, что если ты обычно не просматриваешь все коммиты, то это может быть излишней нагрузкой на тебя.
У меня постмодерация, так что такая модель не подходит. В сущности всё достаточно просто. вот давай на примере. Есть трёхзвенка. Сервер, клиент, БД. Её пишут три программиста, каждый свою часть. Тот кто знает WPF, плавает в SQL. Тот кто знает SQL, не разбирается в WCF. Можно премодерировать изменения, но тогда нужен отдельный человек, который будет разбираться во всех трёх технологиях и с утра до вечера премодерировать. Этон е эффективно. Мне проще дать каждому права на запись только в его часть. Тогда в случае больших изменений, затрагивающих несколько слоёв они будут вынуждены общаться и согласовывать свои действия. Эффективность при этом существенно не падает.
Здравствуйте, AlexNek, Вы писали:
AN> Ээ.. у нас даже большая дискуссия была по этому поводу, прекратилась после первого неопознанного вылета
В Ява-мире есть maven repository. А у вас?
AN> Ну так когда сразу все коммиты, это равносильно svn коммит, в чем "качество" конфликтов будет отличаться?
Тем что у тебя не один огромный коммит, который делает всё, а много маленьких, легко обозримых.
AN> .>В другой ветке. Ещё можно историю как-то поредактировать, чтобы количество конфликтов уменьшить. AN> Это как? Обнаружили конфликт, прерываем, берем все в новую ветку?
Конфликт может возникнуть только при мерже. Берётся (в смысле fetch) всегда в отдельную ветку.
AN> — каталоги с пробелами или не ASCII символами гит не любит, хотя в Гит экстеншион показываются нормально.
Кодировка да, возможно проблемы с msys, может быть, но решаемо. А на счёт пробелов — что-то ты видимо не то делаешь, вроде всё ок.
AN> — обновления из svn ищутся быстрее черепахи.
А история, а мержи... всё быстрее.
AN> — визуал Гит от Гит экстеншион не захотел грузится в мою 2008 студию
Хвалёный .net.
AN> — ни в проводнике ни в Гит экстеншион нифига не видно состояний файла/папки (под контролем/модифицирован/не изменен)
А он разве должен отображать? Вроде tortoisegit такое делает, знаю.
AN> — без коммандной строки нмфига не сделать. Добавил пару файлов в подконтрольный гиту каталог, еле нашел их в сташе. при попытке добавить в репозиторий получаю ошибку AN>
AN> C:\msysgit\cmd\git.cmd stash apply Current working dir changes
AN> fatal: ambiguous argument 'Current': unknown revision or path not in the working tree.
AN> use '--' to separate paths from revisions
AN> Done
"C:\msysgit\cmd\git.cmd stash apply Current working dir changes" это коммандная строка такая? Ты разве знаешь что аргументы, содержащие пробелы, нужно заключать в кавычки?
Что-то я не понял что ты со stash делал такое... Ты случайно его со stage не попутал?
AN> После получаса брожения по менюшкам и поиску ответа в сети Current заменился на какую то странную комбинацию и что то вроде пошло, но файлы упрямо не появлялись в Гит экстеншион пока не сделал все по описанным командам. При этом с проводника вообще ничего не получалось хотя и есть команда добавить файлы.
AN> Так что пока отрицательных состояний больше чем положительных, но бум продолжать.
Learning curve у гита очень steep...
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Ээ.. у нас даже большая дискуссия была по этому поводу, прекратилась после первого неопознанного вылета .>В Ява-мире есть maven repository. А у вас?
Если бы еще знал что это
Пока только это нашел Byldan
AN>> Ну так когда сразу все коммиты, это равносильно svn коммит, в чем "качество" конфликтов будет отличаться? .>Тем что у тебя не один огромный коммит, который делает всё, а много маленьких, легко обозримых.
То есть для начала меняется стратегия работы? Коммитим после каждого пука.
AN>> .>В другой ветке. Ещё можно историю как-то поредактировать, чтобы количество конфликтов уменьшить. AN>> Это как? Обнаружили конфликт, прерываем, берем все в новую ветку? .>Конфликт может возникнуть только при мерже. Берётся (в смысле fetch) всегда в отдельную ветку.
А потом ветка мержится с моей локальной копией?
AN>> — каталоги с пробелами или не ASCII символами гит не любит, хотя в Гит экстеншион показываются нормально. .>Кодировка да, возможно проблемы с msys, может быть, но решаемо. А на счёт пробелов — что-то ты видимо не то делаешь, вроде всё ок.
Ну да, когда "" автоматом ставишь
Но если решаемо через несколько лет, то как говорится, нам не по пути
AN>> — обновления из svn ищутся быстрее черепахи. .>А история, а мержи... всё быстрее.
Остального пока не видел, но поиск новых файлов точно медленней. (в SVN вроде и не нужен)
AN>> — визуал Гит от Гит экстеншион не захотел грузится в мою 2008 студию .>Хвалёный .net.
Скорее хваленный Гит экстеншион
AN>> — ни в проводнике ни в Гит экстеншион нифига не видно состояний файла/папки (под контролем/модифицирован/не изменен) .>А он разве должен отображать?
Про должен не знаю, но как без этого работать пока не знаю. .>Вроде tortoisegit такое делает, знаю.
Было такое подозрение. Прийдется еще ждать AnkhGit. AN>> — без коммандной строки нмфига не сделать. Добавил пару файлов в подконтрольный гиту каталог, еле нашел их в сташе. при попытке добавить в репозиторий получаю ошибку AN>>
AN>> C:\msysgit\cmd\git.cmd stash apply Current working dir changes
AN>> fatal: ambiguous argument 'Current': unknown revision or path not in the working tree.
AN>> use '--' to separate paths from revisions
AN>> Done
.>"C:\msysgit\cmd\git.cmd stash apply Current working dir changes" это коммандная строка такая? Ты разве знаешь что аргументы, содержащие пробелы, нужно заключать в кавычки?
Это не моя команда, это прога все делает.
.>Что-то я не понял что ты со stash делал такое... Ты случайно его со stage не попутал?
А фиг его знает там какая то желтая иконка и первые три буквы вроде "sta". Там диалог открывается, где видны новые файлы, вверху комбобох который дает "Current", внизу от комбо бокса список файлов с большими плюсиками и внизу три кнопки. Справа текстовые файлы показывает.
AN>> После получаса брожения по менюшкам и поиску ответа в сети Current заменился на какую то странную комбинацию и что то вроде пошло, но файлы упрямо не появлялись в Гит экстеншион пока не сделал все по описанным командам. При этом с проводника вообще ничего не получалось хотя и есть команда добавить файлы.
AN>> Так что пока отрицательных состояний больше чем положительных, но бум продолжать. .>Learning curve у гита очень steep...
Тогда я выучил git. Git — это такой нелогичный набор утилит командной строки, в котором ежедневные операции выполняются последовательностью из двух–четырех команд. Первую неделю я тыкался в каждый угол, как слепой щенок. Я рисовал себе схему четырех хранилищ (working copy, staging area, local repo, remote repo), и подписывал стрелочками, какая команда и с какими опциями переносит информацию откуда куда. К концу этого периода адаптации я нащупал те заветные комбинации, которые мне нужны были в повседневной работе, и обрел некоторую смелость в перетасовке набора команд с листочка, заставляя их выдавать более-менее то, что мне нужно. Силу интерактивного коммита из коммандной строки, или, допустим, какие делать запросы, чтобы понять текущее состояние, я не освоил до сих пор. Порадовало, что репозиторий можно вертеть как угодно, пересвязывать что угодно с чем угодно, правда, магия для этого нужна соответствующая.
Здравствуйте, AlexNek, Вы писали:
AN> Если бы еще знал что это AN> Пока только это нашел Byldan
Главная фича — репозиторий бинарных артефактов.
AN> То есть для начала меняется стратегия работы? Коммитим после каждого пука.
Типа того.
AN> А потом ветка мержится с моей локальной копией?
Да.
AN> Ну да, когда "" автоматом ставишь
Например, Far Manager автоматом ставит. bash тоже.
AN> Но если решаемо через несколько лет, то как говорится, нам не по пути
Нет, уже вроде решаемо. Правда никогда не приходилось решать, не знаю точно.
AN> Остального пока не видел, но поиск новых файлов точно медленней. (в SVN вроде и не нужен)
Что значит "поиск новых файлов"? git status показывает всё.
AN> Скорее хваленный Гит экстеншион
Хз, ни разу не пользовался. Я в мире java живу.
AN> .>А он разве должен отображать? AN> Про должен не знаю, но как без этого работать пока не знаю.
Это по идее должен делать софт, который ставит расширения в Проводнике. svn же тоже просто так ничего не показывает.
AN> Было такое подозрение. Прийдется еще ждать AnkhGit.
А чем tortoisegit не устраивает?
AN> Это не моя команда, это прога все делает.
Мда.. хз, непонятно.
AN> .>Что-то я не понял что ты со stash делал такое... Ты случайно его со stage не попутал?
AN> А фиг его знает там какая то желтая иконка и первые три буквы вроде "sta". Там диалог открывается, где видны новые файлы, вверху комбобох который дает "Current", внизу от комбо бокса список файлов с большими плюсиками и внизу три кнопки. Справа текстовые файлы показывает.
Брр... вот за это не люблю gui в данном случае — ничего без скриншотов непонятно.
AN>
AN> Тогда я выучил git. Git — это такой нелогичный набор утилит командной строки, в котором ежедневные операции выполняются последовательностью из двух–четырех команд. Первую неделю я тыкался в каждый угол, как слепой щенок. Я рисовал себе схему четырех хранилищ (working copy, staging area, local repo, remote repo), и подписывал стрелочками, какая команда и с какими опциями переносит информацию откуда куда. К концу этого периода адаптации я нащупал те заветные комбинации, которые мне нужны были в повседневной работе, и обрел некоторую смелость в перетасовке набора команд с листочка, заставляя их выдавать более-менее то, что мне нужно. Силу интерактивного коммита из коммандной строки, или, допустим, какие делать запросы, чтобы понять текущее состояние, я не освоил до сих пор. Порадовало, что репозиторий можно вертеть как угодно, пересвязывать что угодно с чем угодно, правда, магия для этого нужна соответствующая.
AN> Пугает
staging area — всё просто. Представь себе svn, диалог коммита. Ты там галочками отмечаешь что хочешь закоммитить. Так вот staging area это замена этому диалогу, с учётом того, что ты эти галочки можешь отмечать через командную строку (git add) и оно не теряется при закрытии/обновлении диалога. И ещё ты можешь отметить для коммита не весь файл целиком, а только некоторые ломтики (hunks).
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Если бы еще знал что это AN>> Пока только это нашел Byldan .>Главная фича — репозиторий бинарных артефактов.
То есть не может быть бинарников "несовместимых" с исходниками?
AN>> А потом ветка мержится с моей локальной копией? .>Да.
Пожалуй пора искать алгоритм пользования гитом
AN>> Ну да, когда "" автоматом ставишь .>Например, Far Manager автоматом ставит. bash тоже.
Я в окно Баша даже ничего вставить из клипбоарда не могу, призодится все пути руками вводить
AN>> Но если решаемо через несколько лет, то как говорится, нам не по пути .>Нет, уже вроде решаемо. Правда никогда не приходилось решать, не знаю точно.
Ну если понравится поищу, а то SVN репозиторий никто не будет менять.
AN>> Остального пока не видел, но поиск новых файлов точно медленней. (в SVN вроде и не нужен) .>Что значит "поиск новых файлов"? git status показывает всё.
Как я теперь понял это окно stag-ей, после каждой операции оно перечитывается.
AN>> Скорее хваленный Гит экстеншион .>Хз, ни разу не пользовался. Я в мире java живу.
А я в НЕТе — прювет
AN>> .>А он разве должен отображать? AN>> Про должен не знаю, но как без этого работать пока не знаю. .>Это по идее должен делать софт, который ставит расширения в Проводнике. svn же тоже просто так ничего не показывает.
Ну так данный софт и хочется.
А что в яве разве не нужно знать что под контролем версий, а что еще нет
AN>> Было такое подозрение. Прийдется еще ждать AnkhGit. .>А чем tortoisegit не устраивает?
Он для студии не должен годится, по идее. (В смысле провайдера контроля версий)
AN>> Это не моя команда, это прога все делает. .>Мда.. хз, непонятно.
Я открываю окно stag-ей, там список файлов которые я добавил проводником, потом жму кнопу добавить в рабочую область (или что то подопбное) и потом приведенная ошибка и вылазит.
AN>> .>Что-то я не понял что ты со stash делал такое... Ты случайно его со stage не попутал?
AN>> А фиг его знает там какая то желтая иконка и первые три буквы вроде "sta". Там диалог открывается, где видны новые файлы, вверху комбобох который дает "Current", внизу от комбо бокса список файлов с большими плюсиками и внизу три кнопки. Справа текстовые файлы показывает. .>Брр... вот за это не люблю gui в данном случае — ничего без скриншотов непонятно.
Скрины можно сделать только на работе, но с работы я не хожу на форум. Придется обходным путем идти...
AN>>
AN>> Тогда я выучил git. Git — это такой нелогичный набор утилит командной строки, в котором ежедневные операции выполняются последовательностью из двух–четырех команд. Первую неделю я тыкался в каждый угол, как слепой щенок. Я рисовал себе схему четырех хранилищ (working copy, staging area, local repo, remote repo), и подписывал стрелочками, какая команда и с какими опциями переносит информацию откуда куда. К концу этого периода адаптации я нащупал те заветные комбинации, которые мне нужны были в повседневной работе, и обрел некоторую смелость в перетасовке набора команд с листочка, заставляя их выдавать более-менее то, что мне нужно. Силу интерактивного коммита из коммандной строки, или, допустим, какие делать запросы, чтобы понять текущее состояние, я не освоил до сих пор. Порадовало, что репозиторий можно вертеть как угодно, пересвязывать что угодно с чем угодно, правда, магия для этого нужна соответствующая.
AN>> Пугает .>staging area — всё просто. Представь себе svn, диалог коммита. Ты там галочками отмечаешь что хочешь закоммитить. Так вот staging area это замена этому диалогу, с учётом того, что ты эти галочки можешь отмечать через командную строку (git add) и оно не теряется при закрытии/обновлении диалога. И ещё ты можешь отметить для коммита не весь файл целиком, а только некоторые ломтики (hunks)
Тое это как бы виртуальный репозиторий которого просто не существует физически?
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, IT, Вы писали:
IT>>Здравствуйте, AlexNek, Вы писали:
IT>>>>У GitExtensions тоже есть. Вполне достаточная для работы с ним. AN>>>А картинки к интеграции есть? Что -то в статье не заметил.
Сорри, случайно отправил тестовое сообщение из черновиков.
Здравствуйте, AlexNek, Вы писали:
AN> .>Главная фича — репозиторий бинарных артефактов. AN> То есть не может быть бинарников "несовместимых" с исходниками?
Управление версиями. Типа сделал какой-то модуль, скомпилил, протестил, выложил в репозиторий под новой версией. Другие указывают в исходниках какую версию использовать и качают готовый бинарник.
AN> Пожалуй пора искать алгоритм пользования гитом
Да всё просто:
1. правим код
2. git status — смотрим что наменяли.
3. git add/rm — отмечаем что хотим закоммитить.
4. git commit
5. git push
Шаги 3+4 в простых случаях делаются проще: "git commit -a" — коммит всех изменений сразу.
AN> Я в окно Баша даже ничего вставить из клипбоарда не могу, призодится все пути руками вводить
Эээ.. вроде shift-ins работает. (или мышой — одновременно left+right click).
AN> Ну если понравится поищу, а то SVN репозиторий никто не будет менять.
Это тебе повезло, что только под виндой работаешь. А так бы ты ещё намучился с русскими именами везде.
AN> .>Что значит "поиск новых файлов"? git status показывает всё. AN> Как я теперь понял это окно stag-ей, после каждой операции оно перечитывается.
Непонятно. Десятки тысяч файлов перечитывается в пределах 2-3 секунд. И, кстати, быстрее чем svn окно коммита на том же проекте.
AN> .>Хз, ни разу не пользовался. Я в мире java живу. AN> А я в НЕТе — прювет
Ява — рулезъ, .НЕТ — мастдай!
AN> Ну так данный софт и хочется.
Так можешь и то, и то поставить.
AN> А что в яве разве не нужно знать что под контролем версий, а что еще нет
Проводником не пользуюсь.
AN> Я открываю окно stag-ей, там список файлов которые я добавил проводником, потом жму кнопу добавить в рабочую область (или что то подопбное) и потом приведенная ошибка и вылазит.
Оно ещё и по-русски? Вообще непонятно.
AN> AN>> .>Что-то я не понял что ты со stash делал такое... Ты случайно его со stage не попутал?
AN> .>staging area — всё просто. Представь себе svn, диалог коммита. Ты там галочками отмечаешь что хочешь закоммитить. Так вот staging area это замена этому диалогу, с учётом того, что ты эти галочки можешь отмечать через командную строку (git add) и оно не теряется при закрытии/обновлении диалога. И ещё ты можешь отметить для коммита не весь файл целиком, а только некоторые ломтики (hunks) AN> Тое это как бы виртуальный репозиторий которого просто не существует физически?
Нет, просто редактируемый список того что ты собираешься закоммитить.
Для GUI он обычно не нужен, там чекбоксами работаешь. Для коммандной строки — удобно. В svn чтобы закоммитить некоторые файлы ты должен писать огромную страшную команду:
svn commit path1/file1 path2/file2 path2/file3 ...
в git можно например так:
git add path1/file1
cd path2
git add file2 file3
...
git commit
(но не обязательно, можно и как в svn).
Здравствуйте, ., Вы писали:
AN>> Пожалуй пора искать алгоритм пользования гитом .>Да всё просто: .>1. правим код .>2. git status — смотрим что наменяли. .>3. git add/rm — отмечаем что хотим закоммитить. .>4. git commit .>5. git push
.>Шаги 3+4 в простых случаях делаются проще: "git commit -a" — коммит всех изменений сразу.
Назовите меня мышевозилой гуёвым, но я для 2…4 использую git gui. Удобно просматривать изменения и выбирать, в какой последовательности какие из них коммитить.
Push из него тоже можно сделать, но у меня в большинстве случаев «сверху» svn и вместо git push надо git svn dcommit, а для этого в git gui кнопочка не предусмотрена. Да и нефиг вообще-то: отправка своих коммитов в другой репозиторий — это должен быть осознанный и обдуманный шаг.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> .>Главная фича — репозиторий бинарных артефактов. AN>> То есть не может быть бинарников "несовместимых" с исходниками? .>Управление версиями. Типа сделал какой-то модуль, скомпилил, протестил, выложил в репозиторий под новой версией.
в НЕТе это встроено производителем .>Другие указывают в исходниках какую версию использовать и качают готовый бинарник.
Это работает до тех пор пока кто то, что то не забудет сделать.
AN>> Пожалуй пора искать алгоритм пользования гитом .>Да всё просто: .>1. правим код .>2. git status — смотрим что наменяли. .>3. git add/rm — отмечаем что хотим закоммитить. .>4. git commit .>5. git push
А где же "взять изменения в ветку", "смержить с моими"?
.>Шаги 3+4 в простых случаях делаются проще: "git commit -a" — коммит всех изменений сразу.
AN>> Я в окно Баша даже ничего вставить из клипбоарда не могу, призодится все пути руками вводить .>Эээ.. вроде shift-ins работает. (или мышой — одновременно left+right click).
shift-ins вроде пробовал какую то фигню вставляет, а вот мышу не насиловал. А что мешает Ctl/V сделать?
AN>> .>Что значит "поиск новых файлов"? git status показывает всё. AN>> Как я теперь понял это окно stag-ей, после каждой операции оно перечитывается. .>Непонятно. Десятки тысяч файлов перечитывается в пределах 2-3 секунд. И, кстати, быстрее чем svn окно коммита на том же проекте.
До git status я еше не дошел, я только в GitExtension UI смотрел.
AN>> .>Хз, ни разу не пользовался. Я в мире java живу. AN>> А я в НЕТе — прювет .>Ява — рулезъ, .НЕТ — мастдай!
Я лучше промолчу
AN>> Ну так данный софт и хочется. .>Так можешь и то, и то поставить.
Да комп и так 10 минут грузится, спасибо McAfee
AN>> А что в яве разве не нужно знать что под контролем версий, а что еще нет .>Проводником не пользуюсь.
А... знаю... ls
AN>> Я открываю окно stag-ей, там список файлов которые я добавил проводником, потом жму кнопу добавить в рабочую область (или что то подопбное) и потом приведенная ошибка и вылазит. .>Оно ещё и по-русски? Вообще непонятно.
Не, по англицки, где то близко к "Add to working copy"
AN>> AN>> .>Что-то я не понял что ты со stash делал такое... Ты случайно его со stage не попутал?
AN>> .>staging area — всё просто. Представь себе svn, диалог коммита. Ты там галочками отмечаешь что хочешь закоммитить. Так вот staging area это замена этому диалогу, с учётом того, что ты эти галочки можешь отмечать через командную строку (git add) и оно не теряется при закрытии/обновлении диалога. И ещё ты можешь отметить для коммита не весь файл целиком, а только некоторые ломтики (hunks) AN>> Тое это как бы виртуальный репозиторий которого просто не существует физически? .>Нет, просто редактируемый список того что ты собираешься закоммитить. .>Для GUI он обычно не нужен, там чекбоксами работаешь.
где? В GitExtension не заметил пока.
.>Для коммандной строки — удобно. В svn чтобы закоммитить некоторые файлы ты должен писать огромную страшную команду: .>svn commit path1/file1 path2/file2 path2/file3 ...
Ни разу не видел . Черепаха это наш нижний уровень.
Здравствуйте, AlexNek, Вы писали:
AN> .>Управление версиями. Типа сделал какой-то модуль, скомпилил, протестил, выложил в репозиторий под новой версией. AN> в НЕТе это встроено производителем
И тоже само все эти шаги делает? Выкачивает все зависимости, все исходники/документацию?
AN> .>Другие указывают в исходниках какую версию использовать и качают готовый бинарник. AN> Это работает до тех пор пока кто то, что то не забудет сделать.
А репозиторий-то где?
AN> .>Да всё просто: AN> .>1. правим код AN> .>2. git status — смотрим что наменяли. AN> .>3. git add/rm — отмечаем что хотим закоммитить. AN> .>4. git commit AN> .>5. git push AN> А где же "взять изменения в ветку", "смержить с моими"?
Если push отказался работать (кто-то другой что-то успел наменять), то делаешь pull, правишь конфликты если есть, тестишь, делаешь push. В общем аналогично svn, только в svn когда делаешь update, он будет сливать твои незакоммиченные изменения с чужими. Если что-то не так пойдёт, вешайся... git же не позволяет сливать незакоммиченное, что гарантирует тебе возможность отката любых действий.
AN> shift-ins вроде пробовал какую то фигню вставляет, а вот мышу не насиловал. А что мешает Ctl/V сделать?
Да вроде работало... Не помню, у меня в убунте — работает. На работе винда — проверю на неделе.
А ctrl-<letter> это управляющая последовательнось в терминале.
Кстати, можно настроить оказывается.
AN> .>Ява — рулезъ, .НЕТ — мастдай! AN> Я лучше промолчу
Эх жаль... а можно было бы пофлеймить.
AN> Да комп и так 10 минут грузится, спасибо McAfee
Снеси. Я антивирусами не пользовался. А последнее время на убунте сижу..
AN> А... знаю... ls
Far manager.
А под убунтой, да.
AN> .>Оно ещё и по-русски? Вообще непонятно. AN> Не, по англицки, где то близко к "Add to working copy"
Слушай, ты вроде с tortoisesvn работаешь. Попробуй tortoisegit, он очень похож.
AN> .>Нет, просто редактируемый список того что ты собираешься закоммитить. AN> .>Для GUI он обычно не нужен, там чекбоксами работаешь. AN> где? В GitExtension не заметил пока.
Ээ.. не пользовался. В tortise — точно можно.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> .>Управление версиями. Типа сделал какой-то модуль, скомпилил, протестил, выложил в репозиторий под новой версией. AN>> в НЕТе это встроено производителем .>И тоже само все эти шаги делает? Выкачивает все зависимости, все исходники/документацию?
Это было к этому "Другие указывают в исходниках какую версию использовать и качают готовый бинарник."
AN>> .>Другие указывают в исходниках какую версию использовать и качают готовый бинарник. AN>> Это работает до тех пор пока кто то, что то не забудет сделать. .>А репозиторий-то где?
В смысле? Нормальный SVN
AN>> .>Да всё просто: AN>> .>1. правим код AN>> .>2. git status — смотрим что наменяли. AN>> .>3. git add/rm — отмечаем что хотим закоммитить. AN>> .>4. git commit AN>> .>5. git push AN>> А где же "взять изменения в ветку", "смержить с моими"? .>Если push отказался работать (кто-то другой что-то успел наменять), .>то делаешь pull,
Так пулл это похоже взять изменения в рабочую копию, разговор ведь был про ветку. .>правишь конфликты если есть, тестишь, делаешь push. В общем аналогично svn, только в svn когда делаешь update, он будет сливать твои незакоммиченные изменения с чужими. Если что-то не так пойдёт, вешайся... git же не позволяет сливать незакоммиченное, что гарантирует тебе возможность отката любых действий.
AN>> shift-ins вроде пробовал какую то фигню вставляет, а вот мышу не насиловал. А что мешает Ctl/V сделать? .>Да вроде работало... Не помню, у меня в убунте — работает. На работе винда — проверю на неделе. .>А ctrl-<letter> это управляющая последовательнось в терминале.
.>Кстати, можно настроить оказывается.
Спасибки, попробую
AN>> .>Ява — рулезъ, .НЕТ — мастдай! AN>> Я лучше промолчу .>Эх жаль... а можно было бы пофлеймить.
Жалко эту ветку, надо в спецфоруме открывать. Да и результата то все равно никакого не будет.
AN>> Да комп и так 10 минут грузится, спасибо McAfee .>Снеси. Я антивирусами не пользовался. А последнее время на убунте сижу..
Низзя, прописан в сетевой загрузке (это на работе)
AN>> А... знаю... ls .>Far manager.
Он у меня тоже всегда с собой
AN>> .>Оно ещё и по-русски? Вообще непонятно. AN>> Не, по англицки, где то близко к "Add to working copy" .>Слушай, ты вроде с tortoisesvn работаешь. Попробуй tortoisegit, он очень похож.
Да, для проводника, а для студии?
Здравствуйте, AlexNek, Вы писали:
AN> Это было к этому "Другие указывают в исходниках какую версию использовать и качают готовый бинарник."
maven сам готовый бинарник качает.
AN> .>А репозиторий-то где? AN> В смысле? Нормальный SVN
Для бинарников?
AN> .>Если push отказался работать (кто-то другой что-то успел наменять), AN> .>то делаешь pull, AN> Так пулл это похоже взять изменения в рабочую копию, разговор ведь был про ветку.
Я видимо вопрос не понял.
pull == fetch + merge.
fetch == "взять изменения", притом всегда в отдельную ветку "origin/master". Потом "замержить" твой "master" с "origin/master". А рабочую копию можно только checkout или commit, притом только в локальный "master". Потом можно мержить твой "master" в "origin/master" с помощью push.
AN> .>правишь конфликты если есть, тестишь, делаешь push. В общем аналогично svn, только в svn когда делаешь update, он будет сливать твои незакоммиченные изменения с чужими. Если что-то не так пойдёт, вешайся... git же не позволяет сливать незакоммиченное, что гарантирует тебе возможность отката любых действий.
AN> .>Эх жаль... а можно было бы пофлеймить. AN> Жалко эту ветку, надо в спецфоруме открывать. Да и результата то все равно никакого не будет.
Да ладно, флеймить везде можно, пока модераторы не придут. А результат будет — сотни сообщений.
AN> .>Слушай, ты вроде с tortoisesvn работаешь. Попробуй tortoisegit, он очень похож. AN> Да, для проводника, а для студии?
А tortoisesvn разве в Студию встраивается?
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Это было к этому "Другие указывают в исходниках какую версию использовать и качают готовый бинарник." .>maven сам готовый бинарник качает.
А где он его берет?
AN>> .>А репозиторий-то где? AN>> В смысле? Нормальный SVN .>Для бинарников?
Так люди и с фотошопом в нем работают.
А где-же их еще хранить?
AN>> .>Если push отказался работать (кто-то другой что-то успел наменять), AN>> .>то делаешь pull, AN>> Так пулл это похоже взять изменения в рабочую копию, разговор ведь был про ветку. .>Я видимо вопрос не понял. .>pull == fetch + merge. .>fetch == "взять изменения", притом всегда в отдельную ветку "origin/master". Потом "замержить" твой "master" с "origin/master". А рабочую копию можно только checkout или commit, притом только в локальный "master". Потом можно мержить твой "master" в "origin/master" с помощью push.
Я видимо этот ответ не понял
отдельную ветку "origin/master" — это разве не главная ветка?
Потом "замержить" твой "master" с "origin/master" — как?
AN>> .>Эх жаль... а можно было бы пофлеймить. AN>> Жалко эту ветку, надо в спецфоруме открывать. Да и результата то все равно никакого не будет. .>Да ладно, флеймить везде можно, пока модераторы не придут. А результат будет — сотни сообщений.
Да вроде ветка полезная, не хочется ее замусоривать. У меня уже скоро месяц пару сообщений ждут ответа, пока был в отпуске развил "большую полемику", а потом уже времени не стало. (перед авторами сообщений неудобно). Так что лучше не начинать.
AN>> .>Слушай, ты вроде с tortoisesvn работаешь. Попробуй tortoisegit, он очень похож. AN>> Да, для проводника, а для студии? .>А tortoisesvn разве в Студию встраивается?
Не а, для этого ankhSVN пользуется. Да тут пока бы просто так поиграться, а если понравиться можно и дальше искать.
Здравствуйте, AlexNek, Вы писали:
AN> .>maven сам готовый бинарник качает. AN> А где он его берет?
Из maven repository. Например, тут куча опен-сорсных библиотек. Можно создавать свои репозитории.
AN> .>Для бинарников? AN> Так люди и с фотошопом в нем работают. AN> А где-же их еще хранить?
Фотошоп ещё ладно, от безысходности, а вот всякие dll это жуть.
AN> .>Я видимо вопрос не понял. AN> .>pull == fetch + merge. AN> .>fetch == "взять изменения", притом всегда в отдельную ветку "origin/master". Потом "замержить" твой "master" с "origin/master". А рабочую копию можно только checkout или commit, притом только в локальный "master". Потом можно мержить твой "master" в "origin/master" с помощью push. AN> Я видимо этот ответ не понял AN> отдельную ветку "origin/master" — это разве не главная ветка?
Есть "master" — твоя личная главная ветка, а есть "origin/master" главная ветка репозитория с которого ты первый раз взял копию (потому и названо origin).
AN> .>Да ладно, флеймить везде можно, пока модераторы не придут. А результат будет — сотни сообщений. AN> Да вроде ветка полезная, не хочется ее замусоривать. У меня уже скоро месяц пару сообщений ждут ответа, пока был в отпуске развил "большую полемику", а потом уже времени не стало. (перед авторами сообщений неудобно). Так что лучше не начинать.
Истинно интересующиеся должны не брезговать ища инфу среди мусора. Это есть путь познания.
AN> .>А tortoisesvn разве в Студию встраивается? AN> Не а, для этого ankhSVN пользуется. Да тут пока бы просто так поиграться, а если понравиться можно и дальше искать.
Так ты значит и tortisesvn + ankhsvn юзаешь? Так используй tortoisegit+gitextensions.
Иногда надо дать права только на часть.
