| Версия для печати
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум на Исходниках.RU > Version Control > Как работают с git'ом? |
| Автор: Fester 16.02.17, 08:02 |
| Не понимаю вообще! Это какое-то говнище просто. Короче говоря, есть довольно большая задача. Седеллал для нее отдельный бранч. Делаю, комичу. Теперь хочу синхронизировать с мастером, но пока что в мои планы не входит комитить в мастер. Т.е. я хочу взять актуальную версию мастера с замерджить ее в свой бранч. Как, черт побори (тут используются другие слова), это сделать?  |
| Автор: Flex Ferrum 16.02.17, 08:07 |
| <{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}> git checkout master git pull --rebase git checkout your_branch git rebase master или <{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}> git fetch git rebase origin/master Вот здесь подробнее. Если работаешь с этим добром под виндой - ставь TortuiseGit, выбираешь там (в контекстной менюшке эксплорера) команду rebase и в открывшимся диалоге выбираешь ветку, на которую будешь перебазироваться. Добавлено А вообще матюги при начале работы с git'ом - дело обычное. Непривычная у него модель ведения репозитория. Но потом, вроде, проникаешься. |
| Автор: Koss 16.02.17, 08:26 |
| консоль галимая |
| Автор: Fester 16.02.17, 08:37 |
| Толи я не понял, толи это не совсем то. Я хочу сделать так:  branch.jpg (, : 1188)
Добавлено Может это и подробнее, но почему там стрелки все в обратном направлении? Я из этих картинок нихрена не понял Хрен поймешь, в каком направлении развиваются мастер и бранчи  |
| Автор: Flex Ferrum 16.02.17, 08:53 |
| Ты не понял. Это именно то. Смотри, ты в какой-то момент отбранчевался и начинаешь пилить свой мегафункционал. Пилишь-пилишь, коммитишь в свой бранч. master за это время уже уехал. У тебя естественное желание - подсосать всё из мастера и накатить "сверху" свои коммиты. Для этого ты делаешь следующее: 1. Обновляешь свой локальный мастер: <{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}> git checkout master git pull --rebase Таким образом в твоём локальном мастере оказываются все коммиты с сервера. 2. Перебазируешь свою ветку на новый мастер: <{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}> git checkout your_branch git rebase master То есть переключаешься обратно на свою ветку и ребейзишь её на актуальный мастер. git при этом делает своеобразный merge - забирает коммиты из свежего (локального) мастера и пытается накатить сверху твои коммиты. Может получиться не для всего. В этом случае возникнут конфликты, которые он предложит тебе отрезолвить. Есть другой вариант (применяется у нас в силу определённых обстоятельств непреодолимой силы в виде тимлида): 1. Переключаешься на мастер. 2. Ребейзишься 3. Отрезаешь от него новую ветку типа your_branch_new 4. Переключаешься на неё 5. Мерджишь (git merge) в эту новую ветку свою старую ветку. 6. Профит - получаешь нужное тебе объединение. Чтобы не придумывать новые имена, можешь старую предварительно переименовать в your_branch_old, отрезать новую с привычным именем, а старую (после мерджа) удалять. |
| Автор: ^D^ima 16.02.17, 09:11 |
| Flex Ferrum и что, git всегда корректно сам объеденияет коды? Если в мастере код поменяли местами(по тексту перенесли в другое место) он это поймет? |
| Автор: Flex Ferrum 16.02.17, 09:23 |
| Цитата ^D^ima @ Flex Ferrum и что, git всегда корректно сам объеденияет коды? Если в мастере код поменяли местами(по тексту перенесли в другое место) он это поймет? Ну, не всегда сам, не всегда корректно, но в целом да, с задачей справляется. |
| Автор: Fester 16.02.17, 09:31 |
| Цитата Flex Ferrum @ То есть переключаешься обратно на свою ветку и ребейзишь её на актуальный мастер. &)$ Какой такой "локальный мастер"? Какой "новый мастер"? Еще какой-то "актуальный мастер". У меня один мастер и один бранч. Что из этих трех мастеров - мастер, а что бранч? Накой хрен мне столько всякой бесполезной шняги? Уши оборвать этому Торвальдсу!  Цитата Flex Ferrum @ 1. Переключаешься на мастер. 2. Ребейзишься 3. Отрезаешь от него новую ветку типа your_branch_new 4. Переключаешься на неё 5. Мерджишь (git merge) в эту новую ветку свою старую ветку. 6. Профит - получаешь нужное тебе объединение. Почему все тащатся с этого говна? |
| Автор: kosten 16.02.17, 09:36 |
| Модно же ) |
| Автор: Flex Ferrum 16.02.17, 09:38 |
| Цитата Fester @ Какой такой "локальный мастер"? Какой "новый мастер"? Еще какой-то "актуальный мастер". У меня один мастер и один бранч. Что из этих трех мастеров - мастер, а что бранч? Накой хрен мне столько всякой бесполезной шняги? Уши оборвать этому Торвальдсу! Я думаю, тебе стоит начать с того, чтобы почитать - что такое git и как он работает.  |
| Автор: OpenGL 16.02.17, 09:39 |
| Видимо, такова судьба всех продуктов Торвальдса |
| Автор: Flex Ferrum 16.02.17, 09:43 |
| Просто эта система контроля версий принципиально отличается от тех, с которыми ты, видимо, привык работать до этого. Она построена не на "традиционной" клиент-серверной архитектуре, где есть выделенный сервер, а у пользователей - локальный снимок, с которым они работают. git - это чисто распределённая система равноправных репозиториев, которые определённым образом можно синхронизировать. И в этой системе git server - это просто ещё одна копия репозитория, в которую можно заливать данные. При этом у всех пользователей - свои, локальные, полноценные копии. Поэтому я и говорю, что есть "локальный мастер" (версия master-ветки в репозитории на твоём диске), а есть master в репозитории на сервере. |
| Автор: applegame 16.02.17, 09:45 |
| Гит этим славится. Он очень недружелюбен к юзверям. Чтобы полноценно работать с гитом нужно тщательно изучить принципы его работы. Вместо того чтобы заниматься делом, тебе приходится ковырятся в гайдах, писать на форумах, по сто раз клонировать удаленную репу. Торвальдс сделал систему заточенную под его собственные нужды, то бишь разработка ядра линупса, а хомячки дружно подхватили и сделали его де-факто стандартом. Пичаль, бида. |
| Автор: Flex Ferrum 16.02.17, 09:46 |
| Что-то этих хомячков подозрительно много. А публичные гит-сервера типа GitHub, GitLab, BitBucket и прочие, растут и множатся, как грибы после дождя. |
| Автор: applegame 16.02.17, 09:47 |
| Цитата Flex Ferrum @ Mercurial работает на тех же принципах, что и Git, но при этом не требует долгого и вдумчивого курения мануалов для относительно простых операций. Так что это не оправдание. Просто эта система контроля версий принципиально отличается от тех, с которыми ты, видимо, привык работать до этого. Она построена не на "традиционной" клиент-серверной архитектуре, где есть выделенный сервер, а у пользователей - локальный снимок, с которым они работают. git - это чисто распределённая система равноправных репозиториев, которые определённым образом можно синхронизировать. И в этой системе git server - это просто ещё одна копия репозитория, в которую можно заливать данные. При этом у всех пользователей - свои, локальные, полноценные копии. Поэтому я и говорю, что есть "локальный мастер" (версия master-ветки в репозитории на твоём диске), а есть master в репозитории на сервере. |
| Автор: Fester 16.02.17, 09:47 |
| Лучше бы TFS было бы модно Цитата Flex Ferrum @ Я думаю, тебе стоит начать с того, чтобы почитать - что такое git и как он работает. Так я почитал И сайтец (git-scm.com) видел... там же все череж допу описано. Они вот даже коммиты обозначают в противоположную сторону (от нового к старому).Ну и лирическое - нахрена пользоваться системой, в которой сначала надо постигнуть какую-то философию по ее использованию?  |
| Автор: negram 16.02.17, 09:48 |
| Цитата Fester @ Эта-эта, полегче Какой такой "локальный мастер"? Какой "новый мастер"? Еще какой-то "актуальный мастер". У меня один мастер и один бранч. Что из этих трех мастеров - мастер, а что бранч? Накой хрен мне столько всякой бесполезной шняги?  Да, мастер -- это, в принципе, такой же равноправный бранч, как и все остальные. |
| Автор: Flex Ferrum 16.02.17, 09:49 |
| Свят-свят-свят... Цитата Fester @ Ну и лирическое - нахрена пользоваться системой, в которой сначала надо постигнуть какую-то философию по ее использованию? Философию надо постигать в любом случае, если хочешь пользоваться эффективно. А твоём случае просто необходимо понять отличия от "традиционных" репозиториев. |
| Автор: applegame 16.02.17, 09:49 |
| Подозрительно? Ничего подозрительного, их господь бог - Торвальдс. А он человек весьма талантливый, если не сказать гениальный и харизма у него серьезная во всех смыслах. |
| Автор: Flex Ferrum 16.02.17, 09:50 |
| Цитата applegame @ Подозрительно? Ничего подозрительного, их господь бог - Торвальдс. А он человек весьма талантливый, если не сказать гениальный и харизма у него серьезная во всех смыслах. Ну вот не надо. Уверен, что процентов 80 пользователей git'а и знать не знают, что его Торвальдс написал. |
| Автор: Fester 16.02.17, 09:50 |
| Цитата Flex Ferrum @ git - это чисто распределённая система равноправных репозиториев, которые определённым образом можно синхронизировать. И в этой системе git server - это просто ещё одна копия репозитория, в которую можно заливать данные. При этом у всех пользователей - свои, локальные, полноценные копии. Поэтому я и говорю, что есть "локальный мастер" (версия master-ветки в репозитории на твоём диске), а есть master в репозитории на сервере. Это я уже понял Но как это знание помогает в мердже/ребейзе итд? |
| Автор: applegame 16.02.17, 09:51 |
| Цитата Flex Ferrum @ Об этом не знают разве только те пользователи, которые даже на знают, что они пользуются Git-ом. Ну вот не надо. Уверен, что процентов 80 пользователей git'а и знать не знают, что его Торвальдс написал. |
| Автор: Flex Ferrum 16.02.17, 09:52 |
| Просто даёт понимание, что, откуда и куда перемещается. Собственно, я начинал пользоваться гитом с TortuiseGit, поэтому каких-то особых проблем не испытывал. Потом походу дела разобрался и с "философией". |
| Автор: applegame 16.02.17, 09:53 |
| Цитата Flex Ferrum @ Как я уже писал выше. Mercurial - это тот же Git, но куда более интуитивный и понятный. "нетрадиционность" - не оправдание для всякого говна. А твоём случае просто необходимо понять отличия от "традиционных" репозиториев. |
| Автор: Fester 16.02.17, 09:57 |
| Так оно везде так И что из этого следует?Хум хау По-мне, так TFS - это просто, удобно и надежно. Правда дорого  Цитата Flex Ferrum @ Философию надо постигать в любом случае, если хочешь пользоваться эффективно. А твоём случае просто необходимо понять отличия от "традиционных" репозиториев. Вот ничего нетрадиционного я в этих репозиториях в упор не вижу. Ну есть на каждой машине свой (или даже несколько). И что? Успех гита опуславливается наличием бесплатного гитхаба. Просто никому раньше не приходило в голову сделать бесплатный хостинг на, скажем, сабвержине. ИМХО. |
| Автор: negram 16.02.17, 09:57 |
| запомни пару простых комманд: commit -- закоммитить merge <brunch> -- замержить pull - стянуть данные с сервера push - отправить на сервер checkout - переключиться на ветку Всё! Шли к чёртовой бабушке всех, кто рассказывает про всякие rebase. Вот этого хватит на большенство задач даже после прохождения "первого знакомства" |
| Автор: Flex Ferrum 16.02.17, 09:58 |
| И тормозно. А если TFS Git - так ещё и глюкаво... Добавлено Цитата negram @ Шли к чёртовой бабушке всех, кто рассказывает про всякие rebase. Вот этого хватит на большенство задач даже после прохождения "первого знакомства" Ну я пошёл, что-ли... |
| Автор: Fester 16.02.17, 09:59 |
| Цитата Flex Ferrum @ Собственно, я начинал пользоваться гитом с TortuiseGit, поэтому каких-то особых проблем не испытывал. Потом походу дела разобрался и с "философией". Я тоже с TortuiseGit. И вся эта распределенная "философия" понятна. Но вот что и куда мержится... и по каким таким неведомым правилам - это темный лес  |
| Автор: negram 16.02.17, 10:01 |
| Цитата Fester @ Ошибаешься, причём очень сильно. Популярность гиту пришла гораздо раньше появления гитхаба.Успех гита опуславливается наличием бесплатного гитхаба. Просто никому раньше не приходило в голову сделать бесплатный хостинг на, скажем, сабвержине. ИМХО. И на тот момент был уже бесплатный хостинг SVN - от гугла (который со временем помер), был и Sourceforge, про который уже редко вспоминают. Добавлено Цитата Flex Ferrum @ Цитата negram @ Шли к чёртовой бабушке всех, кто рассказывает про всякие rebase. Вот этого хватит на большенство задач даже после прохождения "первого знакомства" Ну я пошёл, что-ли... Не, ну правда, зачем ты начал про rebase человеку, который только-только в гит пришел? Я rebase раз в месяц делаю, и то не каждый -- про эту команду можно первые полгода даже не догадываться.  |
| Автор: OpenGL 16.02.17, 10:03 |
| Вот мне тоже так кажется - гитхаб весьма удобен (по-моему самый удобный из альтернатив), и поддерживает только гит. Так что если выбрал ео в качестве площадки, придётся либо кушать кактус в виде гита, либо использовать костыли для более вменяемой системы вроде hg-git, что тоже особой радости не доставляет. |
| Автор: negram 16.02.17, 10:04 |
| git merge <другая ветка> Мержит "другая ветка" в текущую. |
| Автор: Fester 16.02.17, 10:04 |
| Не согласен TFS - вполне себе шустро работает.Не знаю такого И как мне этими командами сделать то, что я нарисовал в посте Как работают с git'ом? (сообщение #3707209)? Добавлено Ну вот у меня есть мастер, с котого я неделю назад ответвил бранч. Иду в папку с бранчем, говорю "merge" в окошке выбираю "from master" клацаю "ОК" .... "you are up to date" и нихрена не мержится и не переносится из мастера. бранч остается без изменений. |
| Автор: applegame 16.02.17, 10:14 |
| Цитата OpenGL @ Я сижу на битбакете, он немного проигрывает гитхабу в функциональности, зато можно бесплатно пять приватных реп сделать, на гитхабе, ЕМНИП, бесплатно, только открытые репы. Вот мне тоже так кажется - гитхаб весьма удобен (по-моему самый удобный из альтернатив), и поддерживает только гит. |
| Автор: negram 16.02.17, 10:14 |
| Цитата Fester @ А в мастере есть изменения? я так понял, мастер в твоей схеме -- это то, что на сервере? Тогда:Иду в папку с бранчем, говорю "merge" в окошке выбираю "from master" клацаю "ОК" .... "you are up to date" и нихрена не мержится и не переносится из мастера. бранч остается без изменений. Переключаешься на мастер, там `git pull' Возвращаешься в свою ветку, там `git merge master' Скрытый текст можно сразу git merge origin/master -- тогда изменения подтянуться из удалённого мастера, но путь это будет потом |
| Автор: Flex Ferrum 16.02.17, 10:16 |
| Автор: negram 16.02.17, 10:22 |
| Цитата Flex Ferrum @ Скрытый текст чорт, да просто я перед каждым общением с удалённой репой `git pull' делаю |
| Автор: Fester 16.02.17, 10:24 |
| да на сервере там все, в том числе и бранч мастер - это то, куда коммитят все. а в бранч коммичу только я. и то и другое пуллом отправляю на сервер и оно там каждую ночь билдится. Цитата negram @ Переключаешься на мастер, там `git pull' Возвращаешься в свою ветку, там `git merge master' Погоди Не так быстро, я записываю 1) захожу в папку с бранчем 2) switch -> master 3) pull 3.5) тут будут конфликты 4) switch -> branch 5) merge master 6) commit 7) push я все правильно понял? |
| Автор: Flex Ferrum 16.02.17, 10:26 |
| Да. Только пункта 3.5 не будет - если ты в свой (локальный) мастер ничего не коммитил. А ты, наверняка, не коммитил. Но будет пункт "5.5 тут будут конфликты". Добавлено И п. 6 не будет. merge сразу локальный коммит делает. |
| Автор: Fester 16.02.17, 10:28 |
| Ок, пойду эксперементировать Если что, то знайте, что меня убили коллеги  |
| Автор: Flex Ferrum 16.02.17, 10:29 |
| Правда, в результате всего этого действа у тебя будет так называет "Merge commit", в котором будет указано, с какой ветки ты мержился и какие конфликты были. Некоторым владельцам репозиториев такие коммиты не нравятся. Поэтому вместо merge и используется rebase. |
| Автор: negram 16.02.17, 10:49 |
 Вот |
