Чем отличается master и origin master

Что такое origin / master в git по сравнению с origin master?

Я хотел добавить этот вопрос в качестве комментария к ответу @KevinBallard здесь в чем разница «origin master «против»origin/master», но мой комментарий был длинным.

или, может быть, это такой: origin/master является локальной копией реальной удаленной главной ветви, в которую был извлечен пульт (скопирован, т. е. просто перезаписаны), и мой местный филиал под названием master изменяется только тогда, когда я git merge origin/master (или git rebase … ). То есть: когда я git pull origin master оба мои локальные копии origin/master и master обновление/слился. Конечно предполагая, что в настоящее время я нахожусь в главной ветви (т. е. git checkout master мой последний заказ).

4 ответов

когда вы git pull (что я считаю злом, кто-нибудь еще?), он автоматически делает:

когда вы хотите перебазировать master, вы должны сделать:

экстракт git help pull :

точнее git pull работает git fetch с заданными параметрами и звонки git merge чтобы объединить извлеченные головки ветвей в настоящее бранч

/
именованная ветвь управляется автоматически git.

git fetch автоматическое обновление origin/master локальная ветвь, чтобы указать на последний коммит origin ПДУ master филиала.

если я нахожусь в ветке под названием topic, это можно ли просто написать ГИТ перебазирования мастер вместо git перебазирования происхождения/мастер?

или действительно есть две разные местные главные ветви?

Да, это две разные местные ветви. Они просто обычно указывают на одни и те же коммиты и разделяют общее дерево.

после извлечения git смотрит на вашу конфигурацию и по умолчанию пытается объединить или перебазировать вашу текущую ветку на ветку из origin С тем же именем.

в config вы можете указать, какая локальная ветвь будет перезагружена, на какой удаленной ветви-так что вы можете просто запустить git pull без дополнительных параметров.

отделения просто ссылки на точки фиксации. Теги также являются ссылками для фиксации точек, но ветви отличаются от теги потому что git в определенных ситуациях автоматически обновляет ссылки на ветви, чтобы указать на другую фиксацию. Эти автоматические обновления происходят, скажем, при создании новой точки фиксации ( git commit ), тогда ветка, которая нынешний глава обновляется для ссылки на вновь созданную точку фиксации.

обратите внимание, что локальная ветвь и удаленная ветвь, которая отслеживает, могут иметь разные имена.

также обратите внимание, что вы действительно фиксацию точки что ветка указывает на (вы можете сказать git merge ), а не сам филиал.

Источник

В чем разница между origin / master и origin master в Git?

7 ответов

Пример: тянуть за два шага

Поскольку origin/master является ветвью, вы можете объединить его. Вот два шага:

Затем вы можете отправить свои новые изменения в master обратно в origin :

Еще примеры

Итак, у нас есть это:

Пример (в местном филиале master ):

Возможно, удаленный бангалор продвинулся дальше, так как вы выполнили «выборку» или «извлечение».

Прежде чем перейти к различию, нам нужно понять, что означает origin в Git.

Теперь это происхождение или источник истины для вашего репозитория может иметь ветки, включая master или development, или вы называете это.

Теперь, взяв происхождение в контексте, мы можем легко понять следующие вещи.

