Git запутался
 

Доброго времени суток!

После двух неудачных мерджей ветки перепутались, пытался исправить, гуглил и все превратилось в неведумую хрень. Вот

git reflog

5b4ea5d HEAD@{0}: checkout: moving from develop to 5b4ea5d
8422d4e HEAD@{1}: checkout: moving from feature/cluster-api to develop
5b4ea5d HEAD@{2}: checkout: moving from 8422d4ee13d8e770c1d5ed52f249d702ed26456e to feature/cluster-api
8422d4e HEAD@{3}: checkout: moving from 5b4ea5dccd210cd5227d92927f615e4dbda00a05 to 8422d4e
5b4ea5d HEAD@{4}: checkout: moving from master to 5b4ea5d
d0bad9d HEAD@{5}: reset: moving to HEAD^
5b4ea5d HEAD@{6}: reset: moving to 5b4ea5d
6421057 HEAD@{7}: checkout: moving from develop to master
8422d4e HEAD@{8}: pull: Merge made by the 'recursive' strategy.
6e1acdf HEAD@{9}: checkout: moving from master to develop
6421057 HEAD@{10}: checkout: moving from master to master
6421057 HEAD@{11}: checkout: moving from develop to master
6e1acdf HEAD@{12}: checkout: moving from master to develop
6421057 HEAD@{13}: merge develop: Merge made by the 'recursive' strategy.
cbb2270 HEAD@{14}: checkout: moving from develop to master
6e1acdf HEAD@{15}: merge feature/cluster-api: Merge made by the 'recursive' strategy.
8400734 HEAD@{16}: checkout: moving from feature/cluster-api to develop
5b4ea5d HEAD@{17}: commit: Cluster of vars

Собственно видно что я делал после 5b4ea5d... вопрос. как мне вернуть предыдущее состояние локальных и удаленных веток?:cray:

Тобишь мне нужно восстановить состояние всех веток на момент 5b4ea5d

Пофиксил, теперь все по человечьи))))

Вот тебе и польза от Collection - научишься гитом пользоваться :D

Да пора бы уже научится все разруливать))

Не буду создавать новую тему, спрошу по гиту тут.

Над проектом работает человек 10, все форкнулись от главной репы.

Вопрос, как мне подтянуть в свой репозиторий ветку другого разработчика?

Вспомнил как делал для upstream

Под виндой есть нюансы, надо демона запустить:
http://softtime.info/view/Git_%D0%BF...%D0%B4_Windows

Если же все хорошо и доступ к репозиторию есть, то делаем все прямо по родному мануалу:
http://git-scm.com/book/ru/ch2-5.html

Makarov,
Благодарю, но я сам допер выше))

git remote add <name> <url>
git fetch <name>

Зы
линь

Что то не пойму, как сделать по феншую а точнее gitflow.

У меня есть 5 - 6 веток, в каждой своя фича, мне понадобилось показать все вместе и пото продлжать разработку. Чтобы показать все вместе я сделал отдельную ветку и смерджил туда эти.

Как мне в каждую ветку теперь подтянуть все изменения??
Или нужно ветки заного создавать?


В итоге создал ветку новой фичи и пилю там..

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

Там в основном верстка, и некоторые странички хотят виджеты. А виджеты пилятся в отдельных ветках.

Там 2 виджета и несколько страничек. И все хотят их в любом состоянии, даже полурабочем)

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

Короче тут вопрос скорее такой:
Есть фича готовая и много не готовых.
Как внедрить готовую во все неготовые если они этого требует)

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

2. Фичи поедут в продакшн вместе. Тогда с точки зрения gitflow это одна фича. А для себя ты решаешь удобнее пилить в одной ветке или вагоне маленьких, которые мержишь в свою условную "большую фичеветку". Я для себя например люблю одну прямую ровную ветку из небольших коммитов, а в своем репозитории ничто не мешает пользоваться всякими revert и reset --mixed сколько душе угодно.
Вот если над веткой твоей "большой фичи" будет работать кто-то еще, тогда подход множества маленьких веток выигрывает, а если все локально - разницы не вижу

Скорее 2 вариант)

Готовая фича большая? На удаленном репозитории она есть, или только на твоем?

Я думаю тебя скорее всего спасет волшебная команда git cherry-pick, которая берет диапазон коммитов которые ты ей укажешь и применяет в текущую ветку. Еще можно использовать rebase -i, но с rebase у большинства проблемы сначала

А, ну если 2 вариант, то да, легче заново ветки посоздавать)

Я вот щас тебе лучше всю ситуацию обьясню, может что порекомендуешь

Тут просто смотри какое дело, глобааальный рефакторинг идет. Есть ужасный less файлик из почти 6000 строк, в котором все записано каскадом относительно body и многие элементы которые очень похожи пилятся заного или наследуют стили от подобных. И есть страницы, в этих страницах эти стили и применяются в различных местах.

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

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

есть 2 ветки, их нужно слить в одну так, чтобы в гите она показывалась как одна.

Как это сделать? черепикать или просто мердж но без флага --no-ff?

По всей ситуации влом думать, честно)

Правильно делать rebase в такой ситуации, но у rebase есть нюансы и в некоторых случаях он может навредить. Мне ща лень все расписывать, поэтому отсылаю к документации, где все реально хорошо написано и к статьям вроде этой:
http://habrahabr.ru/post/161009/
Rebase похоже на обобщение черри-пика, после которого черипикнутые коммиты удаляются

А вообще в гите можно многое сделать разными способами и получить один и тот же результат.

Подскажите, кто знает

Есть у меня сайт статики на гитхабе, в рамках которого добавил подмодуль гита angular-file-upload.

Как обновить подмодуль angular-file-upload на гитхабе?
На локальной машине я это сделал (взял пулл в рамках подмодуля), не понятно, как уведомить гитхаб.
А? вообще, желательно, чтобы гитхаб подхватывал HEAD подмодуля, а не commit-id.

Причина: сделали мне PR, его смеджил. На локальном хосте работает...

Решено

git submodule update --recursive --remote
git commit -m "msg"
git push origin

http://stackoverflow.com/a/18799234/5215084
http://blog.jacius.info/git-submodule-cheat-sheet/