Как двигаться туда, откуда происходит ветка

Question

Я чувствую, что мне не хватает чего-то простого в Git, но есть ли способ переместиться туда, откуда происходит ветка? Я очень часто сталкиваюсь со сценарием, в котором я создаю ветку компонентов вне мастера, работаю над ней в течение нескольких дней, а затем продолжаю нажимать, мне нужно убедиться, что любые изменения, которые были добавлены в мастер, должны быть объединены /перебазировал на мою ветку. Это, кажется, делает мою ветвь очень грязной. Я мог бы предположить, что мог бы просто изменить, откуда происходит ветвь, туда, где сейчас находится мастер, как если бы я только что создал ветку в первую очередь (но, очевидно, мне нужно было бы обрабатывать любые возникающие конфликты). Есть ли способ сделать этот или какой-то другой процесс для поддержания чистоты моей ветки?

Я надеюсь, что смогу переключиться с:

a--b--d--f
    \
     c--e--g

на

a--b--d--f
          \
           c--e--g

Редактировать: Недавно, чтобы подражать этому, я работал над временными ветвями, когда моя работа будет завершена, я создам новую ветвь, переместу все коммиты в это, перекомпилирую их все и нажму. Это не очень хорошо работает, если проверка запроса на получение ответа занимает некоторое время. Я также недавно попытался сделать git pull --rebase upstream master, а затем объединить мастер в ветку. Это добавило к моей ветке тонны других людей. Я думаю, что слияние все испортило, но я не понял, пока не нажал и не проверил запрос на извлечение.

Answer 1

То, что вы описываете , это перебазирование. Вы просто делаете это в неправильном направлении. Допустим, master баллов за фиксацию f и your-branch баллов за g.

a---b---d---f  ← master
     \
      c---e---g  ← your-branch

Чтобы взять ветку и начать ее с коммита f, вы должныребаз your-branch на master. Соответствующая команда:

git rebase master your-branch

Сначала Git проверит ветку, указанную в качестве второго аргумента (здесь your-branch). Таким образом, вы можете опустить второй аргумент, если вы уже отметили эту ветвь.

Первый аргумент будет использоваться для определения базового коммита, который в данном примере равен b. Git будет использовать первого общего предка между предоставленной вами веткой и выбранной вами веткой.

Если вы не указали --onto, Git снова будет использовать первый аргумент для определения новой базы. В данном случае это коммит f. Результат:

a---b---d---f  ← master
             \
              c'--e'--g' ← your-branch

Просто имейте в виду, что хеши коммитов изменятся, поскольку у вас, по сути, есть новые коммиты. Я пометил новые коммиты простыми числами (').

---

Я также недавно пытался сделать git pull --rebase upstream master, а затем объединить мастер с веткой.

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