Поддържане на клон в крак с master

Имам отдалечено хранилище, което изтеглих и от което се разклонявам. Искам да поддържам новия клон актуален с промените, направени за master. Мисля за работния процес по-долу, има ли смисъл или има по-добри начини за това?

  1. Първоначално разклоняване и плащане:

    git checkout master

git pull

git checkout -b my_branch

  2. Направете малко работа в my_branch, след което периодично:

    git checkout master

git pull

git checkout my_branch

git merge master --no-ff

Повторете стъпка 2, ако е необходимо, с периодични натискания към дистанционното my_branch.

След това, когато сте готови за обратно сливане:

git checkout master

git merge my_branch --no-ff

Звучи добре?


git git-branch git-merge
person larryq    schedule 03.11.2013    source източник

Отговори (2)


arrow_upward
22
arrow_downward

Можете да опростите вашите команди:

1.

git fetch
git checkout -b my_branch origin/master

2.

git fetch
git merge origin/master

git fetch актуализира вашите отдалечени клонове, обикновено няма нужда да имате локално копие на клон, когато не планирате да работите в този клон.

Можете да пропуснете --no-ff след настройка на git config --global merge.ff false.

git help config казва:

   merge.ff
       By default, Git does not create an extra merge commit when merging
       a commit that is a descendant of the current commit. Instead, the
       tip of the current branch is fast-forwarded. When set to false,
       this variable tells Git to create an extra merge commit in such a
       case (equivalent to giving the --no-ff option from the command
       line). When set to only, only such fast-forward merges are allowed
       (equivalent to giving the --ff-only option from the command line).

Имайте предвид, че git pull е просто комбинация от git fetch и git merge.

Обикновено просто искате git pull --rebase, което по същество е git fetch плюс git rebase, и създава много по-чиста история.

Има ли причина за твоите "периодични напъни"? Ако никой друг не работи в същия клон, би било напълно добре, просто да натискате, след като приключите с всичко.

person michas    schedule 03.11.2013
comment
Благодаря за вашия (и на Кристоф) отговор. За да отговоря на въпроса ви, няма причина за периодичните натискания, освен да действа като резервно копие, в случай че кутията ми умре. И в случай, че някой иска кодът ми да свърши собствената си работа с-- не е съвсем вероятно, докато кодът ми не влезе в master, плюс извършването на повторно базиране на публичен клон може да доведе до проблеми, така че разбирам (но не съм сигурен защо точно .) - person larryq; 04.11.2013
comment
rebases са нож с две остриета. от една страна те често водят до много по-ясна история. от друга страна те създават напълно нови ангажименти с основно старото съдържание. Ако настоявате вашите ангажименти, някой друг може (теоретично) да изгради свои собствени промени върху тези ангажименти. Ако по-късно решите да пребазирате вашите ангажименти, вие основно обезсилвате старите ангажименти и всички промени се основават на тях. - Дори ако премахнете стария си клон, другият може да наложи своите промени и следователно също да наложи вашите стари промени, което ще доведе до дублиране на ангажименти и последваща бъркотия. :) - person michas; 04.11.2013
comment
Още веднъж много благодаря. Четох за git pull --rebase и не знам 100% какво ще се случи, ако го извикам, докато в момента съм в (да речем) my_branch. При това обстоятелство командата изтегля от дистанционното my_branch и след това пребазира срещу...кой клон? Не е майстор, който бих предположил, тъй като не го споменах никъде в командата. Така че трябва да се пребазира спрямо my_branch, което ми звучи малко странно, тъй като винаги съм пребазирал два отделни клона. Но предполагам, че е възможно и сега като се замисля защо не? - person larryq; 05.11.2013
comment
git pull и git pull --rebase работят с конфигурирания upstream (вижте git branch -vv). Обикновено локален клон my_branch ще проследи отдалечен клон origin/my_branch. Но преди да натиснете първия път, е напълно добре да проследите origin/master. git pull --rebase просто извлича текущата версия на клона нагоре по веригата, нулира вашия клон към тази версия и възпроизвежда всички ангажименти, които сте направили. Следователно вие водите до същите промени само въз основа на текущата версия на клона нагоре по веригата. - person michas; 05.11.2013
comment
можете да видите повторното базиране на работа с git tag old_state; git pull --rebase; gitk HEAD old_state. Като се има предвид, че вече сте извършили някои локални ангажименти и има нови ангажименти на upstream, трябва да видите както оригиналните си ангажименти, базирани на старата версия на upstream, така и повторно базираните ангажименти, базирани на текущата версия на upstream. - person michas; 05.11.2013

arrow_upward
14
arrow_downward

Бих посъветвал да използвате работен процес за пребазиране. Така че вместо да използвате git pull, трябва да използвате git pull --rebase.

Бих направил същото с клона за функции. Така че вместо да правя git merge master --no-ff, бих използвал git rebase master. Въпреки това, ако клонът на функцията е предназначен да бъде споделен с колеги по време на разработката, тогава е по-добре да обединявате главния клон периодично в клона на функцията.

Но за да бъда честен, работя в малък екип и ако трябва да работим върху клон на функции заедно и трябва да го актуализираме с master, тогава просто спираме работата си за кратък момент (и съобщаваме процеса ясно) , пребазиране на master и принудително натискане на клона на функцията. Но да, това не е мащабно за по-големи отбори. Въпреки това намирам за много по-удобно да работя с клон на функция, който е пребазиран на master, вместо да се налага да се занимавам със сливания от master.

Не забравяйте да прочетете това.

Въпроси за работен процес на Git и пребазиране срещу сливане

person Christoph    schedule 03.11.2013