Это обновит мою локальную главную ветку (на моем локальном компьютере), и все изменения будут доступны в удаленной главной ветке (т.е.

Теперь я хотел бы, чтобы мои изменения были объединены с моей локальной главной веткой, как я могу этого добиться?

git merge origin / master

Как мне обновить удаленную главную ветку со всеми локальными изменениями?

git push origin master

Эта команда говорит об отправке всех моих локальных изменений в origin (то есть в репозиторий (https: // github. com / mycode / git-awsomecode.git)) в главную ветку.

Я предлагаю объединить разработку и мастер с этой командой

Источник

Цикл разработки через Github

Разработка

Я расскажу о цикле разработки через Github, который я использую. Он был проверен в течении года на командах разного размера: 3 — 14 человек.

Существует 2 основных ветки: master и dev.

master — стабильная ветка, готовая к выкатыванию на production сервер в любой момент.

dev — ветка, над которой в данный момент работает команда.

Итак, в начале разработки master и dev ветки идентичны.

1. Когда программист начинает работу над новым дефектом / функционалом, он должен переключиться на ветку dev и получить ее последнюю версию.

2. К примеру, разработчик хочет начать исправлять дефект страницы аутентификации. Номер ошибки на Github — 1234. Разработчик должен создать новую ветку из dev

1234-bug-login это только пример. Первым словом должен быть номер дефекта, вторым — bug / feature, а дальше — описание проблемы.

3. Далее разработчик продолжает работу локально: делает изменения, коммиты и т.д. Commit-cообщения должны содержать номер ошибки и техническое описание

4. Итак, разработка окончена, и теперь необходимо отправить изменения на Github

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

И затем влить все изменения, которые произошли в dev ветке, в свою ветку (1234-bug-login)

5. Отлично! Ветка с решенными конфликтами в репозитории. Теперь разработчик делает Сreate Pull Request из 1234-bug-login в dev ветку при помощи Github. Так же необходимо разместить ссылку на задачу (#1234) в описании Pull Request.

6. Pull Request отправлен, любой разработчик может сделать code review, написать комментарии, уточнения и т.д.
Комментарии должны быть исправлены и отправлены на Github обычным способом. Pull Request обновится автоматически.

7. Иногда, исправления занимают некоторое время, и другие разработчики уже слили свои ветки с dev. В этом случае есть 2 варианта:

— кнопка Merge pull request на Github активна. Это означает, что изменения других разработчиков не конфликтуют с текущими изменениями, и ничего дополнительного делать не требуется.

— кнопка Merge pull request неактивна. Необходимо вернуться к пункту 4) и заново слить и отправить изменения из dev ветки в 1234-bug-login.

8. Отлично! Все изменения сделаны, и кто-то написал комментарий «merge it» в Pull Request. Пора нажимать кнопку Merge pull request, чтобы влить изменения 1234-bug-login в dev ветку.

Тестирование

9. Как только 1234-bug-login попадает в dev, Jenkins (система непрерывной интеграции) автоматически обновляет dev сервер из dev ветки. QA могут начинать тестировать и как итог подтвердить или переоткрыть задачу.

10. Если Pull Request вносит много изменений, разработчик может при помощи Jenkins загрузить свою ветку на qa сервер для проверки тестерами.

Релиз

11. Перед обновлением production сервера необходимо влить dev ветку в master. Для этого мы создаем Pull Request из dev в master при помощи Github и нажимаем Merge pull request, вот и все. При выполнении предыдущих пунктов, никаких конфликтов быть не будет.

12. Если регрессионное тестирование успешно закончено, можно обновлять production сервер, при этом берется последний пакет (тот, на котором проходило тестирование), и именно он устанавливается на production сервер.

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

Источник

Git. Коротко о главном

Cодержание:

4. Самые распространенные команды в Git;

5. Работа с историей;

7. Примеры ведения истории проекта;

Введение

Привет, Хабр! Меня зовут Егор, я занимаюсь разработкой мобильных приложений на Flutter. Это моя первая работа в сфере IT, и как подобает начинающим, я столкнулся с проблемой изучения систем контроля версий. В данной публикации я хочу поделиться приобретенными знаниями и подробно рассмотреть одну из таких систем, а именно Git. Итак, начнем.

“Whoah, I’ve just read this quick tuto about git and oh my god it is cool. I feel now super comfortable using it, and I’m not afraid at all to break something.” — said no one ever.

Не так страшен чёрт, как его малюют. Хотя, как мне кажется, это не касается Git. Так или иначе многие сталкиваются с необходимостью обучиться грамотной работе с этим инструментом. Несмотря на обилие информации и туториалов, это задача является не самой тривиальной. Исходя из своего опыта, могу сделать вывод: необходимо изучить самые разные ресурсы, прежде чем наступит понимание.

Тем не менее, я бы хотел дополнить просторы интернета очередной статьей о Git. Постараюсь изложить все таким образом, как если бы у меня была возможность объяснить все самому себе из прошлого. Как следует из названия, я расскажу о Git очень коротко; а точнее о возможностях, которые он нам предоставляет.

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

Системы контроля версий можно разделить на две группы:

1. Централизованные системы контроля версий;

2. Распределенные системы контроля версий.

Git является распределенной системой контроля версий, разработанной Линусом Торвальдсом для управления разработкой ядра Linux. На данный момент Git завоевал огромную популярность в IT сообществе и, как следствие, его часто можно встретить в стеке технологий различных компаний.

Далее я расскажу про структуру Git репозитория и как его завести. Познакомлю вас с основными, наиболее популярными командами в Git. Также вы узнаете о том, как инспектировать историю своего проекта и как откатить его до определенной точки. И, в заключение, я слегка затрону тему ветвления.

Установка Git

Прежде чем мы продолжим, вам необходимо установить Git.

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

Windows. Перейдите по ссылке и скачайте Git соответствующий архитектуре вашего процессора (32 или 64-bit) и установите его.

Linux. Перейдите по ссылке для более подробной инструкции.

Как правило, ваша работа с Git будет начинаться с того, что вам потребуется проинициализировать Git директорию в своем проекте. Это делается с помощью команды:

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

В данном файле содержатся настройки Git репозитория. Например, здесь можно хранить email и имя пользователя.

В этом каталоге Git предоставляет набор скриптов, которые могут автоматически запускаться во время выполнения git команд. В некоторых случаях это значительно упрощает разработку. Например, вы можете написать скрипт, который будет редактировать сообщение коммита согласно вашим требованиям.

Каталог refs хранит в себе копию ссылок на объекты коммитов в локальных и удаленных ветках.

Каталог logs хранит в себе историю проекта для всех веток в вашем проекте.

Каталог objects хранит в себе BLOB объекты, каждый из которых проиндексирован уникальным SHA.

Файл содержит ссылку на текущую ветку, в которой вы работаете

Каждый раз во время слияния в этот файл попадает SHA ветки, с которой проводилось слияние

Файл хранит в себе ссылки в виде SHA на ветки, которые участвовали в git fetch

Файл хранит в себе ссылки в виде SHA на ветки, которые участвовали в git merge

Файл содержит в себе последнее введенное вами сообщение коммита

Самые распространенные команды в Git.

При работе с системами контроля версий разработчики сталкиваются с определенной, повторяющейся последовательностью действий. Оно и понятно, ведь, по сути, если не брать в расчет возможности Git для управления состоянием проекта и прочие плюшки, то как правило ваша работа ограничена рядом действий:

1. Внести изменения в проект;

Итак, разберемся в этом подробнее. Проинициализировав Git репозиторий, вы начинаете вносить какие-то изменения в проект. Предположим, что вы создали файл `hello_world.txt` и работаете над его редактированием.

Введем git status и увидим следующее:

Команда git status отображает состояние директории и индекса(staging area). Это позволяет определить, какие файлы в проекте отслеживаются Git, а также какие изменения будут включены в следующий коммит.

Так как вы создали новый файл, Git определяет его как неотслеживаемый, и тут же подсказывает, что делать дальше:

git add hello_world.txt

Файл добавлен в индекс. Теперь можно закоммитить внесенные изменения и оставить небольшое описание. Делается это командой:

Готово! Мы сделали наш первый коммит! Далее добавим в наш файл строку “Hello, World!”, и снова проверим git status:

Что ж, мы научились записывать и хранить изменения на своей машине, теперь нам нужно отправить версию нашей истории на удаленный сервер. В данном примере я воспользуюсь репозиторием на GitHub.

Для начала вам нужно создать удаленный репозиторий. Как это реализовать в случае с GitHub подробно описано тут.

Далее необходимо добавить удаленный репозиторий в Git:

Эта команда сопоставит удаленное хранилище с ссылкой на локальный репозиторий. С этого момента можно обращаться к удаленному репозиторию через эту ссылку. Например:

git remote add origin https://github.com/user/hello_world.git

Готово! Теперь история изменений вашего проекта будет храниться в удаленном репозитории.

Работа с историей

Итак, как записывать, сохранять и отправлять изменения в удаленное хранилище мы разобрались.

Настало время поговорить о том, как управлять историей проекта. А именно как просматривать изменения и как откатить проект до определенной точки.

Для инспектирования истории в Git предусмотрен определенный ряд команд, рассмотрим несколько из них:

Данная команда предназначена для отображения всей вашей истории. Она может быть весьма удобна, если вам понадобилось узнать, какие изменения вы вносили ранее. Или если вам нужно откатиться до определенного места в истории, либо если есть нужда её отредактировать.

Если ввести git log без каких либо параметров, выглядит это примерно так:

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

Хотите просмотреть последние три коммита? Пожалуйста:

Есть необходимость вывести все в одну линию? Запросто:

Так можно продолжать до бесконечности, поэтому я оставлю ссылочку, перейдя по которой, вы сможете с ними подробней ознакомиться.

Команда git show используется для отображения полной информации о любом объекте в Git, будь то коммит или ветка. По умолчанию git show отображает информацию коммита, на который в данный момент времени указывает HEAD.

Для удобства работы git show оснащен рядом дополнительных параметров, некоторые из них мы рассмотрим ниже.

Здесь представлена полная информация о последнем коммите, а также какие именно изменения он в себя включает.

Мы также можем вывести диапазон из указанных коммитов. Диапазон указывается полуоткрытым интервалом, содержащим id коммитов, не включая первый элемент. Выглядит это следующим образом:

git show 349de9d..957e113

Для более лаконичного вывода, можно воспользоваться командой:

Таким образом, мы сократим id коммита, а также исключим авторство и дату коммита.

Подробнее с командой `git show` и с её параметрами можно ознакомиться перейдя по ссылке.

Эта команда выводит упорядоченный список коммитов, на которые указывал HEAD. Грубо говоря, она отображает историю всех ваших перемещений по проекту.

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

Вывод этой команды выглядит следующим образом:

Теперь давайте рассмотрим очень полезную команду `git reset`. Она позволяет откатить проект до определенной точки.

Эту команду можно использовать с тремя параметрами:

Давайте вернемся к нашему репозиторию и рассмотрим следующий пример:

Итак, в ходе нашей работы, мы сделали четыре коммита. Предположим, что мы хотим откатить проект до второго коммита. Давайте посмотрим, как это будет происходить, используя разные параметры:

Далее, проверим индекс:

Как и ожидалось, указатель HEAD переместился на второй коммит, а состояние индекса осталось неизменным.

Проверим git status:

Снова проверяем git status :

Здесь указатель HEAD переместился на второй коммит, а все предыдущие изменения были стерты, что видно по пустому индексу и зоне отслеживаемых файлов.

И если посмотреть сейчас содержимое файла, то мы увидим единственную строку “Hello, world!”, которую мы с вами добавляли в файл во втором коммите.

Ветвление в Git

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

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

Давайте попробуем с этим поработать на нашем примере. У нас имеется следующая последовательность коммитов.

Git по умолчанию во время инициализации создает ветку master и уже ведет свою работу в ней. Мы можем в этом убедиться введя команду:

Предположим, что нам по какой-либо причине понадобилось создать новую ветку и вести работу в ней. Для этого сначала необходимо её создать.

Делается это при помощи команды git branch
. Давайте создадим ветку “dev”:

Теперь введя команду git branch мы увидим следующее:

Звёздочкой Git указывает на текущую ветку, в которой мы работаем.

Для того чтобы переключиться на другую ветку используют команду git checkout
. Давайте переключимся на ветку “dev”.

Теперь внесем любые изменения в файл hello_world.txt и сделаем коммит, после чего посмотрим, как выглядят наши ветки после редактирования.

Теперь перейдем на ветку master

git checkout master

Помимо разделения истории в Git мы также можем соединять воедино два потока разработки. Это значит, что нашу проделанную работу в новой ветке мы можем слить обратно в master. Такой процесс слияния можно выполнить при помощи команды git merge
. То есть, если мы хотим слить изменения из ветки “dev” в ветку “master”, нам необходимо перейти на ветку “master” и в ней выполнить:

Примеры ведения истории проекта

Моя статья подходит к концу, но перед завершением хочу отметить, что во многих командах существуют определенные соглашения по поводу ведения истории в Git.

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

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

1. Сообщение коммита:

Ниже представлен шаблон наших сообщений коммита:

Мы указываем дату совершения коммита и версию приложения для удобства поиска работы в истории.

Модификаторы формата коммита предоставляют информацию о том какой фронт работы был выполнен в этом коммите.

Мы используем следующие модификаторы:

2. Стратегия ветвления:

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

В нашем случае, мы выделяем две основные ветки master и «release». Master используется для подготовки к выкладке новых версий приложения. Код попавший в «master» проходит автоматические тесты, после которых выполняется сборка проекта, которую необходимо вручную протестировать перед дальнейшими действиями. Далее если замечаний к работе нет, мы сливаем ветку «master» в ветку «release». Там снова запускаются автоматические тесты, и собираются сборки к выкладке в маркеты.

Для ведения разработки мы создаем feature векти. Это означает, что каждая ветка отвечает за разработку какой-нибудь функциональности. Например, если мы хотим внедрить в приложение хранение данных в облаке, то программист создаст ветку «feature-cloud» и будет вести работу в ней.

Заключение

В качестве тренировки и закрепления имеющихся навыков, оставлю ссылку на удобный тренажер для Git.

А также на книги, которыми я пользовался и интернет ресурсы:

Также было бы интересно узнать какие практики по Git есть у вас в компаниях и какие интересные ресурсы вы можете подсказать.

Источник

In Git, what is the difference between origin/master vs origin master?

I know, origin is a term for the remote repository and master is the branch there.

I am purposely omitting the «context» here and I am hoping that the answer should not depend upon the context. So in git command lines, what is the difference between origin/master and origin master. Is there a non-ambiguous way to understand when to use origin/master and when I should use origin master?

7 Answers 7

(Note: When this question was originally posted, «master» was the default name for branches in Git. Since «main» is now the default name, this answer has been updated to use «main», in the hope that this will be more natural for people new to Git.)

There are actually three things here: origin main is two separate things, and origin/main is one thing. Three things total.

Is origin/main remote?

Example: pull in two steps

Since origin/main is a branch, you can merge it. Here’s a pull in two steps:

Then you can push your new changes in main back to origin :

More examples

You can fetch multiple branches by name.

You can merge multiple branches.

Can you use a different name?

I can do that easily enough:

Example (in local branch master ):

origin/master is the remote master branch

You would use origin master when pushing, for example. git push origin master is simply telling GIT to push to the remote repository the local master branch.

origin is a name for remote git url. There can be many more remotes example below.

It is possible that remote bangalore has advanced since you have done «fetch» or «pull»

origin is nothing but the original name given to the remote repository. Origin is just a location that’s all. In the below example the repository URL is the origin or the source of truth of where your code resides.

now this origin or the source of truth to you repository can have branches this includes master or develop or you name it.

Now taking origin in the context we can easily under the below things mean.

So if I type git pull origin master What happens?.

This will update my local master branch (on my local machine) will all changes available on the remote master branch (i.e. origin master).

Now I would like my changes to merged with my local master branch how can I achieve this?

git merge origin/master

This will update my local master branch with my changes. The reason to have origin/master is just naming convention you could have named your local master branch origin/master or abcd. So you could have named you local branch instead of origin/master to just master and the command for git would be git merge master.

How would I update my remote master branch with all the local changes?

Источник