Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[54.224.52.210] |
|
Сообщ.
#1
,
|
|
|
Не понимаю вообще! Это какое-то говнище просто.
Короче говоря, есть довольно большая задача. Седеллал для нее отдельный бранч. Делаю, комичу. Теперь хочу синхронизировать с мастером, но пока что в мои планы не входит комитить в мастер. Т.е. я хочу взять актуальную версию мастера с замерджить ее в свой бранч. Как, черт побори (тут используются другие слова), это сделать? |
Сообщ.
#2
,
|
|
|
git checkout master git pull --rebase git checkout your_branch git rebase master или git fetch git rebase origin/master Вот здесь подробнее. Если работаешь с этим добром под виндой - ставь TortuiseGit, выбираешь там (в контекстной менюшке эксплорера) команду rebase и в открывшимся диалоге выбираешь ветку, на которую будешь перебазироваться. Добавлено А вообще матюги при начале работы с git'ом - дело обычное. Непривычная у него модель ведения репозитория. Но потом, вроде, проникаешься. |
Сообщ.
#3
,
|
|
|
консоль галимая
|
Сообщ.
#4
,
|
|
|
Толи я не понял, толи это не совсем то.
Я хочу сделать так: Прикреплённая картинка
Добавлено Цитата Flex Ferrum @ Вот здесь подробнее. Может это и подробнее, но почему там стрелки все в обратном направлении? Я из этих картинок нихрена не понял Хрен поймешь, в каком направлении развиваются мастер и бранчи |
Сообщ.
#5
,
|
|
|
Цитата Fester @ Толи я не понял, толи это не совсем то. Я хочу сделать так: Ты не понял. Это именно то. Смотри, ты в какой-то момент отбранчевался и начинаешь пилить свой мегафункционал. Пилишь-пилишь, коммитишь в свой бранч. master за это время уже уехал. У тебя естественное желание - подсосать всё из мастера и накатить "сверху" свои коммиты. Для этого ты делаешь следующее: 1. Обновляешь свой локальный мастер: git checkout master git pull --rebase Таким образом в твоём локальном мастере оказываются все коммиты с сервера. 2. Перебазируешь свою ветку на новый мастер: git checkout your_branch git rebase master То есть переключаешься обратно на свою ветку и ребейзишь её на актуальный мастер. git при этом делает своеобразный merge - забирает коммиты из свежего (локального) мастера и пытается накатить сверху твои коммиты. Может получиться не для всего. В этом случае возникнут конфликты, которые он предложит тебе отрезолвить. Есть другой вариант (применяется у нас в силу определённых обстоятельств непреодолимой силы в виде тимлида): 1. Переключаешься на мастер. 2. Ребейзишься 3. Отрезаешь от него новую ветку типа your_branch_new 4. Переключаешься на неё 5. Мерджишь (git merge) в эту новую ветку свою старую ветку. 6. Профит - получаешь нужное тебе объединение. Чтобы не придумывать новые имена, можешь старую предварительно переименовать в your_branch_old, отрезать новую с привычным именем, а старую (после мерджа) удалять. |
Сообщ.
#6
,
|
|
|
Flex Ferrum
и что, git всегда корректно сам объеденияет коды? Если в мастере код поменяли местами(по тексту перенесли в другое место) он это поймет? |
Сообщ.
#7
,
|
|
|
Цитата ^D^ima @ Flex Ferrum и что, git всегда корректно сам объеденияет коды? Если в мастере код поменяли местами(по тексту перенесли в другое место) он это поймет? Ну, не всегда сам, не всегда корректно, но в целом да, с задачей справляется. |
Сообщ.
#8
,
|
|
|
Цитата Flex Ferrum @ 1. Обновляешь свой локальный мастер: Цитата Flex Ferrum @ 2. Перебазируешь свою ветку на новый мастер: Цитата Flex Ferrum @ То есть переключаешься обратно на свою ветку и ребейзишь её на актуальный мастер. &)$ Какой такой "локальный мастер"? Какой "новый мастер"? Еще какой-то "актуальный мастер". У меня один мастер и один бранч. Что из этих трех мастеров - мастер, а что бранч? Накой хрен мне столько всякой бесполезной шняги? Уши оборвать этому Торвальдсу! Цитата Flex Ferrum @ 1. Переключаешься на мастер. 2. Ребейзишься 3. Отрезаешь от него новую ветку типа your_branch_new 4. Переключаешься на неё 5. Мерджишь (git merge) в эту новую ветку свою старую ветку. 6. Профит - получаешь нужное тебе объединение. Почему все тащатся с этого говна? |
Сообщ.
#9
,
|
|
|
Цитата Fester @ Почему все тащатся с этого говна? Модно же ) |
Сообщ.
#10
,
|
|
|
Цитата Fester @ Какой такой "локальный мастер"? Какой "новый мастер"? Еще какой-то "актуальный мастер". У меня один мастер и один бранч. Что из этих трех мастеров - мастер, а что бранч? Накой хрен мне столько всякой бесполезной шняги? Уши оборвать этому Торвальдсу! Я думаю, тебе стоит начать с того, чтобы почитать - что такое git и как он работает. |
Сообщ.
#11
,
|
|
|
Цитата Fester @ Почему все тащатся с этого говна? Видимо, такова судьба всех продуктов Торвальдса |
Сообщ.
#12
,
|
|
|
Просто эта система контроля версий принципиально отличается от тех, с которыми ты, видимо, привык работать до этого. Она построена не на "традиционной" клиент-серверной архитектуре, где есть выделенный сервер, а у пользователей - локальный снимок, с которым они работают. git - это чисто распределённая система равноправных репозиториев, которые определённым образом можно синхронизировать. И в этой системе git server - это просто ещё одна копия репозитория, в которую можно заливать данные. При этом у всех пользователей - свои, локальные, полноценные копии. Поэтому я и говорю, что есть "локальный мастер" (версия master-ветки в репозитории на твоём диске), а есть master в репозитории на сервере.
|
Сообщ.
#13
,
|
|
|
Цитата Fester @ Гит этим славится. Он очень недружелюбен к юзверям. Чтобы полноценно работать с гитом нужно тщательно изучить принципы его работы. Вместо того чтобы заниматься делом, тебе приходится ковырятся в гайдах, писать на форумах, по сто раз клонировать удаленную репу. Торвальдс сделал систему заточенную под его собственные нужды, то бишь разработка ядра линупса, а хомячки дружно подхватили и сделали его де-факто стандартом. Пичаль, бида. Не понимаю вообще! Это какое-то говнище просто. |
Сообщ.
#14
,
|
|
|
Цитата applegame @ а хомячки дружно подхватили и сделали его де-факто стандартом. Пичаль, бида. Что-то этих хомячков подозрительно много. А публичные гит-сервера типа GitHub, GitLab, BitBucket и прочие, растут и множатся, как грибы после дождя. |
Сообщ.
#15
,
|
|
|
Цитата Flex Ferrum @ Mercurial работает на тех же принципах, что и Git, но при этом не требует долгого и вдумчивого курения мануалов для относительно простых операций. Так что это не оправдание. Просто эта система контроля версий принципиально отличается от тех, с которыми ты, видимо, привык работать до этого. Она построена не на "традиционной" клиент-серверной архитектуре, где есть выделенный сервер, а у пользователей - локальный снимок, с которым они работают. git - это чисто распределённая система равноправных репозиториев, которые определённым образом можно синхронизировать. И в этой системе git server - это просто ещё одна копия репозитория, в которую можно заливать данные. При этом у всех пользователей - свои, локальные, полноценные копии. Поэтому я и говорю, что есть "локальный мастер" (версия master-ветки в репозитории на твоём диске), а есть master в репозитории на сервере. |
Сообщ.
#16
,
|
|
|
Цитата kosten @ Модно же ) Лучше бы TFS было бы модно Цитата Flex Ferrum @ Я думаю, тебе стоит начать с того, чтобы почитать - что такое git и как он работает. Так я почитал И сайтец (git-scm.com) видел... там же все череж допу описано. Они вот даже коммиты обозначают в противоположную сторону (от нового к старому). Ну и лирическое - нахрена пользоваться системой, в которой сначала надо постигнуть какую-то философию по ее использованию? |
Сообщ.
#17
,
|
|
|
Цитата Fester @ Эта-эта, полегче Какой такой "локальный мастер"? Какой "новый мастер"? Еще какой-то "актуальный мастер". У меня один мастер и один бранч. Что из этих трех мастеров - мастер, а что бранч? Накой хрен мне столько всякой бесполезной шняги? Да, мастер -- это, в принципе, такой же равноправный бранч, как и все остальные. |
Сообщ.
#18
,
|
|
|
Цитата Fester @ Лучше бы TFS было бы модно Свят-свят-свят... Цитата Fester @ Ну и лирическое - нахрена пользоваться системой, в которой сначала надо постигнуть какую-то философию по ее использованию? Философию надо постигать в любом случае, если хочешь пользоваться эффективно. А твоём случае просто необходимо понять отличия от "традиционных" репозиториев. |
Сообщ.
#19
,
|
|
|
Цитата Flex Ferrum @ Подозрительно? Ничего подозрительного, их господь бог - Торвальдс. А он человек весьма талантливый, если не сказать гениальный и харизма у него серьезная во всех смыслах. Что-то этих хомячков подозрительно много. |
Сообщ.
#20
,
|
|
|
Цитата applegame @ Подозрительно? Ничего подозрительного, их господь бог - Торвальдс. А он человек весьма талантливый, если не сказать гениальный и харизма у него серьезная во всех смыслах. Ну вот не надо. Уверен, что процентов 80 пользователей git'а и знать не знают, что его Торвальдс написал. |
Сообщ.
#21
,
|
|
|
Цитата Flex Ferrum @ git - это чисто распределённая система равноправных репозиториев, которые определённым образом можно синхронизировать. И в этой системе git server - это просто ещё одна копия репозитория, в которую можно заливать данные. При этом у всех пользователей - свои, локальные, полноценные копии. Поэтому я и говорю, что есть "локальный мастер" (версия master-ветки в репозитории на твоём диске), а есть master в репозитории на сервере. Это я уже понял Но как это знание помогает в мердже/ребейзе итд? |
Сообщ.
#22
,
|
|
|
Цитата Flex Ferrum @ Об этом не знают разве только те пользователи, которые даже на знают, что они пользуются Git-ом. Ну вот не надо. Уверен, что процентов 80 пользователей git'а и знать не знают, что его Торвальдс написал. |
Сообщ.
#23
,
|
|
|
Цитата Fester @ Но как это знание помогает в мердже/ребейзе итд? Просто даёт понимание, что, откуда и куда перемещается. Собственно, я начинал пользоваться гитом с TortuiseGit, поэтому каких-то особых проблем не испытывал. Потом походу дела разобрался и с "философией". |
Сообщ.
#24
,
|
|
|
Цитата Flex Ferrum @ Как я уже писал выше. Mercurial - это тот же Git, но куда более интуитивный и понятный. "нетрадиционность" - не оправдание для всякого говна. А твоём случае просто необходимо понять отличия от "традиционных" репозиториев. |
Сообщ.
#25
,
|
|
|
Цитата negram @ Да, мастер -- это, в принципе, такой же равноправный бранч, как и все остальные. Так оно везде так И что из этого следует? Цитата Flex Ferrum @ Свят-свят-свят... Хум хау По-мне, так TFS - это просто, удобно и надежно. Правда дорого Цитата Flex Ferrum @ Философию надо постигать в любом случае, если хочешь пользоваться эффективно. А твоём случае просто необходимо понять отличия от "традиционных" репозиториев. Вот ничего нетрадиционного я в этих репозиториях в упор не вижу. Ну есть на каждой машине свой (или даже несколько). И что? Успех гита опуславливается наличием бесплатного гитхаба. Просто никому раньше не приходило в голову сделать бесплатный хостинг на, скажем, сабвержине. ИМХО. |
Сообщ.
#26
,
|
|
|
Цитата Fester @ Но как это знание помогает в мердже/ребейзе итд? запомни пару простых комманд: commit -- закоммитить merge <brunch> -- замержить pull - стянуть данные с сервера push - отправить на сервер checkout - переключиться на ветку Всё! Шли к чёртовой бабушке всех, кто рассказывает про всякие rebase. Вот этого хватит на большенство задач даже после прохождения "первого знакомства" |
Сообщ.
#27
,
|
|
|
Цитата Fester @ Хум хау По-мне, так TFS - это просто, удобно и надежно И тормозно. А если TFS Git - так ещё и глюкаво... Добавлено Цитата negram @ Шли к чёртовой бабушке всех, кто рассказывает про всякие rebase. Вот этого хватит на большенство задач даже после прохождения "первого знакомства" Ну я пошёл, что-ли... |
Сообщ.
#28
,
|
|
|
Цитата Flex Ferrum @ Собственно, я начинал пользоваться гитом с TortuiseGit, поэтому каких-то особых проблем не испытывал. Потом походу дела разобрался и с "философией". Я тоже с TortuiseGit. И вся эта распределенная "философия" понятна. Но вот что и куда мержится... и по каким таким неведомым правилам - это темный лес |
Сообщ.
#29
,
|
|
|
Цитата Fester @ Ошибаешься, причём очень сильно. Популярность гиту пришла гораздо раньше появления гитхаба.Успех гита опуславливается наличием бесплатного гитхаба. Просто никому раньше не приходило в голову сделать бесплатный хостинг на, скажем, сабвержине. ИМХО. И на тот момент был уже бесплатный хостинг SVN - от гугла (который со временем помер), был и Sourceforge, про который уже редко вспоминают. Добавлено Цитата Flex Ferrum @ Цитата negram @ Шли к чёртовой бабушке всех, кто рассказывает про всякие rebase. Вот этого хватит на большенство задач даже после прохождения "первого знакомства" Ну я пошёл, что-ли... Не, ну правда, зачем ты начал про rebase человеку, который только-только в гит пришел? Я rebase раз в месяц делаю, и то не каждый -- про эту команду можно первые полгода даже не догадываться. |
Сообщ.
#30
,
|
|
|
Цитата Fester @ Успех гита опуславливается наличием бесплатного гитхаба. Вот мне тоже так кажется - гитхаб весьма удобен (по-моему самый удобный из альтернатив), и поддерживает только гит. Так что если выбрал ео в качестве площадки, придётся либо кушать кактус в виде гита, либо использовать костыли для более вменяемой системы вроде hg-git, что тоже особой радости не доставляет. |
Сообщ.
#31
,
|
|
|
Цитата Fester @ git merge <другая ветка>Но вот что и куда мержится Мержит "другая ветка" в текущую. |
Сообщ.
#32
,
|
|
|
Цитата Flex Ferrum @ И тормозно. Не согласен TFS - вполне себе шустро работает. Цитата Flex Ferrum @ TFS Git Не знаю такого Цитата negram @ запомни пару простых комманд И как мне этими командами сделать то, что я нарисовал в посте Как работают с git'ом? (сообщение #3707209)? Добавлено Цитата negram @ git merge <другая ветка> Мержит "другая ветка" в текущую. Ну вот у меня есть мастер, с котого я неделю назад ответвил бранч. Иду в папку с бранчем, говорю "merge" в окошке выбираю "from master" клацаю "ОК" .... "you are up to date" и нихрена не мержится и не переносится из мастера. бранч остается без изменений. |
Сообщ.
#33
,
|
|
|
Цитата OpenGL @ Я сижу на битбакете, он немного проигрывает гитхабу в функциональности, зато можно бесплатно пять приватных реп сделать, на гитхабе, ЕМНИП, бесплатно, только открытые репы. Вот мне тоже так кажется - гитхаб весьма удобен (по-моему самый удобный из альтернатив), и поддерживает только гит. |
Сообщ.
#34
,
|
|
|
Цитата Fester @ А в мастере есть изменения? я так понял, мастер в твоей схеме -- это то, что на сервере? Тогда:Иду в папку с бранчем, говорю "merge" в окошке выбираю "from master" клацаю "ОК" .... "you are up to date" и нихрена не мержится и не переносится из мастера. бранч остается без изменений. Переключаешься на мастер, там `git pull' Возвращаешься в свою ветку, там `git merge master' Скрытый текст можно сразу git merge origin/master -- тогда изменения подтянуться из удалённого мастера, но путь это будет потом |
Сообщ.
#35
,
|
|
|
Скрытый текст Цитата negram @ можно сразу git merge origin/master -- тогда изменения подтянуться из удалённого мастера, но путь это будет потом Цитата Flex Ferrum @ git fetch git rebase origin/master Ты про fetch забыл. Изменения с сервера то подтянуть надо. |
Сообщ.
#36
,
|
|
|
Цитата Flex Ferrum @ Скрытый текст Цитата negram @ можно сразу git merge origin/master -- тогда изменения подтянуться из удалённого мастера, но путь это будет потом Цитата Flex Ferrum @ git fetch git rebase origin/master Ты про fetch забыл. Изменения с сервера то подтянуть надо. Скрытый текст чорт, да просто я перед каждым общением с удалённой репой `git pull' делаю |
Сообщ.
#37
,
|
|
|
Цитата negram @ А в мастере есть изменения? да Цитата negram @ я так понял, мастер в твоей схеме -- это то, что на сервере? на сервере там все, в том числе и бранч мастер - это то, куда коммитят все. а в бранч коммичу только я. и то и другое пуллом отправляю на сервер и оно там каждую ночь билдится. Цитата negram @ Переключаешься на мастер, там `git pull' Возвращаешься в свою ветку, там `git merge master' Погоди Не так быстро, я записываю 1) захожу в папку с бранчем 2) switch -> master 3) pull 3.5) тут будут конфликты 4) switch -> branch 5) merge master 6) commit 7) push я все правильно понял? |
Сообщ.
#38
,
|
|
|
Цитата Fester @ я все правильно понял? Да. Только пункта 3.5 не будет - если ты в свой (локальный) мастер ничего не коммитил. А ты, наверняка, не коммитил. Но будет пункт "5.5 тут будут конфликты". Добавлено И п. 6 не будет. merge сразу локальный коммит делает. |
Сообщ.
#39
,
|
|
|
Ок, пойду эксперементировать
Если что, то знайте, что меня убили коллеги |
Сообщ.
#40
,
|
|
|
Правда, в результате всего этого действа у тебя будет так называет "Merge commit", в котором будет указано, с какой ветки ты мержился и какие конфликты были. Некоторым владельцам репозиториев такие коммиты не нравятся. Поэтому вместо merge и используется rebase.
|
Сообщ.
#41
,
|
|
|
Цитата Flex Ferrum @ Вот Некоторым владельцам репозиториев такие коммиты не нравятся. |
Сообщ.
#42
,
|
|
|
negram, в этом есть определённая логика. rebase ты делаешь тогда, когда забираешь чужие коммиты к себе в ветку - ребейзишься на master, или на origin/master, или ещё куда (типа git pull --rebase). При этом всё делается аккуратно - все твои коммиты, сделанные с последней точки ветвления, пытаются накатиться поверх нового содержимого. А вот когда ты хочешь свою ветку затащить в master - ты уже делаешь merge. И вот чтобы не было merge-коммита ты сначала делаешь rebase своей ветке, а потом спокойно её мёржишь.
|
Сообщ.
#43
,
|
|
|
Говорят гитхаб научился делать ребейз автоматически прямо при мердже пулл-реквеста.
|
Сообщ.
#44
,
|
|
|
Цитата Flex Ferrum @ Вот этого я понимать отказываюсь. Во-первых, этот коммит не враг, а друг: я всегда знаю какой коммит нужно откатить, если намержил чего-то не того, и из твоего поста видна одна лишь эстетическая составляющая "чтобы не было мерж-коммита" и логическая компонента выглядит притянутой за уши. Во-вторых, проглядывая историю ты всегда видишь этот эвент. Пусть это не всегда нужно, но лишней информацией это не будет. И вот чтобы не было merge-коммита |
Сообщ.
#45
,
|
|
|
Я обычно перед тем как "смерджить все свое локальное курево в мастер" делаю патч.
Возможно я это уже где то писал. Т.е. делаю дифф в бинарном виде, применяю его на чистой ветке и все. Имеем супер патч, в один коммит. Не надо никаких "мердж коммитов" и т.п. смуты. делаем так: git checkout master git pull --rebase git checkout -b CLEAN_BRANCH_NAME git diff --binary CLEAN_BRUNCH_NAME...DEV_BRANCH_NAME_WITH_100500_INTERMEDIA_COMITS > my.patch git apply -3 my.patch git commit -m "my super feature" git push origin HEAD И все, с этого бранча уже можно поднимать красивый пулреквест. А как у меня там мысль ходила туда сюда в сотне коммитах - этого потомкам знать не надо, пусть я буду в их глазах идеален и пишу сразу как положено Добавлено Вообще не представляю себе теперь жизни в какой то другой системе контроля версий. Правда, так и не осилил никакой "красивой оболочки" для git, все в консольке. Параллельно, правда, в Perforce живу, ну это небо и земля - особенно что касается скорости. |
Сообщ.
#46
,
|
|
|
Сообщ.
#47
,
|
|
|
Цитата git squash Мне скваш как то не понравился, есть шанс ошибиться, константу не ту поставить. Вообще патч в виде диффа бранчей, по мне так, будет потупее и понадёжнее. |
Сообщ.
#48
,
|
|
|
Цитата Бобёр @ Мне скваш как то не понравился, есть шанс ошибиться, константу не ту поставить. Вообще патч в виде диффа бранчей, по мне так, будет потупее и понадёжнее. У меня в этом случае чуть другая техника. Я перед мёрджем делаю git reset --soft до нужного коммита (с которого хочу схлопнуть), потом делаю новый коммит всего добра, и в итоге - merge. |
Сообщ.
#49
,
|
|
|
Цитата Бобёр @ делаем так: git checkout master git pull --rebase git checkout -b CLEAN_BRANCH_NAME git diff --binary CLEAN_BRUNCH_NAME...DEV_BRANCH_NAME_WITH_100500_INTERMEDIA_COMITS > my.patch git apply -3 my.patch git commit -m "my super feature" git push origin HEAD 7 (!!!) действий для одного мерджа! Млять, люди, это же не нормально! В томже самом TFS мердж делается за пару кликов. Все просто и понятно. Я уж не говорю о том, что можно изменить 100 файлов, а закомитить 1 и работать дальше с веткой. Или замерджить только один changeset. |
Сообщ.
#50
,
|
|
|
Цитата Fester @ 7 (!!!) действий для одного мерджа! Млять, люди, это же не нормально! А за сколько действий в TFS ты можешь схлопнуть несколько коммитов в один (но жирный), который потом и замёржить? По факту в Git мердж делается двумя командами, которые тебе выше уже показали. |
Сообщ.
#51
,
|
|
|
Цитата 7 (!!!) действий для одного мерджа Можно и за 6, только у нас в мастер коммитить нельзя. Цитата Млять, люди, это же не нормально! У меня все автоматизировано, так что не переживай Добавлено Цитата По факту в Git мердж делается двумя командами, которые тебе выше уже показали. Можно и одной, правда потом может быть чуть больно . |
Сообщ.
#52
,
|
|
|
Цитата Flex Ferrum @ схлопнуть несколько коммитов в один (но жирный) зачем? Цитата Flex Ferrum @ который потом и замёржить Мердж в TFS'е делается за пару кликов. Если хочешь замержить конкретные changeset'ы, то количество кликов увелисивается на количество changeset'ов + 1. Единственно, что не очень хорошо сделано - это поиск shelveset'ов... Цитата Бобёр @ Можно и за 6, только у нас в мастер коммитить нельзя. Можно вообще не заморачиваться, слить 2 папки BeyondCompare'ом и закомитить все Получится 1-2 действия включая pull и никакого мерджа |
Сообщ.
#53
,
|
|
|
Цитата Fester @ зачем? Затем, чтобы твои частые коммиты (а такое бывает, если работа растягивается надолго, и надо хранить промежуточные результаты где-нибудь в более надёжном месте, чем локальный диск) после мерджа в основую ветку выглядели как один, но жирный. Его и откатить, в случае чего, проще будет. |
Сообщ.
#54
,
|
|
|
Цитата Flex Ferrum @ git reset --soft удаляет твою ветку с сохранинием измененных файлов? У меня в этом случае чуть другая техника. Я перед мёрджем делаю git reset --soft до нужного коммита (с которого хочу схлопнуть), потом делаю новый коммит всего добра, и в итоге - merge. |
Сообщ.
#55
,
|
|
|
Откатывает индекс, а файлы не трогает, да.
|
Сообщ.
#56
,
|
|
|
Цитата Flex Ferrum @ А с веткой что происходит?Откатывает индекс, а файлы не трогает, да. Цитата Flex Ferrum @ Кстати постоянно с таким сталкиваюсь, и где ты хранишь промежуточные результаты? Отдельный удаленый форк заводишь, который потом подчищаешь? а такое бывает, если работа растягивается надолго, и надо хранить промежуточные результаты где-нибудь в более надёжном месте, чем локальный диск |
Сообщ.
#57
,
|
|
|
applegame, пока не сделаешь git branch -d - ветка жива. А так, пушу ветку на сервер, а после мерджа - прибиваю. Ресет комнатам делается на локальной ветке перед мерджем.
|
Сообщ.
#58
,
|
|
|
Цитата Flex Ferrum @ Затем, чтобы твои частые коммиты (а такое бывает, если работа растягивается надолго, и надо хранить промежуточные результаты где-нибудь в более надёжном месте, чем локальный диск) после мерджа в основую ветку выглядели как один, но жирный. Его и откатить, в случае чего, проще будет. Мердж - это и есть один жирный коммит. Зачем какие-то танцы с бубном? |
Сообщ.
#59
,
|
|
|
Цитата Fester @ Мердж - это и есть один жирный коммит. Зачем какие-то танцы с бубном? Не знаю, как в TFS, а в гите после мерджа в ветке, в которую ты мерджишь, оказывается вся твоя история коммитов из той ветки, которую мерджишь. Сделал 100500 коммитов с комментариями "Build fix", "Fix typo", "Temporary Interface Rename" - все они окажутся в целевой ветке. Вот чтобы всю эту историю не тащить и делают squash. |
Сообщ.
#60
,
|
|
|
Цитата Flex Ferrum @ Вот чтобы всю эту историю не тащить и делают squash. Ну т.е. сам себе придумал проблему, потом решил ее и выставил это решение как плюс системы |
Сообщ.
#61
,
|
|
|
Цитата Fester @ Ну т.е. сам себе придумал проблему, потом решил ее и выставил это решение как плюс системы Это "не сам себе придумал проблему". Такая "проблема" имеет место быть у многих. Или ты хочешь сказать, что результаты месячной работы ты заливаешь на сервер одним коммитом? Что-то я сомневаюсь. |
Сообщ.
#62
,
|
|
|
Проблема в том, что при мердже из одного бранча в другой переносит все комиты, а не делается одним коммитом.
|
Сообщ.
#63
,
|
|
|
Цитата Fester @ Проблема в том, что при мердже из одного бранча в другой переносит все комиты, а не делается одним коммитом. Это не проблема. Это особенность. У каждого из подходов есть свои плюсы и минусы. |
Сообщ.
#64
,
|
|
|
Если делается большая таска, то желательно пулиться с мастера часто, тогда конфликты будут маленькие, а не простыни, которые непонятно как резолвить. ИМХО.
|
Сообщ.
#65
,
|
|
|
А есть оконная версия этого говна? какой понт сидеть в консоли, и редакторы вызывать из консоли
|
Сообщ.
#66
,
|
|
|
Git? Не знаю такого слова.
Чёт я запутался. Что такое комет и что такое мердж? Как увидеть какие файлы обновятся? Как увидеть изменившиеся части? Как автоматизировать заплатки? - Как сделать автоматический прием заплаток? - Как получить заплатки от ведущей-ветки? Я правильно понимаю что эта технология предназначена для работы только с заплатками и сливать целиком файлы никак не выйдет так как существует 4 вида заплаток. 1) Разница между m3-m2 которую мы можем получить от мастера. 2) Разница между m3-m2 которую мы не можем получить от мастера. (сам термин мастер подразумевает, что такого не бывает) 3) Разница между b3-m2 которую мы можем принять 4) Разница между b3-m2 которую мы не можем принять. 5) Разница между m3-b2 которую мы можем отправить. Не понятно как это связано с версией программы если у каждого файла своя версия. И как отобрать те файлы в ветке которые мы сливаем? А сливаются ветки или файлы? Я к чему порядок какой сначала отбираем что слить или с начало сливаем а потом отсеиваем что нам не подходит? Или сначала надо дифы построить? |
Сообщ.
#67
,
|
|
|
Цитата Pavia @ Как увидеть какие файлы обновятся? Как увидеть изменившиеся части? git diff Заплатки не юзают чаще всего. Сливают ветки в мастер. Мастер это такая же ветка, только со стабильным кодом. Версия программы это чаще всего несколько слитых веток в мастер, просто их помечают тегами, типа v1.1.100. Добавлено Цитата Fester @ 1) захожу в папку с бранчем 2) switch -> master 3) pull 3.5) тут будут конфликты 4) switch -> branch 5) merge master 6) commit 7) push Можно так: 1. Комитишься и пушишь в свою ветку. 2. В своей ветке делаешь git pull origin master 3. Резолвишь конфликты и пушишь в свою ветку 4. Делаешь мердж реквест, чтобы ТЛ затянул в мастер или куда надо... Добавлено Цитата Koss @ какой понт сидеть в консоли Понт в том чтобы понимать что делаешь)) |
Сообщ.
#68
,
|
|
|
Цитата Fester @ Какой такой "локальный мастер"? Какой "новый мастер"? Еще какой-то "актуальный мастер". У меня один мастер и один бранч. Что из этих трех мастеров - мастер, а что бранч? Накой хрен мне столько всякой бесполезной шняги? Уши оборвать этому Торвальдсу! Инструмент не изучил, но обрывать готов? Профи Вот тут все есть, аж на русском: https://git-scm.com/book/ru/v1 |
Сообщ.
#69
,
|
|
|
Цитата Fester @ Короче говоря, есть довольно большая задача. Седеллал для нее отдельный бранч. Делаю, комичу. Теперь хочу синхронизировать с мастером, но пока что в мои планы не входит комитить в мастер. Т.е. я хочу взять актуальную версию мастера с замерджить ее в свой бранч. Как, черт побори (тут используются другие слова), это сделать? git commit -m "Мои текущие правки" git pull origin master Этого достаточно. А то, вижу, Флекс там насоветовал финтов ушами. Изменения сольются с удалённой ветки мастер в твою текущую локальную. Если что-то поломается - откатываешься на коммит или просто сносишь всё до него. |
Сообщ.
#70
,
|
|
|
Что вы наделали!?
Я же из-за этой темы начал Git изучать. И уже один свой проект на 1С на него перевел. |
Сообщ.
#71
,
|
|
|
Поставь TortoiseHG и не парься со всякой глупостью
|
Сообщ.
#72
,
|
|
|
Цитата OpenGL @ Поставь TortoiseHG и не парься со всякой глупостью ты не поверишь, из консоли норм все работает |
Сообщ.
#73
,
|
|
|
Цитата kosten @ Я же из-за этой темы начал Git изучать. И уже один свой проект на 1С на него перевел. А... как ты жил раньше? |
Сообщ.
#74
,
|
|
|
Цитата Астарот @ А... как ты жил раньше? Файлы датой в имени, встроенное хранилище 1С. |
Сообщ.
#75
,
|
|
|
Цитата Астарот @ А... как ты жил раньше? 1С, наверное, должно было тебе всё сказать |
Сообщ.
#76
,
|
|
|
Сообщ.
#77
,
|
|
|
Цитата Serafim @ 1С, наверное, должно было тебе всё сказать Даже с ним можно жить по-разному |
Сообщ.
#78
,
|
|
|
Цитата Астарот @ Даже с ним можно жить по-разному Сима, учись не предвзятому взгляду на вещи. |
Сообщ.
#79
,
|
|
|
В 8-й версии (от 8.2 и выше) можно делать классные вещи и натягивать на существующую базу. ERP система с учетом реалий РФ, если уметь готовить
|
Сообщ.
#80
,
|
|
|
Цитата kosten @ Сима, учись не предвзятому взгляду на вещи. Невозможно вбрасывать смотря на вещи непредвзято |
Сообщ.
#81
,
|
|
|
А если в git переименовать ветку master в 'экстаз', то потом можно будет сливаться с гораздо бОльшим удовольствием.
|
Сообщ.
#82
,
|
|
|
Цитата Serafim @ Невозможно вбрасывать смотря на вещи непредвзято Возможно. Например сколько лет понадобилось для корректного отлова такого? try { thisFunctionDoesNotEvenExist(); //вызов несуществующей функции } catch (\EngineException $e) { echo $e->getMessage(); } |
Сообщ.
#83
,
|
|
|
Цитата A.I. @ Например сколько лет понадобилось для корректного отлова такого? А оно на этапе трансляции, или что там у 1С, не отваливалось что ли? |
Сообщ.
#84
,
|
|
|
Цитата A.I. @ Возможно. Например сколько лет понадобилось для корректного отлова такого? Судя по документации уже примерно 20 лет как отлавливается. Так что мимо, давай дальше. для тех кто в танке В то время вышел php 4.01, где был set_error_handler, позволяющий отлавливать ошибки подобного рода. В районе 5ки появились исключения. В 7ке (около пары лет назад) ошибки заменили на инстанс Throwable исключения, так что появилась возможность отлавливать и обрабатывать фатальные ошибки в месте вызова через конструкции исключения, а не в дочернем асинхронном коллбеке. А т.к. фатальные ошибки всё же на то и фатальны, что являются альтернативой ошибок компиляции, после которых работа ПО практически невозможна. То и отлов данных ошибок в асинхронном колбеке - вполне корректен (так поставил свой вопрос A.I.). А возможность отлова подобных ошибок во время работы в месте возникновения - это лишь плюшка. Подключаешь ты, например, исходник на C++ внутрь пыха, а он тебе кидает исключение, не могу собрать его, а ты такой гасишь исключение и пишешь в логи "отлично, работаем дальше" Ну или запускаешь gcc, передавая управление уже туда... Добавлено P.S. а за echo $e->getMessage(); в мире PHP принято убивать на месте, т.к. эхо является побочным эффектом, что нарушает не только стандарты PSR, но и разумность существования этого кода. Вменяемые люди используют для таких вещей PSR-3 реализации, например monolog. |
Сообщ.
#85
,
|
|
|
Цитата kosten @ Файлы датой в имени Т.е. каждый раз, когда меняешь файл надо сохранять его с новой датой в названии? Это такая практика у разработчиков 1С или чисто твоя фишка?) |
Сообщ.
#86
,
|
|
|
Принимайте в секту. Я раньше балдел от Perforce, скрипел зубами от SVN, и просто выворачивался наизнанку от гита (особенно который MS встроила в TFS). А недавно...
- Здравствуйте, меня зовут Mr.Delphist, и я храню свои pet-проекты в Git |
Сообщ.
#87
,
|
|
|
Цитата Mr.Delphist @ - Здравствуйте, меня зовут Mr.Delphist, и я храню свои pet-проекты в Git (присутствующие хором): Добрый вечер, Mr. Delphist! |
Сообщ.
#88
,
|
|
|
Цитата domencom @ Это такая практика у разработчиков 1С или чисто твоя фишка?) Это чисто моя фишка. В 1С по дефолту конфигурация сохраняется одним файлом. Поэтому вечерком сохраняешь в файл с датой. |
Сообщ.
#89
,
|
|
|
Цитата Mr.Delphist @ - Здравствуйте, меня зовут Mr.Delphist, и я храню свои pet-проекты в Git Да все так хоть раз делали! |
Сообщ.
#90
,
|
|
|
Цитата Астарот @ Да все так хоть раз делали! Кроме Кости :trollface: |
Сообщ.
#91
,
|
|
|
Цитата Serafim @ Судя по документации уже примерно 20 лет как отлавливается. Так что мимо, давай дальше. именно undefined function безо всяких проверок типа callable стандартным try/catch? |
Сообщ.
#92
,
|
|
|
чем смотреть изменения? У меня какая-то хрень раньше была в редакторе открывала, и можно было смотреть две колонки в чём разница
|
Сообщ.
#93
,
|
|
|
Цитата Koss @ чем смотреть изменения git diff :trollface: |
Сообщ.
#94
,
|
|
|
винмерге я вспомнил. прще всего гитк написать и там будет. тока винмерге лучшы
Добавлено git difftool HEAD HEAD~1 Добавлено зачем git diff нужен? он делает такую херню, что командную строку потом закрываешь |
Сообщ.
#95
,
|
|
|
Цитата Koss @ чем смотреть изменения? BeyondCompare. Ничего лучше я еще не видел. |
Сообщ.
#96
,
|
|
|
Цитата Koss @ зачем git diff нужен? он делает такую херню, что командную строку потом закрываешь И что с ним не так? |
Сообщ.
#97
,
|
|
|
Цитата Fester @ BeyondCompare. Ничего лучше я еще не видел. Дык оно же платное... |
Сообщ.
#98
,
|
|
|
Лучше заплатить деньги и пользоваться удобным продуктом, чем испытывать боль и унижение от какой-то бесплатной поделки.
|
Сообщ.
#99
,
|
|
|
Цитата Da$aD @ И что с ним не так? а я запускаю и он у меня командную строку вешает. Куча говна вылазит на экран которое не прокрутишь ничо не сделаешь пока не закроешь кэмэдэ |
Сообщ.
#100
,
|
|
|
Цитата applegame @ Я сижу на битбакете, он немного проигрывает гитхабу в функциональности, зато можно бесплатно пять приватных реп сделать, на гитхабе, ЕМНИП, бесплатно, только открытые репы. Я тоже пользуюсь битбакетом. Там неограниченное количество приватных репов (бесплатно). Также можно создавать команды разработчиков. До 5 человек бесплатно, больше - за деньги. |
Сообщ.
#101
,
|
|
|
Цитата Koss @ чем смотреть изменения? Да этих утилит хоть попой жуй. Я Meld-ом пользуюсь, например. |
Сообщ.
#102
,
|
|
|
я винмерге.
|
Сообщ.
#103
,
|
|
|
Цитата OpenGL @ Цитата Koss @ чем смотреть изменения? Да этих утилит хоть попой жуй. Я Meld-ом пользуюсь, например. В intellij idea неплохо видно искаробки. |
Сообщ.
#104
,
|
|
|
тогда зачем нужен git diff ?
|
Сообщ.
#105
,
|
|
|
Цитата Fester @ BeyondCompare. Ничего лучше я еще не видел Помнится, мне его очень советовали в одном из стародавних проектов (причём со стороны Заказчика). Поставил, потыкал - и не понял, в чём восторги. Дефолтные диффы что перфорса, что тортойзов ничем не хуже. Разве если его с WinDiff сравнивать - но там минимальный функционал по определению, и апдейтов уж сколько лет нету Или надо какие-то особые условия, на которых диффы от BeyondCompare становятся кардинально читабельней тех же тортойзов? (возможность вкл-выкл сравнения witespace, посимвольная подсветка отличий в строке и т.п.) |
Сообщ.
#106
,
|
|
|
год на проекте камиты не делал. завтра гит адд сделаю потом камит .
|
Сообщ.
#107
,
|
|
|
Цитата Mr.Delphist @ Или надо какие-то особые условия, на которых диффы от BeyondCompare становятся кардинально читабельней тех же тортойзов? Никаких особых условий. Цитата Mr.Delphist @ возможность вкл-выкл сравнения witespace, посимвольная подсветка отличий в строке и т.п. Жто все есть в BeyondCompare, плюс к этому возможность "ручного" сравнения, т.е. можешь сказать, что строка Х в правой части соответствует строке Y в левой - очень удобная функция. Плюс там хорошо реализована возможность разбиения измененного блока на строки и построчного мерджа. Также, очень часто бывает полезно редактировать текст "на лету". Удобный интерсейс, умеет сравнивать папки итд. Не знаю, возможно это сила привычки, но я действительно не видел ничего лучше... |
Сообщ.
#108
,
|
|
|
а бывают конверторы в гит репозитерий?
|
Сообщ.
#109
,
|
|
|
git init
|
Сообщ.
#110
,
|
|
|
Ларин я не про это! Есть куча папок с называнием версии. от 1.101 до 1.236 и в каждом архиве изменения.
|
Сообщ.
#111
,
|
|
|
Цитата Бобёр @ В intellij idea неплохо видно искаробки. +1 Хз просто зачем нужны остальные |
Сообщ.
#112
,
|
|
|
Цитата Koss @ Есть куча папок с называнием версии. от 1.101 до 1.236 и в каждом архиве изменения. Если хочется сохранить историю, то можно заливать эти папки по очереди в рабочую папку и коммитить. Если история не нужна, то залить последнюю версию, и git init |
Сообщ.
#113
,
|
|
|
кароч цикл написать, и запускать с параметрами
Добавлено нет. история нужна |
Сообщ.
#114
,
|
|
|
Цитата Serafim @ Хз просто зачем нужны остальные Затем, что не все пишут в идее Добавлено Цитата Koss @ Есть куча папок с называнием версии. от 1.101 до 1.236 и в каждом архиве изменения. Тогда скрипт, по очереди кидающий изменения в репозиторий и вызывающий git commit |
Сообщ.
#115
,
|
|
|
Я это итак знаю, Ларин! Врядли я готовую программу найду такую.
Закоммитил сёдня исходник, который 2 года не коммитился. Неудобно вот что пишешь гитдиффтулл коммит1 коммит2 длинное название файла, и винмерге открывается. А шо эта проще нельзя сделать? |
Сообщ.
#116
,
|
|
|
Цитата OpenGL @ Затем, что не все пишут в идее Правильно, нафиг жабу, надо брать шторм и писать на православных языках |
Сообщ.
#117
,
|
|
|
Цитата Serafim @ надо брать шторм и писать на православных языках а что умеет шторм из православного энтерпрайза? |
Сообщ.
#118
,
|
|
|
Цитата A.I. @ Цитата Serafim @ надо брать шторм и писать на православных языках а что умеет шторм из православного энтерпрайза? php Вообще у idea есть плагинчики для многих языков, для go например... я с ними правда по наслышке в основном знаком. |
Сообщ.
#119
,
|
|
|
Цитата Бобёр @ Вообще у idea есть плагинчики для многих языков 1C? |
Сообщ.
#120
,
|
|
|
Цитата Koss @ Неудобно вот что пишешь гитдиффтулл коммит1 коммит2 длинное название файла, и винмерге открывается. А шо эта проще нельзя сделать? Да это любая оболочка умеет. TortoiseGit и git extensions уж точно. Цитата Бобёр @ Вообще у idea есть плагинчики для многих языков Эти плагины только базовые возможности дают. По крайней мере я пробовал плагин для rust - оказалось, что он ничем не лучше Sublime. |
Сообщ.
#121
,
|
|
|
я в принцессе гите тока изменения смотрю
|
Сообщ.
#122
,
|
|
|
А если я чото поделал на одном компе(создал ридми.тхт), сделал гит пуш , пришёл домой, сделал гид фетчь оригин, потом гит мерге оригин\мастер. у меня создался этот фаел. А как работать с одним и тем же файлом? как он сливает?
|
Сообщ.
#123
,
|
|
|
Koss, на те туториал https://githowto.com/ru
Я по нему начал фтыкать про гит |
Сообщ.
#124
,
|
|
|
Зачем это нужно, если есть ProGit? https://git-scm.com/book/ru/v1 |
Сообщ.
#125
,
|
|
|
+1 к ссылке Астарота.
Даже я разобрался. |
Сообщ.
#126
,
|
|
|
A.I.? http://eax.me/git-commands/ вот лучше. я там всё понял
Добавлено оказывается этот гит всегда был мне нужен! Добавлено Цитата kosten @ Даже я разобрался. как перейти по ссылке? |
Сообщ.
#127
,
|
|
|
Цитата kosten @ Даже я Скромняга Ты даже в 1С разобрался, куда там гиту Добавлено Цитата Koss @ как перейти по ссылке? Кликни по ней. |
Сообщ.
#128
,
|
|
|
1С: Гит
|
Сообщ.
#129
,
|
|
|
Цитата Koss @ как перейти по ссылке? Пятница завтра. |
Сообщ.
#130
,
|
|
|
хватит меня вербовать !!!
|
Сообщ.
#131
,
|
|
|
Снова проблема с гитом
Как узнать, какие коммиты были сделаны непосредственно на бранче? Т.е. без учета коммитов из других бранчей (после мерджа?) |
Сообщ.
#132
,
|
|
|
Цитата Fester @ Как узнать, какие коммиты были сделаны непосредственно на бранче? Никак - гит не хранит информацию о том, в какой ветке был сделан коммит. |
Сообщ.
#133
,
|
|
|
А теперь хочу странного
Что будет, если один коммит разбить на 2, а потом слить? Идея такая: создать 2 бранча, в каждый из этих бранчей сделать черипик разных частей одного комита, а потом слить эти 2 бранча в один. |
Сообщ.
#134
,
|
|
|
Да скорее всего ничего не будет
смержатся и всё :-/ |
Сообщ.
#135
,
|
|
|
Вроде убедил шефа не заниматься херней
|