| Автор: Flex Ferrum 16.02.17, 10:57 |
| negram, в этом есть определённая логика. rebase ты делаешь тогда, когда забираешь чужие коммиты к себе в ветку - ребейзишься на master, или на origin/master, или ещё куда (типа git pull --rebase). При этом всё делается аккуратно - все твои коммиты, сделанные с последней точки ветвления, пытаются накатиться поверх нового содержимого. А вот когда ты хочешь свою ветку затащить в master - ты уже делаешь merge. И вот чтобы не было merge-коммита ты сначала делаешь rebase своей ветке, а потом спокойно её мёржишь. |
| Автор: applegame 16.02.17, 11:36 |
| Говорят гитхаб научился делать ребейз автоматически прямо при мердже пулл-реквеста. |
| Автор: negram 16.02.17, 13:02 |
| Вот этого я понимать отказываюсь. Во-первых, этот коммит не враг, а друг: я всегда знаю какой коммит нужно откатить, если намержил чего-то не того, и из твоего поста видна одна лишь эстетическая составляющая "чтобы не было мерж-коммита" и логическая компонента выглядит притянутой за уши. Во-вторых, проглядывая историю ты всегда видишь этот эвент. Пусть это не всегда нужно, но лишней информацией это не будет. |
| Автор: Бобёр 16.02.17, 20:10 |
| Я обычно перед тем как "смерджить все свое локальное курево в мастер" делаю патч. Возможно я это уже где то писал. Т.е. делаю дифф в бинарном виде, применяю его на чистой ветке и все. Имеем супер патч, в один коммит. Не надо никаких "мердж коммитов" и т.п. смуты. делаем так: 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 живу, ну это небо и земля - особенно что касается скорости. |
| Автор: Flex Ferrum 16.02.17, 20:33 |
| Бобёр, ты ведь про git squash? Добавлено В смысле, про git squash для бедных... |
| Автор: Бобёр 16.02.17, 20:41 |
| Цитата git squash Мне скваш как то не понравился, есть шанс ошибиться, константу не ту поставить. Вообще патч в виде диффа бранчей, по мне так, будет потупее и понадёжнее. |
| Автор: Flex Ferrum 16.02.17, 20:55 |
| Цитата Бобёр @ Мне скваш как то не понравился, есть шанс ошибиться, константу не ту поставить. Вообще патч в виде диффа бранчей, по мне так, будет потупее и понадёжнее. У меня в этом случае чуть другая техника. Я перед мёрджем делаю git reset --soft до нужного коммита (с которого хочу схлопнуть), потом делаю новый коммит всего добра, и в итоге - merge. |
| Автор: Fester 16.02.17, 22:16 |
| Цитата Бобёр @ делаем так: 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. |
| Автор: Flex Ferrum 16.02.17, 22:24 |
| А за сколько действий в TFS ты можешь схлопнуть несколько коммитов в один (но жирный), который потом и замёржить? По факту в Git мердж делается двумя командами, которые тебе выше уже показали. |
| Автор: Бобёр 17.02.17, 05:15 |
| Цитата 7 (!!!) действий для одного мерджа Можно и за 6, только у нас в мастер коммитить нельзя. Цитата Млять, люди, это же не нормально! У меня все автоматизировано, так что не переживай Добавлено Цитата По факту в Git мердж делается двумя командами, которые тебе выше уже показали. Можно и одной, правда потом может быть чуть больно . |
| Автор: Fester 17.02.17, 08:00 |
| зачем? Мердж в TFS'е делается за пару кликов. Если хочешь замержить конкретные changeset'ы, то количество кликов увелисивается на количество changeset'ов + 1. Единственно, что не очень хорошо сделано - это поиск shelveset'ов... Можно вообще не заморачиваться, слить 2 папки BeyondCompare'ом и закомитить все Получится 1-2 действия включая pull и никакого мерджа  |
| Автор: Flex Ferrum 17.02.17, 08:04 |
| Затем, чтобы твои частые коммиты (а такое бывает, если работа растягивается надолго, и надо хранить промежуточные результаты где-нибудь в более надёжном месте, чем локальный диск) после мерджа в основую ветку выглядели как один, но жирный. Его и откатить, в случае чего, проще будет. |
| Автор: applegame 17.02.17, 08:59 |
| Цитата Flex Ferrum @ git reset --soft удаляет твою ветку с сохранинием измененных файлов? У меня в этом случае чуть другая техника. Я перед мёрджем делаю git reset --soft до нужного коммита (с которого хочу схлопнуть), потом делаю новый коммит всего добра, и в итоге - merge. |
| Автор: Flex Ferrum 17.02.17, 09:02 |
| Откатывает индекс, а файлы не трогает, да. |
| Автор: applegame 17.02.17, 09:05 |
| А с веткой что происходит? Цитата Flex Ferrum @ Кстати постоянно с таким сталкиваюсь, и где ты хранишь промежуточные результаты? Отдельный удаленый форк заводишь, который потом подчищаешь? а такое бывает, если работа растягивается надолго, и надо хранить промежуточные результаты где-нибудь в более надёжном месте, чем локальный диск |
| Автор: Flex Ferrum 17.02.17, 09:09 |
| applegame, пока не сделаешь git branch -d - ветка жива. А так, пушу ветку на сервер, а после мерджа - прибиваю. Ресет комнатам делается на локальной ветке перед мерджем. |
| Автор: Fester 17.02.17, 09:38 |
| Цитата Flex Ferrum @ Затем, чтобы твои частые коммиты (а такое бывает, если работа растягивается надолго, и надо хранить промежуточные результаты где-нибудь в более надёжном месте, чем локальный диск) после мерджа в основую ветку выглядели как один, но жирный. Его и откатить, в случае чего, проще будет. Мердж - это и есть один жирный коммит. Зачем какие-то танцы с бубном? |
| Автор: Flex Ferrum 17.02.17, 09:41 |
| Не знаю, как в TFS, а в гите после мерджа в ветке, в которую ты мерджишь, оказывается вся твоя история коммитов из той ветки, которую мерджишь. Сделал 100500 коммитов с комментариями "Build fix", "Fix typo", "Temporary Interface Rename" - все они окажутся в целевой ветке. Вот чтобы всю эту историю не тащить и делают squash. |
| Автор: Fester 17.02.17, 09:46 |
| Ну т.е. сам себе придумал проблему, потом решил ее и выставил это решение как плюс системы |
| Автор: Flex Ferrum 17.02.17, 09:47 |
| Цитата Fester @ Ну т.е. сам себе придумал проблему, потом решил ее и выставил это решение как плюс системы Это "не сам себе придумал проблему". Такая "проблема" имеет место быть у многих. Или ты хочешь сказать, что результаты месячной работы ты заливаешь на сервер одним коммитом? Что-то я сомневаюсь. |
| Автор: Fester 17.02.17, 10:09 |
| Проблема в том, что при мердже из одного бранча в другой переносит все комиты, а не делается одним коммитом. |
| Автор: Flex Ferrum 17.02.17, 10:24 |
| Цитата Fester @ Проблема в том, что при мердже из одного бранча в другой переносит все комиты, а не делается одним коммитом. Это не проблема. Это особенность. У каждого из подходов есть свои плюсы и минусы. |
| Автор: domencom 17.02.17, 16:23 |
| Если делается большая таска, то желательно пулиться с мастера часто, тогда конфликты будут маленькие, а не простыни, которые непонятно как резолвить. ИМХО. |
| Автор: Koss 17.02.17, 16:35 |
| А есть оконная версия этого говна? какой понт сидеть в консоли, и редакторы вызывать из консоли |
| Автор: Pavia 17.02.17, 17:37 |
| Git? Не знаю такого слова. Чёт я запутался. Что такое комет и что такое мердж? Как увидеть какие файлы обновятся? Как увидеть изменившиеся части? Как автоматизировать заплатки? - Как сделать автоматический прием заплаток? - Как получить заплатки от ведущей-ветки? Я правильно понимаю что эта технология предназначена для работы только с заплатками и сливать целиком файлы никак не выйдет так как существует 4 вида заплаток. 1) Разница между m3-m2 которую мы можем получить от мастера. 2) Разница между m3-m2 которую мы не можем получить от мастера. (сам термин мастер подразумевает, что такого не бывает) 3) Разница между b3-m2 которую мы можем принять 4) Разница между b3-m2 которую мы не можем принять. 5) Разница между m3-b2 которую мы можем отправить. Не понятно как это связано с версией программы если у каждого файла своя версия. И как отобрать те файлы в ветке которые мы сливаем? А сливаются ветки или файлы? Я к чему порядок какой сначала отбираем что слить или с начало сливаем а потом отсеиваем что нам не подходит? Или сначала надо дифы построить? |
| Автор: domencom 17.02.17, 20:21 |
| 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. Делаешь мердж реквест, чтобы ТЛ затянул в мастер или куда надо... Добавлено Понт в том чтобы понимать что делаешь)) |
| Автор: Астарот 20.02.17, 06:43 |
| Цитата Fester @ Какой такой "локальный мастер"? Какой "новый мастер"? Еще какой-то "актуальный мастер". У меня один мастер и один бранч. Что из этих трех мастеров - мастер, а что бранч? Накой хрен мне столько всякой бесполезной шняги? Уши оборвать этому Торвальдсу! Инструмент не изучил, но обрывать готов? Профи  Вот тут все есть, аж на русском: https://git-scm.com/book/ru/v1 |
| Автор: Serafim 21.02.17, 01:33 |
| Цитата Fester @ Короче говоря, есть довольно большая задача. Седеллал для нее отдельный бранч. Делаю, комичу. Теперь хочу синхронизировать с мастером, но пока что в мои планы не входит комитить в мастер. Т.е. я хочу взять актуальную версию мастера с замерджить ее в свой бранч. Как, черт побори (тут используются другие слова), это сделать? <{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}> git commit -m "Мои текущие правки" git pull origin master Этого достаточно. А то, вижу, Флекс там насоветовал финтов ушами. Изменения сольются с удалённой ветки мастер в твою текущую локальную. Если что-то поломается - откатываешься на коммит или просто сносишь всё до него. |
| Автор: kosten 21.02.17, 10:14 |
| Что вы наделали!? Я же из-за этой темы начал Git изучать. И уже один свой проект на 1С на него перевел. |
| Автор: OpenGL 21.02.17, 10:17 |
| Поставь TortoiseHG и не парься со всякой глупостью |
| Автор: kosten 21.02.17, 10:22 |
| ты не поверишь, из консоли норм все работает |
| Автор: Астарот 21.02.17, 12:13 |
| Цитата kosten @ Я же из-за этой темы начал Git изучать. И уже один свой проект на 1С на него перевел. А... как ты жил раньше? |
| Автор: kosten 21.02.17, 12:28 |
| Файлы датой в имени, встроенное хранилище 1С. |
| Автор: Serafim 21.02.17, 22:48 |
| 1С, наверное, должно было тебе всё сказать |
| Автор: A.I. 22.02.17, 04:01 |
| Скрытый текст |
| Автор: Астарот 22.02.17, 06:19 |
| Даже с ним можно жить по-разному |
| Автор: kosten 22.02.17, 06:24 |
| Сима, учись не предвзятому взгляду на вещи. |
| Автор: A.I. 22.02.17, 06:55 |
| В 8-й версии (от 8.2 и выше) можно делать классные вещи и натягивать на существующую базу. ERP система с учетом реалий РФ, если уметь готовить |
| Автор: Serafim 22.02.17, 10:04 |
| Невозможно вбрасывать смотря на вещи непредвзято |
| Автор: Flex Ferrum 22.02.17, 10:08 |
| А если в git переименовать ветку master в 'экстаз', то потом можно будет сливаться с гораздо бОльшим удовольствием. |
| Автор: A.I. 22.02.17, 10:09 |
| Возможно. Например сколько лет понадобилось для корректного отлова такого? <{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}> try { thisFunctionDoesNotEvenExist(); //вызов несуществующей функции } catch (\EngineException $e) { echo $e->getMessage(); } |
| Автор: Астарот 22.02.17, 15:50 |
| А оно на этапе трансляции, или что там у 1С, не отваливалось что ли? |
| Автор: Serafim 22.02.17, 17:53 |
| Судя по документации уже примерно 20 лет как отлавливается. Так что мимо, давай дальше.  для тех кто в танке В то время вышел php 4.01, где был set_error_handler, позволяющий отлавливать ошибки подобного рода. В районе 5ки появились исключения. В 7ке (около пары лет назад) ошибки заменили на инстанс Throwable исключения, так что появилась возможность отлавливать и обрабатывать фатальные ошибки в месте вызова через конструкции исключения, а не в дочернем асинхронном коллбеке. А т.к. фатальные ошибки всё же на то и фатальны, что являются альтернативой ошибок компиляции, после которых работа ПО практически невозможна. То и отлов данных ошибок в асинхронном колбеке - вполне корректен (так поставил свой вопрос A.I.). А возможность отлова подобных ошибок во время работы в месте возникновения - это лишь плюшка. Подключаешь ты, например, исходник на C++ внутрь пыха, а он тебе кидает исключение, не могу собрать его, а ты такой гасишь исключение и пишешь в логи "отлично, работаем дальше" Ну или запускаешь gcc, передавая управление уже туда...  Добавлено P.S. а за echo $e->getMessage(); в мире PHP принято убивать на месте, т.к. эхо является побочным эффектом, что нарушает не только стандарты PSR, но и разумность существования этого кода. Вменяемые люди используют для таких вещей PSR-3 реализации, например monolog. |
| Автор: domencom 23.02.17, 16:24 |
| Т.е. каждый раз, когда меняешь файл надо сохранять его с новой датой в названии? Это такая практика у разработчиков 1С или чисто твоя фишка?) |
| Автор: Mr.Delphist 23.02.17, 19:37 |
| Принимайте в секту. Я раньше балдел от Perforce, скрипел зубами от SVN, и просто выворачивался наизнанку от гита (особенно который MS встроила в TFS). А недавно... - Здравствуйте, меня зовут Mr.Delphist, и я храню свои pet-проекты в Git |
| Автор: Flex Ferrum 23.02.17, 20:22 |
| (присутствующие хором): Добрый вечер, Mr. Delphist! |
| Автор: kosten 24.02.17, 11:24 |
| Это чисто моя фишка. В 1С по дефолту конфигурация сохраняется одним файлом. Поэтому вечерком сохраняешь в файл с датой. |
| Автор: Астарот 24.02.17, 12:46 |
| Да все так хоть раз делали! |
| Автор: Serafim 24.02.17, 13:22 |
| Кроме Кости :trollface: |
| Автор: A.I. 27.02.17, 09:23 |
| Цитата Serafim @ Судя по документации уже примерно 20 лет как отлавливается. Так что мимо, давай дальше. именно undefined function безо всяких проверок типа callable стандартным try/catch? |
| Автор: Koss 04.03.17, 15:13 |
| чем смотреть изменения? У меня какая-то хрень раньше была в редакторе открывала, и можно было смотреть две колонки в чём разница |
| Автор: Da$aD 04.03.17, 17:29 |
| git diff :trollface: |
| Автор: Koss 04.03.17, 18:56 |
| винмерге я вспомнил. прще всего гитк написать и там будет. тока винмерге лучшы Добавлено git difftool HEAD HEAD~1 Добавлено зачем git diff нужен? он делает такую херню, что командную строку потом закрываешь |
| Автор: Fester 04.03.17, 21:19 |
| BeyondCompare. Ничего лучше я еще не видел. |
| Автор: Da$aD 05.03.17, 01:16 |
| И что с ним не так? |
| Автор: vot 05.03.17, 08:10 |
| Дык оно же платное... |
| Автор: Fester 05.03.17, 08:59 |
| Лучше заплатить деньги и пользоваться удобным продуктом, чем испытывать боль и унижение от какой-то бесплатной поделки. |
| Автор: Koss 05.03.17, 11:16 |
| а я запускаю и он у меня командную строку вешает. Куча говна вылазит на экран которое не прокрутишь ничо не сделаешь пока не закроешь кэмэдэ |
| Автор: Polinom2686 05.03.17, 11:57 |
| Цитата applegame @ Я сижу на битбакете, он немного проигрывает гитхабу в функциональности, зато можно бесплатно пять приватных реп сделать, на гитхабе, ЕМНИП, бесплатно, только открытые репы. Я тоже пользуюсь битбакетом. Там неограниченное количество приватных репов (бесплатно). Также можно создавать команды разработчиков. До 5 человек бесплатно, больше - за деньги. |
| Автор: OpenGL 05.03.17, 14:44 |
| Да этих утилит хоть попой жуй. Я Meld-ом пользуюсь, например. |
| Автор: Koss 05.03.17, 16:05 |
| я винмерге. |
| Автор: Бобёр 05.03.17, 17:38 |
| В intellij idea неплохо видно искаробки. |
| Автор: Koss 05.03.17, 19:52 |
| тогда зачем нужен git diff ? |
| Автор: Mr.Delphist 05.03.17, 19:58 |
| Помнится, мне его очень советовали в одном из стародавних проектов (причём со стороны Заказчика). Поставил, потыкал - и не понял, в чём восторги. Дефолтные диффы что перфорса, что тортойзов ничем не хуже. Разве если его с WinDiff сравнивать - но там минимальный функционал по определению, и апдейтов уж сколько лет нету Или надо какие-то особые условия, на которых диффы от BeyondCompare становятся кардинально читабельней тех же тортойзов? (возможность вкл-выкл сравнения witespace, посимвольная подсветка отличий в строке и т.п.) |
| Автор: Koss 05.03.17, 20:25 |
| год на проекте камиты не делал. завтра гит адд сделаю потом камит . |
| Автор: Fester 05.03.17, 21:28 |
| Цитата Mr.Delphist @ Или надо какие-то особые условия, на которых диффы от BeyondCompare становятся кардинально читабельней тех же тортойзов? Никаких особых условий. Цитата Mr.Delphist @ возможность вкл-выкл сравнения witespace, посимвольная подсветка отличий в строке и т.п. Жто все есть в BeyondCompare, плюс к этому возможность "ручного" сравнения, т.е. можешь сказать, что строка Х в правой части соответствует строке Y в левой - очень удобная функция. Плюс там хорошо реализована возможность разбиения измененного блока на строки и построчного мерджа. Также, очень часто бывает полезно редактировать текст "на лету". Удобный интерсейс, умеет сравнивать папки итд. Не знаю, возможно это сила привычки, но я действительно не видел ничего лучше... |
| Автор: Koss 06.03.17, 10:47 |
| а бывают конверторы в гит репозитерий? |
| Автор: OpenGL 06.03.17, 11:57 |
| git init |
| Автор: Koss 06.03.17, 13:00 |
| Ларин я не про это! Есть куча папок с называнием версии. от 1.101 до 1.236 и в каждом архиве изменения. |
| Автор: Serafim 06.03.17, 16:12 |
| +1 Хз просто зачем нужны остальные |
| Автор: vot 06.03.17, 17:51 |
| Если хочется сохранить историю, то можно заливать эти папки по очереди в рабочую папку и коммитить. Если история не нужна, то залить последнюю версию, и git init |
| Автор: Koss 06.03.17, 17:58 |
| кароч цикл написать, и запускать с параметрами Добавлено нет. история нужна |
| Автор: OpenGL 06.03.17, 18:41 |
| Затем, что не все пишут в идее Добавлено Тогда скрипт, по очереди кидающий изменения в репозиторий и вызывающий git commit |
| Автор: Koss 06.03.17, 18:51 |
| Я это итак знаю, Ларин! Врядли я готовую программу найду такую. Закоммитил сёдня исходник, который 2 года не коммитился. Неудобно вот что пишешь гитдиффтулл коммит1 коммит2 длинное название файла, и винмерге открывается. А шо эта проще нельзя сделать? |
| Автор: Serafim 06.03.17, 19:19 |
| Правильно, нафиг жабу, надо брать шторм и писать на православных языках  |
| Автор: A.I. 07.03.17, 03:18 |
| а что умеет шторм из православного энтерпрайза? |
| Автор: Бобёр 07.03.17, 03:34 |
| php Вообще у idea есть плагинчики для многих языков, для go например... я с ними правда по наслышке в основном знаком. |
| Автор: kosten 07.03.17, 03:45 |
| 1C? |
| Автор: OpenGL 07.03.17, 06:04 |
| Цитата Koss @ Неудобно вот что пишешь гитдиффтулл коммит1 коммит2 длинное название файла, и винмерге открывается. А шо эта проще нельзя сделать? Да это любая оболочка умеет. TortoiseGit и git extensions уж точно. Эти плагины только базовые возможности дают. По крайней мере я пробовал плагин для rust - оказалось, что он ничем не лучше Sublime. |
| Автор: Koss 07.03.17, 08:16 |
| я в принцессе гите тока изменения смотрю |
| Автор: Koss 07.03.17, 21:46 |
| А если я чото поделал на одном компе(создал ридми.тхт), сделал гит пуш , пришёл домой, сделал гид фетчь оригин, потом гит мерге оригин\мастер. у меня создался этот фаел. А как работать с одним и тем же файлом? как он сливает? |
| Автор: A.I. 09.03.17, 03:50 |
| Koss, на те туториал https://githowto.com/ru Я по нему начал фтыкать про гит |
| Автор: Астарот 09.03.17, 06:36 |
| Зачем это нужно, если есть ProGit? https://git-scm.com/book/ru/v1 |
| Автор: kosten 09.03.17, 07:33 |
| +1 к ссылке Астарота. Даже я разобрался. |
| Автор: Koss 09.03.17, 07:49 |
| A.I.? http://eax.me/git-commands/ вот лучше. я там всё понял Добавлено оказывается этот гит всегда был мне нужен! Добавлено как перейти по ссылке? |
| Автор: Астарот 09.03.17, 08:08 |
| Скромняга Ты даже в 1С разобрался, куда там гиту Добавлено Кликни по ней. |
| Автор: Koss 09.03.17, 08:14 |
| 1С: Гит |
| Автор: kosten 09.03.17, 08:22 |
| Пятница завтра. |
| Автор: Koss 09.03.17, 08:30 |
| хватит меня вербовать !!! |
| Автор: Fester 18.04.17, 12:46 |
| Снова проблема с гитом Как узнать, какие коммиты были сделаны непосредственно на бранче? Т.е. без учета коммитов из других бранчей (после мерджа?) |
| Автор: OpenGL 18.04.17, 13:03 |
| Никак - гит не хранит информацию о том, в какой ветке был сделан коммит. |
| Автор: Fester 19.04.17, 07:46 |
| А теперь хочу странного Что будет, если один коммит разбить на 2, а потом слить? Идея такая: создать 2 бранча, в каждый из этих бранчей сделать черипик разных частей одного комита, а потом слить эти 2 бранча в один. |
| Автор: negram 19.04.17, 08:38 |
Да скорее всего ничего не будет  смержатся и всё :-/ |
| Автор: Fester 19.04.17, 09:31 |
| Вроде убедил шефа не заниматься херней |