Комментарии 50
Ветка заканчивается специальным merge коммитом который говорит, что ветку нужно объединить с какой-то другой веткой. В merge коммите содержатся две ссылки на два коммита которые объединяются в одну ветку.
О_О А мужики то не знали…
git cat-file -p <hach>И увидеть, что у этого коммита два parent и одно tree
https://git-scm.com/docs/git-merge
Там написано
...and record the result in a new commit along with the names of the two parent commits and a log message from the user describing the changes…
Ты наверное что-то путаешь и думаешь что merge commit создается только если были конфликты.
Убедись сам
Такое может происходить часто только если ты работаешь в команде один и выполняешь задачи последовательно по одной за раз. В таком случаи вообще нет особого смысла создавать ветки под задачи, можно просто делать коммиты в мастер ветку.
1) Твое утверждение — любой мердж заканчивается мердж коммитом.
2) Мое утверждение — мердж коммит нужен не во всех случаях.
3) Дальше я привожу пример мерджа двух веток, который не заканчивается мердж коммитом.
4) Твое утверждение — это не мердж это перемещение коммитов.
Мне кажется, ты просто не хочешь признавать ошибку, даже если тебе приводят пример, где твое утверждение неправильно.
В той же официальной документации явно, отдельным разделом, описан fast-forward, при котором мерж-коммита не бывает.
Вот именно что отдельным разделом.
… внутри документации на git merge, ага.
А что по мне, так именно в этой статье рассматривать другие варианты воде fast-forward merge было не обязательно.
… хотя они на практике встречаются весьма часто?
Дело не в том как часто это происходит а в том, что это можно было и не описывать в этой статье, для понимания что такое git merge первой схемы было достаточно.
Если описать все что есть в git, то получиться еще одна книга Pro Git, в которой очень много информации и вопрос, а что с этим со всем делать остается открытым после ее прочтения.
Если ты работаешь в команде один, и делаешь задачи последовательно, то такое у тебя получается постоянно.
… если работаешь не один, но не хочешь иметь мерж-коммиты (потому что они затрудняют чтение истории) — то тоже.
Пойнт-то как раз в том, что надо понимать, откуда и зачем берутся мерж-коммиты, как их получить и как их избежать.
Если описать все что есть в git, то получиться еще одна книга Pro Git, в которой очень много информации и вопрос, а что с этим со всем делать остается открытым после ее прочтения.
Ну, у меня вот после прочтения Pro Git вопросов "что делать" не оставалось.
Пойнт-то как раз в том, что надо понимать, откуда и зачем берутся мерж-коммиты, как их получить и как их избежать.Вообще ничего плохого в merge commit нету. При работе в команде их не избежать. Но ты мне напомнил про одну важную вещь о которой стоит написать более явно.
Вообще ничего плохого в merge commit нету.
… пока вам не надо ветку разбирать, ребейзить, черрипикать и так далее.
При работе в команде их не избежать.
Но можно радикально уменьшить их число.
… пока вам не надо ветку разбирать, ребейзить, черрипикать и так далее.Это наверное лучше вообще не делать.
Но можно радикально уменьшить их число.Что ты предлагаешь для этого сделать?
Это наверное лучше вообще не делать.
Почему это "лучше не делать"? Вам никогда не надо разбираться, какое изменение все сломало или починило? Переносить фиксы между версиями?
Что ты предлагаешь для этого сделать?
Например, pull --ff-only и pull --rebase вместо обычного pull. Радикально уменьшает число мерж-коммитов при совместной работе в одной ветке. Соответственно, при работе командой над одной фичей в разных ветках — аналогично, ребейз вместо мержа. Более того, даже при вливании фичи в транк, если сделать ребейз фичи на транк, можно получить в худшем случае один мерж-коммит вместо двух (и больше), а в лучшем — ни одного.
Почему это «лучше не делать»? Вам никогда не надо разбираться, какое изменение все сломало или починило? Переносить фиксы между версиями?
Да, иногда если сразу не понятно по коду из-за чего что-то сломалось, то мне приходилось искать тот коммит который что-то сломал. Для этого вначале делается тест с помощью которого можно найти ту самую поломку. Или тест не делатся, а поломка проверяется в ручную. Потом код откатывается на прошлое состояние в котором все работало запускается тест. Дальше методом деления отрезка пополам находится тот коммит который все испортил. Смотрим что было в этом коммите. Дальше это фиксится с помощью нового коммита. Все просто. Переносить фиксы между версиями не надо. merge commit-ы абсолютно ничем не мешают. Фиксы не теряются, по новой их применять не надо. Вообще обычно до поисков конкретного коммита не доходит дело, обычно и так понятно в чем причина поломки.
Смотрим что было в этом коммите.
… а в этом коммите был мерж. В этот момент все и взрывается.
Переносить фиксы между версиями не надо.
Вам не надо, мне надо.
merge commit-ы абсолютно ничем не мешают.
Вам не мешают, мне мешают. Вы вот знаете (именно из головы, без справочника), как увидеть список коммитов только в вашей ветке, если в нее был сделан мерж? Т.е., A -> A1 -> A2 -> A3 -> (merge) -> A4 -> B?
Например, pull --ff-only и pull --rebase вместо обычного pull. Радикально уменьшает число мерж-коммитов при совместной работе в одной ветке.
Работать нескольким программистам в одной ветке как-то не правильно. Ни в одной из предложенных мною схем такого не происходит. Ветки как раз и были созданы для того, что бы программисты могли работать совместно и не мешать друг другу.
… а в этом коммите был мерж. В этот момент все и взрывается.
Такое может быть только если этот мерж имел конфликт и этот конфликт не правильно разрешили в ручную. Если делать git rebase, то все было бы точно так же. В этой ситуации там тоже возник бы конфликт, и его нужно было бы решать вручную, и его могли бы не правильно решить. Если конфликт разрешили не правильно и ошибка в мердж коммите, то нужно действовать точно так же как я описал выше. Это ничего не меняет.
Вам не надо, мне надо.
…
Вам не мешают, мне мешают.
По-моему вы сами себе жизнь усложняете. Представим ситуацию когда вы работаете в одной команде с теми кто делает мерж через git merge, а не через git rebace; git merge. Такие парни вам будут мешать (хотя я по прежнему не понимаю чем), а вы им ни чуть. Вам придется хейтить их и убеждать, что нужно делать так, как вы иначе вы сами не сможете нормально работать.
Вы вот знаете (именно из головы, без справочника), как увидеть список коммитов только в вашей ветке, если в нее был сделан мерж? Т.е., A -> A1 -> A2 -> A3 -> (merge) -> A4 -> B?
А зачем? Это же тоже коммит и он должен быть в истории. К тому же в конце ветки они говорят о том, что этим коммитом ветка завершилась. По моему очень наглядно и полезно.
Работать нескольким программистам в одной ветке как-то не правильно.
Неправильно — применять инструменты не по назначению.
Вот у меня (прямщаз) команда из трех людей, работающих над одной фичей. Один делает домен, один — сервисы поверх, третий — UI. Каждый делающий может поменять домен, поэтому по факту все друг от друга зависят. В среднем, за день код синхронизируется (в смысле, все приходят к одному мастеру) три-четыре раза.
Внимание, вопрос: чем ситуация "каждый сидит в feature/x и мержится с origin/feature/x" хуже ситуации "каждый сидит в feature/x-<devname> и мержится с origin/feature/x"?
программисты могли работать совместно и не мешать друг другу.
Эти два условия прекрасно выполняются: все трое работают совместно и не мешают друг другу.
Такое может быть только если этот мерж имел конфликт и этот конфликт не правильно разрешили в ручную
Совершенно не обязательно. Могло не быть конфликта (с точки зрения гита), а код сломался. Есть много способов этого достичь.
Это ничего не меняет.
Меняет. Мерж-коммит приносит изменения в десятках и сотнях файлов.
По-моему вы сами себе жизнь усложняете. Представим ситуацию
Если так рассуждать, то люди, которые пишут (и ожидают видеть) продуманные коммит-сообщения, тоже сами себе жизнь усложняют — а вдруг придется работать с людьми, которые не хотят писать нормальные коммит-сообщения?
А зачем? Это же тоже коммит и он должен быть в истории
Вы не понимаете задачи. Вот есть две ветки:
* 4cea0a2 (B) B2
* 42e644d B1
| * 4901c2c (A) A2
|/
* ba68671 A1
* 95d2b42 A1
> git log A
4901c2c A2
ba68671 A1
95d2b42 A1
> git log B
4cea0a2 B2
42e644d B1
ba68671 A1
95d2b42 A1Делаем git checkout A; git merge B. Теперь я хочу в логе увидеть следующее:
90d6bbe Merge branch 'B' into A
4901c2c A2
ba68671 A1
95d2b42 A1(в том числе, чтобы делать деление пополам, или просто откатиться на коммит до мержа). Но:
> git log A
90d6bbe Merge branch 'B' into A
4cea0a2 B2
4901c2c A2
42e644d B1
ba68671 A1
95d2b42 A1Видите мешанину? Я теперь вижу не только коммиты, которые были в "моей" ветке, но и коммиты из "другой", хотя для меня все они "сжаты" в мерж-коммит.
И да, я могу нагуглить параметр к git log, которы сделает так, как мне надо. Но мне это приходится каждый раз искать.
К тому же в конце ветки они говорят о том, что этим коммитом ветка завершилась.
Но нет. Помните, мы только что сделали git merge B? Так вот:
> git log B
4cea0a2 (B) B2
42e644d B1
ba68671 A1
95d2b42 A1Когда вы делаете merge, указатель "другой" ветки не двигается на мерж-коммит (и это очень правильно). Собственно, поэтому утверждение "ветка заканчивается мерж-коммитом" неверно не иногда, а практически всегда.
Вот вам дерево после мержа:
* 90d6bbe (A) Merge branch 'B' into A
|\
| * 4cea0a2 (B) B2
| * 42e644d B1
* | 4901c2c A2
|/
* ba68671 A1
* 95d2b42 A1Видите указатели веток?
Внимание, вопрос: чем ситуация «каждый сидит в feature/x и мержится с origin/feature/x» хуже ситуации «каждый сидит в feature/x-devname и мержится с origin/feature/x»?
Тем, что в такой ситуации они будут мещать друг другу. Например, один из них ошибся и запушил ошибку в эту ветку, другой обновили код из этой ветки у себя и скачали ошибку. Его локальная копия оказалась нерабочей. Он не сможет работать дальше пока не исправит код. Если исправлять начнут двое, то получат конфликт. Каждый раз, когда они будут обновлять у себя код, возможен конфликт, который нужно решать. А если бы они работали независимо, то конфликтов было бы не больше одного, когда каждый закончил бы свою часть работы. А если вы правильно распределите задачи, то конфликтов вообще не будет.
Совершенно не обязательно. Могло не быть конфликта (с точки зрения гита), а код сломался. Есть много способов этого достичь.
Приведите пример, когда такое происходит, когда каждый программист работает в ветке задачи, и не происходит при том способе, который описываете вы.
которые не хотят писать нормальные коммит-сообщения?
Ничего страшного, другие программисты все равно смогут работать по предложенным здесь схемам. В прочем люди бывают разные, это скорее недостаток людей, чем Git-а.
Когда вы делаете merge, указатель «другой» ветки не двигается на мерж-коммит (и это очень правильно). Собственно, поэтому утверждение «ветка заканчивается мерж-коммитом» неверно не иногда, а практически всегда.
Это чистое буквоедство. Я думаю, что мысль была понятна и без этих уточнений. Но специально для вас я могу немного переформулировать и написать, что не ветка обычно заканчивается, а работа над веткой обычно заканчивается.
Я не понял, чего вы хотите и почему вот такая схема вас не устраивает. По-моему, все так как надо.
* 90d6bbe (A) Merge branch 'B' into A
|\
| * 4cea0a2 (B) B2
| * 42e644d B1
* | 4901c2c A2
|/
* ba68671 A1
* 95d2b42 A1Вы все время пишите, что хотите чего-то, а получается все не так как вы хотите. При этом вы описываете нормальное поведение Git, а чего вы хотите вообще не понятно. Делайте так как написано в этой статье и у вас все будет получаться. По-моему, вы как раз из той категории людей которая прочитала книгу Pro Git, но не поняла, что с этим делать.
Если вам и правда так сильно не нравятся merge commit’ы, то вы могли бы сделать вот так.
git checkout A
git pull
git rebace B
git merge BИ тогда бы у вас все коммиты выстроились бы в одну линию.
A1-A1-B1-B2-A2
Будто бы они были сделаны в одной ветке. (При этому в одном из файлов коммиты у меня заребейзились не правильно.)
Если вам нужно что бы было
A1-A1-A2-B1-B2
То нужно сделать вот так
git checkout A
git pull
git checkout B
git pull
git rebace A
git checkout A
git merge BРаботая по такой схеме вы видимо вообще сможите обойтись без merge commt’ов. Но это ни, чем не лучше.
Еще вы пишите, что git log показывает не то, что вы хотите увидеть. Попробуйте представить работу с ветками не в плоскости как ее рисует git log, а в трехмерном пространстве. Как ветки отходят от общей стволовой master ветки, а потом возвращаются обратно. После этого должно стать понятнее что рисует git log.
Имхо, вы просто не разобрались с тем как работает git занимаетесь каким-то непотребством, и у вас поэтому что-то не получается, вы хотите, чтобы остальные работали как-то определенно, иначе у вас что-то не будет получаться еще больше и т.п.
Тем, что в такой ситуации они будут мещать друг другу.
… но не мешают.
Например, один из них ошибся и запушил ошибку в эту ветку, другой обновили код из этой ветки у себя и скачали ошибку.
Это ничем не отличается от "ошибся и запушил ошибку в фичеветку". Как, собственно, и все ваши рассуждения дальше.
Еще раз, нет никакой разницы между схемой feature/x-dev -> feature/x и feature/x -> origin/feature/x. В обоих случаях это выделенные ветки.
А если вы правильно распределите задачи, то конфликтов вообще не будет.
По постановке выше это просто невозможно.
Приведите пример, когда такое происходит, когда каждый программист работает в ветке задачи, и не происходит при том способе, который описываете вы.
А я говорил, что при моем способе не происходит конфликтов? Я говорил лишь то, что мерж-коммит может затруднить их расследование.
Я не понял, чего вы хотите
Оно и видно. Я хочу линейную и понятную историю.
Делайте так как написано в этой статье и у вас все будет получаться.
Вот как раз если делать, как в статье, то не получается. А если делать так, как я делаю, получается.
Если вам и правда так сильно не нравятся merge commit’ы, то вы могли бы сделать вот так.
Да, я знаю. Я про это уже написал несколькими комментами выше.
Еще вы пишите, что git log показывает не то, что вы хотите увидеть. [...] После этого должно стать понятнее что рисует git log.
Охохонюшки. Я понимаю, что рисует git log. И я хочу, чтобы он показал мне другое, не то, что он рисует по умолчанию. Что характерно, там для этого даже есть параметр, который делает ровно то, что мне надо.
вы хотите, чтобы остальные работали как-то определенно
А это вы, простите, откуда взяли? Я нигде не говорил, как должны работать другие.
Это ничем не отличается от «ошибся и запушил ошибку в фичеветку». Как, собственно, и все ваши рассуждения дальше.
Разница в том, что другие программисты работают в других ветках и если один из программистов запушит недописанный код в свою ветку задачи, этот код другим программистам никак не помешает. Они смогут делать и push/pull запросы, когда захотят и не будут мешать друг другу. А если они будут работать в одной ветке и начнут делать push и pull, то у них как раз начнут появляться лишние merge commit’ы, конфликты и т.п.
А это вы, простите, откуда взяли? Я нигде не говорил, как должны работать другие.
Выше вы говорили, что если другие программисты в вашей команде будут работать с merge commit, то сами вы не сможете работать нормально. Ведь merge commit'ы чем-то мешают. Мне кажется я понял в чем дело. Дело в том, что вы постоянно делаете ребейзы и путаетесь в каком направлении их делать. Поэтому некоторые ребейзы вызывают ошибки, как у меня в примере выше. И вам надо перемещать отдельные коммиты что бы их не было. Если делать обычный мердж, то такого не происходит вообще. Строки не меняются местами на одной строке не оказывается две разные строки кода.
Разница в том, что другие программисты работают в других ветках
… другие программисты и так работают в других ветках. Ветка feature/dev — своя в каждом репозитории. Пока явно не сделать push/pull, код в/из общей ветки не попадет.
Они смогут делать и push/pull запросы, когда захотят и не будут мешать друг другу.
Нет в гите пуш/пул-запросов. А push/pull-команды как раз влияют на соотношение локальной и удаленной ветки, как я и показываю выше.
А если они будут работать в одной ветке и начнут делать push и pull, то у них как раз начнут появляться лишние merge commit’ы, конфликты и т.п.
Петя работает в feature/x-petya. Вася работает в feature/x-vasya. Обе эти ветки отбранчеваны от feature/x. Петя делает коммит и мержит свою ветку в feature/x. Вася делает коммит и мержит свою ветку в feature/x. Сколько мерж-коммитов будет в feature/x?
А это именно предлагаемая вами схема.
Выше вы говорили, что если другие программисты в вашей команде будут работать с merge commit, то сами вы не сможете работать нормально.
Этого я тоже не говорил. Я всего лишь говорю, что merge commit усложняет анализ истории.
Дело в том, что вы постоянно делаете ребейзы и путаетесь в каком направлении их делать.
Диагноз по юзерпику? Не угадали.
Если делать обычный мердж, то такого не происходит вообще.
Если вы не видели семантического конфликта при мерже, то это еще не значит, что их не бывает.
Если вы не видели семантического конфликта при мерже, то это еще не значит, что их не бывает.В том-то и отличие от ребейзов, что гит либо сам делает мерж коммит и делает его правильно, либо говорит о конфликте и тогда его нужно разруливать вручную.
Сколько мерж-коммитов будет в feature/x?Один. Разве в этом есть что-то плохое?
А это именно предлагаемая вами схема.
В том-то и отличие от ребейзов
Нет. Если при ребейзе коммит не накатывается, гит переходит в режим мержа — сначала пытается применить указанную стратегию, затем вываливается в ручной режим.
гит либо сам делает мерж коммит и делает его правильно
Гит ничего не знает про семантические конфликты. Поэтому автоматический мерж-коммит, сделанный гитом, прекрасно может давать неработающий код.
Гит ничего не знает про семантические конфликты. Поэтому автоматический мерж-коммит, сделанный гитом, прекрасно может давать неработающий код.
Что вы называете семантическим конфликтом? Мердж коммиты на практике никогда не ломали код. А вот при ребейзах он может сломаться как я описывал выше.
Что вы называете семантическим конфликтом?
Тривиально же: был публичный класс A. В одной ветке добавили новый класс B: A. В другой ветке класс A переименовали в C. Конфликта при мерже не будет (откуда бы?). Но код компилироваться не будет.
Мердж коммиты на практике никогда не ломали код
На вашей практике.
А вот при ребейзах он может сломаться как я описывал выше.
Я, кстати, не нашел у вас примера, как может сломаться код (исключительно) при ребейзе.
Тривиально же: был публичный класс A. В одной ветке добавили новый класс B: A. В другой ветке класс A переименовали в C. Конфликта при мерже не будет (откуда бы?). Но код компилироваться не будет.
При ребейзе код сломается точно так же. Я не причин не использовать merge commit, а все ребейзить.
Я, кстати, не нашел у вас примера, как может сломаться код (исключительно) при ребейзе.
Имеем вот такую схему
| * 4cea0a2 (B) B2
| * 42e644d B1
* | 4901c2c A2
|/
* ba68671 A1
* 95d2b42 A1
Делаем вот так
git checkout A
git rebace B
git merge BПолучаем цепочку коммитов A1-A1-B1-B2-A2, но в коде есть ошибки. На одной строке оказалось две строчки кода. Если бы мы сделали мердж, то добавился бы мердж коммит и ошибок бы не было.
Если сделать вот так
git checkout B
git rebace A
git checkout A
git merge Bто получится другая цепочка коммитов A1-A1-A2-B1-B2 и в ней не будет такой ошибки в коде.
Кстати говоря, я тоже не вижу у вас примеров, когда ребейзы бы работали правильно, а мердж отработал бы неправильно. Хотя выше уже просил привести такой пример. И вы постоянно говорите о том, что в merge commit могут быть ошибки. А я говорю, что они тогда и в ребейзе были бы.
Нет. Если при ребейзе коммит не накатывается, гит переходит в режим мержа — сначала пытается применить указанную стратегию, затем вываливается в ручной режим.
Да, я знаю об этом. Имелось в виду что отличие в том, что merge commit либо проходит автоматически и не ломает код, либо переходит в ручной режим. А ребейз может пройти автоматически и сломать код при этом.
При ребейзе код сломается точно так же.
Да. Но не будет мерж-коммита.
Делаем вот так
git checkout A git rebace B git merge B
Вас не смущает, что это бессмысленная последовательность? После git rebase B у вас в A уже есть все коммиты из B, зачем делать git merge B?
Получаем цепочку коммитов A1-A1-B1-B2-A2, но в коде есть ошибки.
… а почему?
Если бы мы сделали мердж, то добавился бы мердж коммит и ошибок бы не было.
… а почему?
то получится другая цепочка коммитов A1-A1-A2-B1-B2 и в ней не будет такой ошибки в коде.
… или будет. Нет никакой гарантии.
Кстати говоря, я тоже не вижу у вас примеров, когда ребейзы бы работали правильно, а мердж отработал бы неправильно. Хотя выше уже просил привести такой пример.
А я и не говорю, что меня волнуют случаи, когда rebase даст "более правильный" код. Меня волнуют случаи, когда rebase позволит избежать мерж-коммита.
И вы постоянно говорите о том, что в merge commit могут быть ошибки. А я говорю, что они тогда и в ребейзе были бы.
Да, возможно были бы. Но они были бы в первом коммите ветки, т.е. в нашем изменении, а не в мерж-коммите, и было бы проще понять, что происходит.
Имелось в виду что отличие в том, что либо проходит автоматически и не ломает код, либо переходит в ручной режим.
Это неправда. Как уже говорилось выше, прошедший автоматически мерж прекрасно может сломать код.
А ребейз может пройти автоматически с сломать код при этом.
Да, может. Но это происходит не чаще, чем при мерже.
Вас не смущает, что это бессмысленная последовательность? После git rebase B у вас в A уже есть все коммиты из B, зачем делать git merge B?
Даже если этот мердж не делать, то код все равно сломается. Это ничего не меняет.
… а почему?
Потому, что последовательность комитов в итоге получается разная. Есть разница что куда ребейзить, а с мержем такой проблемы нет.
Да, может. Но это происходит не чаще, чем при мерже.
Я вам только что привел пример как мердж не ломает код, а ребейз ломает.
Есть разница что куда ребейзить, а с мержем такой проблемы нет.
То есть вы хотите сказать, что нет разницы между git checkout A; git merge B и git checkout B; git merge A?
Я вам только что привел пример как мердж не ломает код, а ребейз ломает.
Этот пример никак не доказывает, что это происходит чаще, чем обратное.
То есть вы хотите сказать, что нет разницы между git checkout A; git merge B и git checkout B; git merge A?
Нет, я хочу сказать не это. Есть разница что куда мержить. Я хочу сказать что в обоих случаях при мерже код не сломается. В отличии от ребейза.
Этот пример никак не доказывает, что это происходит чаще, чем обратное.
Тогда приведите хоть один такой пример. Я вас уже третий раз прошу это сделать. Вы же, наверное, понимаете, что мердж не меняет последовательности коммитов, а ребейз делает это и поэтому от него код может сломаться. Как же вы можите утверждать при этом что мердж и мердж коммиты ломают код так же часто как и ребейзы? Ребейз это вообще говоря не типичная операция git'а и злоупотреблять ей не стоит.
Я хочу сказать что в обоих случаях при мерже код не сломается.
Я бы не был так в этом уверен. Все зависит только от сложности конфликта.
Как же вы можите утверждать при этом что мердж и мердж коммиты ломают код так же часто как и ребейзы?
Это наблюдение из моей личной практики: ребейз ломает код не чаще, чем мерж.
Ребейз это вообще говоря не типичная операция git'а и злоупотреблять ей не стоит.
Злоупотреблять не стоит никакой операцией гита. Каждый инструмент надо применять по назначению.
Получаем цепочку коммитов A1-A1-B1-B2-A2, но в коде есть ошибки. На одной строке оказалось две строчки кода. Если бы мы сделали мердж, то добавился бы мердж коммит и ошибок бы не было.
На самом деле, покажите конкретные коммиты, мне уже интересно.
Не забывайте перезаписывать папку .git и файл 1.txt на те, что в архиве перед тем, как попробовать очередной вариант мержа или ребейза.
Не обязателен. Во-первых (и самых простых) бывает fast-forward, во-вторых, бывает rebase (правильно так делать или нет — вопрос отдельный).
Pull запрос можно сделать только из web интерфейса Git
я делаю через терминал
ссылка
github.com/github/hub — это надстройка на стандартным гитом, от гитхаба.
вот установка через пакетный менеджер apt
github.com/github/hub/issues/718#issuecomment-100411835
вот ссылка на документацию по hub
man page
я у себя сделал alias git=hub
пример
git checkout -b <new feature>
git commit <...>
git push origin <new feature>
git pull-request -b <куда делать pull request> -m <заголовок>
git pull --rebase origin branchБез нее, если у вас уже есть коммиты, то будет создан дополнительный мерж-коммит, загрязняющий лог. А с этой опцией гит попытается применить ваши коммиты поверх прилетевших
git init
git clone
git remote
git reset
git commit , ёМоё..
...
этими командами пользуюсь чаще всего, но их в списке не нашел, кстати из терминала работаю.
вот кажется, пишете статью…
теги, пуш\пул, конечно хорошо, но чтобы этим пользоваться — нужно клонировать\инициировать репозиторий… логическая цепочка быть должна.
Git на практике