Size: a a a

2020 November 01

M

Magistr in DevOps
Там нет простого механизма для этого
источник

PK

Phil Kulin in DevOps
Тогда я не понимаю как делать pr. Каждый раз удалять форк и делать заново?
источник

PK

Phil Kulin in DevOps
У меня правка в три строки уже вылилась в историю на три воскресенья
источник

M

Magistr in DevOps
Phil Kulin
Тогда я не понимаю как делать pr. Каждый раз удалять форк и делать заново?
Я пока так делаю это быстрее чем  ребейзить и делать черрипик
источник

DB

Dmitry Burmistrov in DevOps
Гитхаб советует ребейз и форс-пуш
источник

PK

Phil Kulin in DevOps
Хорошо. Я не совсем понимаю порядок действий при ребейзе. Кого куда ребейз
источник

A

Alexander in DevOps
Phil Kulin
Хорошо. Я не совсем понимаю порядок действий при ребейзе. Кого куда ребейз
коммита A на коммит B.
источник

A

Alexander in DevOps
Phil Kulin
Хорошо. Я не совсем понимаю порядок действий при ребейзе. Кого куда ребейз
А, если серьезно, то открой man git-rebase, там даже ASCII-рисунки есть, что куда и какими командами ребейзится.
источник

A

Alexander in DevOps
Assume the following history exists and the current branch is "topic":

                    A---B---C topic
                   /
              D---E---F---G master

      From this point, the result of either of the following commands:

          git rebase master
          git rebase master topic

      would be:

                            A'--B'--C' topic
                           /
              D---E---F---G master
источник

A

Alexander in DevOps
Here is how you would transplant a topic branch based on one branch to another, to pretend that you forked the topic branch from the latter branch, using rebase --onto.

      First let’s assume your topic is based on branch next. For example, a feature developed in topic depends on some functionality which is found in next.

              o---o---o---o---o  master
                   \
                    o---o---o---o---o  next
                                     \
                                      o---o---o  topic

      We want to make topic forked from branch master; for example, because the functionality on which topic depends was merged into the more stable master branch. We want our tree to look like this:

              o---o---o---o---o  master
                  |            \
                  |             o'--o'--o'  topic
                   \
                    o---o---o---o---o  next

      We can get this using the following command:

          git rebase --onto master next topic
источник

PK

Phil Kulin in DevOps
Некстати. Но в тему Весь спич был вокруг этих трех строк:
https://github.com/borgbackup/borg/commit/5f23ff656a9e089b60878ece1e7e9224a6a8a86d

Я настоял и сделал в borg backup установку прав и владения для файов из STDIN
источник

PK

Phil Kulin in DevOps
Alexander
А, если серьезно, то открой man git-rebase, там даже ASCII-рисунки есть, что куда и какими командами ребейзится.
Я не понимаю как эти картинки соотнести с реальностью. Какие в жопу ветки? У меня две репы - его и моя. И обе ещё и на github.
источник

A

Alexander in DevOps
Phil Kulin
Я не понимаю как эти картинки соотнести с реальностью. Какие в жопу ветки? У меня две репы - его и моя. И обе ещё и на github.
Ты не имеешь прямого доступа к репам на гитхабе, работаешь ты всегда с локальной репой, а затем пушишь изменения в репу на гитхаб. Тебе нужено сделать ребейз своего мастера с коммита в апстриме, от которого ты отфоркнул свой мастер, на последний коммит мастера апстрима.
источник

p

pragus in DevOps
Alexander
Ты не имеешь прямого доступа к репам на гитхабе, работаешь ты всегда с локальной репой, а затем пушишь изменения в репу на гитхаб. Тебе нужено сделать ребейз своего мастера с коммита в апстриме, от которого ты отфоркнул свой мастер, на последний коммит мастера апстрима.
Иногда проще сделать свежий бранч от апстрима и чпикнуть из своего бранча ))
источник

p

pragus in DevOps
Потому что ребейз может быть болезненным :)
источник

N

Navern in DevOps
pragus
Потому что ребейз может быть болезненным :)
источник

DS

Dmitry Sergeev in DevOps
Phil Kulin
Тогда я не понимаю как делать pr. Каждый раз удалять форк и делать заново?
это же гит. Зачем тебе механизмы github чтобы синкать свой форк с оригиналом, когда это делается гитом без проблем
источник

DS

Dmitry Sergeev in DevOps
В гите можно хоть сколько удаленных реп добавлять, и мержить как угодно
источник

PK

Phil Kulin in DevOps
Alexander
Ты не имеешь прямого доступа к репам на гитхабе, работаешь ты всегда с локальной репой, а затем пушишь изменения в репу на гитхаб. Тебе нужено сделать ребейз своего мастера с коммита в апстриме, от которого ты отфоркнул свой мастер, на последний коммит мастера апстрима.
Так. Есть main/prog и my/prog - форк этого добра. На github. У меня на компе есть my/prog. Я хочу догнаться до последнего коммита main/prog ... и я вот... делаю что?
источник

AS

Aleksey Shirokikh in DevOps
Phil Kulin
Так. Есть main/prog и my/prog - форк этого добра. На github. У меня на компе есть my/prog. Я хочу догнаться до последнего коммита main/prog ... и я вот... делаю что?
както так
git remote add gh <initial_repo>
git remote add origin <my_repo>
git pull gh
источник