Если вы прочитали всю книгу, то много узнали об использовании Git в командной строке. Вы можете работать с локальными файлами, синхронизировать свой репозиторий с чужими по сети и эффективно работать с другими людьми. Но это ещё не всё; Git обычно используется как часть большей экосистемы и терминал это не всегда лучший способ работы с ним. Рассмотрим несколько других окружений где Git может быть полезен и как другие приложения (включая ваши) работают с ним.
Графические интерфейсы
Родная среда обитания Git — это терминал. Новые функции изначально доступны только там и лишь терминал поможет вам полностью контролировать всю мощь Git. Но текстовый интерфейс — не лучший выбор для всех задач; иногда графическое представление более предпочтительно, а некоторые пользователи чувствуют себя комфортней, орудуя мышкой.
Также стоит понимать, что разные интерфейсы служат разным целям. Некоторые Git клиенты ограничиваются лишь той функциональностью, которую их автор считает наиболее востребованной или эффективной. Учитывая это, ни один из представленных ниже инструментов не может быть «лучше» остальных: они просто предназначены для решения разных задач. Также стоит помнить, что всё, что можно сделать с помощью графического интерфейса, может быть выполнено и из консоли; командная строка по прежнему является местом, где у вас больше всего возможностей и контроля над вашими репозиториями.
gitk и git-gui
Проще всего вызвать Gitk из командной строки: Просто перейдите в каталог с репозиторием и наберите:
И его интерфейс выглядит так:
Слева находится область редактирования Git индекса: изменения в рабочем каталоге наверху, добавленные в индекс изменения — снизу. Вы можете перемещать файлы целиком между двумя состояниями, кликая на иконки, или же вы можете просмотреть изменения в конкретном файле, кликнув по нему.
Справа вверху расположена область просмотра изменений выделенного файла. Можно добавлять отдельные кусочки или строки в индекс из контекстного меню в этой области.
Справа снизу находится область для ввода сообщения коммита и несколько кнопок. Введите сообщение и нажмите кнопку «Commit» чтобы выполнить коммит. Также можно изменить предыдущий коммит, выбрав радиокнопку «Amend», что приведёт к обновлению индекса содержимым предыдущего коммита. После этого вы можете как обычно добавлять или удалять файлы из индекса, изменить сообщение коммита и, нажав кнопку «Commit» создать новый коммит, заменив им предыдущий.
gitk и git-gui — это примеры инструментов, ориентированных на задачи. Каждый из них наиболее подходит для решения определённой задачи (просмотр истории или создание коммитов соответственно) и не поддерживает дополнительные функции Git, ненужные для её решения.
GitHub для Mac и Windows
Компания GitHub выпустила два инструмента, ориентированных на рабочий процесс, а не на конкретные задачи: один для Windows, второй — для Mac. Эти клиенты — хороший пример процесс-ориентированного ПО: вместо предоставления доступа ко всей функциональности Git, они концентрируются на небольшом наборе фич, работающих вместе для достижения цели. Выглядят они примерно так:
Они спроектированы по одному шаблону, поэтому мы будет рассматривать их как один продукт в этой главе. Мы не будем разбирать по косточкам эти инструменты (в конце-концов у них есть документация), а лишь быстренько взглянем на экран изменений (место, где вы будете зависать больше всего).
Слева расположен список отслеживаемых репозиториев; можно добавить репозиторий (клонировав его, либо указав путь к существующей копии) нажатием кнопки + над списком.
В центре экрана расположена область редактирования коммита: тут можно ввести сообщение коммита и выбрать файлы для включение в него. (На Windows, история коммитов расположена под этой областью, на Mac это отдельная вкладка.)
Справа — просмотр изменений: что изменилось в рабочем каталоге, какие изменения войдут в коммит.
И стоит обратить внимание на кнопку «Sync» справа вверху, которая используется для синхронизации по сети.
Необязательно регистрироваться на GitHub, чтобы работать с этими инструментами. Хотя они навязывают использование GitHub, оба инструмента прекрасно работают с любым другим Git сервером.
Установка
GitHub для Windows можно скачать на https://windows.github.com, а для Mac — на https://mac.github.com. При первом запуске обе программы проведут первоначальную настройку Git, например, сконфигурируют ваше имя и email, а также установят разумные значения по умолчанию для распространённых опций типа CRLF-поведение и хранилище паролей.
Оба инструмента поддерживают автообновление в фоне — это означает, что у вас всегда будет последняя версия. Это также относится к поставляемому в комплекте с ними Git — вам никогда не придётся обновлять его вручную. На Windows вы также получаете ярлык для запуска PowerShell с Posh-Git, который мы рассмотрим далее в этой главе.
Следующий шаг — скормить программе парочку репозиториев для работы. Клиент для GitHub показывает список репозиториев, доступных вам на GitHub, и вы можете клонировать любой в один клик. Если же у вас уже есть клонированный репозиторий, просто перетяните его из окна Finder (или Windows Explorer) в окно клиента GitHub, и он будет включён в список репозиториев слева.
Рекомендуемый рабочий процесс
После установки GitHub клиент можно использовать для решения кучи стандартных задач. Рекомендуемый ниже подход к работе иногда называют «GitHub Flow». Мы рассмотрели этот рабочий процесс в разделе Рабочий процесс с использованием GitHub главы 6, но вкратце, важны два момента: (а) вы коммитите в отдельные ветки и (б) вы регулярно забираете изменения с удалённого репозитория.
Управление ветками слегка различается на Mac и Windows. В Mac версии для создания ветки есть кнопка вверху окна:
На Windows создание ветки происходит путём ввода её имени в переключатель веток:
После создания ветки добавление коммитов в неё довольно тривиально. Измените что-нибудь в рабочем каталоге и, переключившись в окно клиента GitHub, вы увидите свои изменения. Введите сообщение коммита, выберете файлы для включения в коммит и нажмите кнопку «Commit» (ctrl-enter или ⌘-enter).
Взаимодействие с удалёнными репозиториями происходит в первую очередь посредством кнопки «Sync». В Git есть отдельные команды для отправки изменений на сервер, слияния изменений воедино и перемещения веток друг относительно друга, но клиент GitHub совмещает все эти команды в одну. Вот что происходит когда вы жмёте «Sync»:
Это довольно привычный, но рутинный процесс при работе по «GitHub Flow», совмещение команд воедино действительно экономит время.
Заключение
Перечисленные инструменты отлично решают поставленные перед ними задачи. С их помощью разработчики (и не только) могут начать совместную работу над проектами в считанные минуты, причём с настроенным рабочим процессом. Но если вы придерживаетесь иных подходов к использованию Git, или если вам нужно больше контроля над происходящим, мы рекомендуем вам присмотреться к другим клиентам, а то и вовсе к командной строке.
Лучшие инструменты и расширения Git GUI в 2020
Упрощение Git с помощью потрясающих инструментов GUI и расширений IDE.
Новички обычно начинают с терминальных команд Git, чтобы понять основы Git. Хотя это хорошая идея, чтобы узнать терминальные команды Git, вы можете чувствовать себя утомительно, когда возвращаетесь к терминалу для довольно простой задачи, как фиксация или толчок.
В этой статье мы расскажем об основных инструментах и расширениях Git GUI, чтобы упростить такие простые задачи в Git и тем самым повысить эффективность вашего рабочего процесса.
Во-первых, мы рассмотрим некоторые вещи, о которых нужно знать, прежде чем использовать инструменты и расширения. Далее мы рассмотрим популярные расширения Git для популярных текстовых редакторов, Sublime Text и Atom. Наконец, мы познакомимся с тремя популярными инструментами Git GUI.
Независимое управление версиями компонентов JavaScript
Благодаря таким инструментам, как Bit, вы можете создавать версии отдельных компонентов поверх вашего «обычного» управления версиями на уровне РЕПО.
Это отличный способ максимизировать повторное использование кода (в репозиториях и между ними), ускорить разработку и создать более поддерживаемую кодовую базу.
Компоненты, опубликованные в Bit.dev, также могут быть клонированы (в виде исходного кода) в любой проект, где они могут быть изменены и опубликованы обратно в Bit.dev с измененной версией. Это означает, что сотрудничество больше не ограничено границами вашего хранилища.
Замечание об инструментах и расширениях Git GUI
Прежде чем вы решите использовать эти инструменты и расширения на постоянной основе, давайте сделаем шаг назад и рассмотрим преимущества и недостатки. Инструменты и расширения Git GUI обеспечивают фантастический способ быстрого и эффективного выполнения действий Git. Они предлагают преимущество визуальной демонстрации различий и истории проекта, что, безусловно, сложно продемонстрировать на терминале. Инструменты и расширения Git GUI легко интегрируются в ваш рабочий процесс без необходимости переключаться между текстовым редактором и терминалом.
Хотя они предлагают множество преимуществ, существуют потенциальные проблемы, о которых вам следует знать. Во-первых, эти инструменты и расширения могут предложить только определенное количество функций Git — сложные действия, такие как cherry-pick, все еще могут выполняться только на терминале. Поэтому хорошей идеей является изучение команд терминала Git. Кроме того, изучение каждого из этих инструментов становится проще, если вы знаете, как Git работает в фоновом режиме с помощью команд терминала. Далее, терминальные команды часто выполняются быстрее, поскольку между выполнением и отображением результатов нет никакой задержки. Наконец, самым большим сдерживающим фактором для того, чтобы полагаться исключительно на эти инструменты, является то, что их пользовательский интерфейс может быть непоследовательным для разных платформ и версий.
Поэтому мы предлагаем вам использовать инструменты и расширения Git GUI только после того, как вы освоитесь с командами терминала. В этом посте мы продемонстрируем, как выполнять обычные задачи Git с помощью этих инструментов и расширений.
1. Расширение Git для Sublime Text
После установки расширения откройте корневой каталог репозитория Git. Выберите Ctrl/Cmd + Shift + p и начните вводить любую команду Git. Например, чтобы проверить изменения в вашем текущем репозитории, введите git diff и нажмите ввод. Вывод команды открывается в виде новой вкладки.
При выборе одной фиксации в истории проекта сведения о ней открываются на новой вкладке.
Расширенные команды, такие как git blame также включены в этом расширении Git.
2. Встроенное расширение Git в Atom
В этом меню, когда вы выбираете вкладку Git, вы можете видеть не поэтапные изменения, файлы и поэтапные изменения. Вы можете перейти к этапу изменений и создать фиксацию с сообщением.
Вы можете изменить активную ветку или создать новую из опций в правом нижнем углу. Вы также можете обновить свой текущий репозиторий с пульта.
После того как вы создали фиксацию, вы можете отправить любые новые изменения из пользовательского интерфейса Atom из опций в правом нижнем углу.
Хотя эти основные команды, связанные с Git, легко выполнимы в Atom, вы можете переключиться на вкладку GitHub, чтобы создать запрос на вытягивание, если у вас есть новые фиксации, которые перенаправят вас на ссылку на GitHub, сравнивая изменения между ветвями.
3. GitHub Desktop
Хотя мы проверили расширения Git для двух популярных текстовых редакторов, давайте перейдем к инструментам Git GUI. Эти инструменты предоставляют немного больше свободы по сравнению с расширениями текстового редактора, поскольку их пользовательский интерфейс специально создан для этой цели.
Обратите внимание, что пользовательский интерфейс изменений в GitHub Desktop похож на интерфейс Atom. Существует две категории файлов для поэтапных и неустановленных изменений. Различие каждого выбранного файла показано справа. Выберите файлы для подготовки к фиксации и введите сообщение о фиксации, чтобы создать фиксацию.
В верхней части есть три варианта выбора хранилища, текущей ветки и действия для обновления хранилища с origin удаленного компьютера. Третья кнопка изменяется, чтобы нажать изменения, origin когда вы создаете фиксацию.
Переход на вкладку истории показывает историю проекта. Тем не менее, он показывает только историю одной ветви и не показывает связи между несколькими ветвями.
4. SourceTree
Состояние хранилища выглядит аналогично состоянию GitHub Desktop с точки зрения промежуточной и неотмеченной области, различий в выбранном файле и возможности ввода сообщения фиксации в том же окне.
История проекта намного лучше в этом инструменте. Связи между ветвями и циклами, созданными слиянием, все отображаются, когда вы нажимаете на опцию истории в левом меню.
Кнопки сверху позволяют выполнять простые операции в Git. Вы можете фиксировать изменения, управлять филиалами и удаленными пользователями, и даже создавать тайник в Git из верхнего меню.
Расширенные параметры, такие как теги, подмодули и поддеревья, также доступны в SourceTree.
Последние мысли
В этой статье мы рассмотрели базовое использование двух расширений Git для популярных текстовых редакторов и двух популярных инструментов Git GUI. Мы также обсудили плюсы и минусы инструментов с графическим интерфейсом и почему они должны служить дополнением к командам терминала Git для повышения эффективности вашего рабочего процесса Git.
Git GUI моей мечты
Я разработчик игр и мобильных приложений. Я написал немало кода на C++ и Swift. И, как и многие из вас, я пользуюсь системами контроля версий, в частности, гитом.
Гит имеет максимально функциональный command-line интерфейс и десятки если не сотни приложений для работы с ним локально при помощи графического интерфейса, которые умеют выполнять только часть функционала гита. Беда в том, что я пишу код уже 10 лет, но никак не нашел идеальный (подходящий для меня) git GUI клиент. Пример: недавно вышел Github Desktop. Я его использовал до тех пор, пока мне не понадобилось сделать checkout на конкретный коммит. И я испытал уже привычную боль от того, что данное приложение так делать не умеет. И вновь вернулся в терминал (с автодополнением для гита). И такие вещи есть в каждом GUI приложении для гита. Однако, я сюда пришел не критиковать их. Уверен, что вы и без меня имеете много претензий к этим приложениям. Я долго думал о том каким должно быть идеальное git GUI приложение. Это были мимолетные обрывки желаний, из которых трудно собрать что-то цельное. И совсем недавно эти обрывки мыслей у меня собрались в единую картину. Ниже я опишу это в формате ТЗ (технического задания) в максимально понятной форме.
Идеальный Git GUI клиент
Важно чтобы интерфейс не был суперусложнен. Если юзер откроет прилажку и увидит больше 20 кнопок, то идея отстой. Бóльшая часть пользователей переключаясь на консоль для работы с гитом пишут команду git status чтобы узнать список файлов с измененным статусом. Потому наше приложение должно почти на весь экран показывать список файлов в виде иерархии, которые имеют измененный статус (примерно как проводник/finder). Туда будет входить все, что мы можем увидеть командой git status : измененные файлы, untracked файлы, добавленные и удаленные (возможно, какой-то статус я забыл). Каждый файл должен как и в консоли отображаться либо красным цветом, либо зеленым, что показывает его добавленность в коммит. На любой файл можно кликнуть правой кнопкой мыши или нажать на три точки в правой части строки чтобы вызвать контекстное меню. В контекстном меню можно добавить файл если он не добавлен ( git add команда в терминале), сделать reset если он добавлен, удалить если он не находится в индексе (clean). Еще можно кликнуть на папку правой кнопкой и добавить всю папку ( git add folder ). Аналогично работает reset. Еще можно добавить в индекс все маленькой кнопкой в верхнем левом углу дерева файлов. Можно кликнуть по строчке с файлом чтобы открыть дифф по нему на весь экран.
Сверху окна есть отдельный заголовочный блок примерно как в Xcode с названием ветки и статусом того, что сейчас происходит (pulling, pushing, idle). Это все. То есть, окно по-умолчанию только показывает статус: нынешнюю ветку и статус файлов.
Далее пользователь наводит указатель мыши на нужную команду и кликает на нее. После этого происходит вызов команды если это команда без аргументов (например, pull, push, fetch). Если нужно указать аргументы, то пользователь кликает правой кнопкой на название команды (например, push) и появляется соответствующее модальное диалоговое окно с вводом аргументов (цель remote и имя ветки, а также галочка force), которые указываются мышью или горячими клавишами. К этом моменту изначально зажатый tab можно уже отпустить. Если кликнуть за пределами модального окна или нажать esc, то модальное окно закроется и вызов команды будет отменен. Если же в этом модальном окне указать аргументы и нажать кнопку push, то начнется выполнение команды. Процесс выполнения команды будет отображен на верхней панели под названием ветки.
Еще одно важное преимущество терминала над остальными git GUI приложениями это возможность склеивать команды последовательно при помощи операторов && и ||. Например, я лично в работе часто использую такую последовательность для подлития в свою ветку той ветки, от которой моя ветка была срезана:
Данная последовательность выполняет 4 операции:
переключается на ветку dev
скачивает последние изменения ветки dev
переключается обратно на ветку, на которой мы находились до ветки dev
вливает ветку dev в нынешнюю ветку
Оператор && устроен таким образом, что если одна из команд остановится из-за ошибки, то выполнение всех остальных команд не начнется. Это суперудобно, но я не видел ни одного git GUI клиента, который бы умел склеивать команды в последовательность (если вы такой знаете, то укажите это в комментариях). И я придумал как в моем потенциальном абстрактном идеальном git GUI приложении моей мечты это будет выполнено.
Отдельная фича, которая сделает использование истории гита удобнее, это хэширование хэша (да, именно так) коммита в виде эмоджи. Объясню на примере. Когда я смотрю историю коммитов, я вижу список труднозапоминаемых длинных хэшей типа такого
Эмоджи намного лучше запоминаются человеком, чем безымянные шестнадцатеричные хэши. Если везде, где мы ни показывали хэши коммитов (история или статус pull’а), показывать их эмоджи хэши, то пользователь лучше будет помнить на каком он коммите работает прям сейчас, и меньше будет ошибок когда он забыл влить другую ветку, запушить или запулить изменения. Вообще было бы здорово если бы эмоджи-хэш использовался везде: на github, bitbucket, teamcity. Это позволило бы проще сверять коммиты билдов с коммитами в истории.
Git gui here что значит
Краткое введение в Git (3 сценария использования)
Git (гит) является наиболее популярной разновидностью системы управления версиями (VCS). В настоящее время это необходимый инструмент профессиональной разработки ПО, используемый в подавляющем большинстве программных проектов. В рамках нашего учебного курса Git используется для контроля и отчетности выполнения практических заданий по программированию.
Git существует в качестве сервера и в качестве клиента. Далее, мы рассмотрим установку программы в качестве клиентского приложения на локальный компьютер пользователя. В качестве серверной части будет выступать известный ресурс https://github.com.
Установка и настройка
и выбираем дистрибутив для своеё операционной системы или идем по ссылке в нижнем правом углу страницы.
После скачивания и запуска инсталлятора появляется мастер установки:
В окне опций соглагшаемся с предложением по-умолчанию:
Git можно использовать через специальные программы-клиенты с графическим интерфейсом пользователя, а можно через обычную командную строку. Для изучения системы рекомендуется научиться основным командам, поэтому далее рассматривается работа именно в командной строке.
Инсталлятор установит специальную unix-подобную оболочку для ввода команд, под названием Git Bash:
На этом этапе установки вновь соглашаемся с инсталлятором:
Обратите внимание, что при выборе опций была установлена галочка в пункте Интеграция с проводником Windows. Тогда, в контекстном меню, вызываемом нажатием правой кнопкой мыши на области окна с папкой, должны появиться пункты:
что значительно облегчает запуск командной оболочки с переходом в указанную папку.
Теперь в проводнике Windows на диске C: создадим папку с будущим репозиторием (хранилищем) проектов. На самом деле эту папку можно размещать в любом месте файловой системы, но мы упрощаем себе задачу. Внимание! Не рекомендуется хранить репозитории в папках с пробелами или кириллическими символами в названии.
Если войти в проводнике в соданную папку (C:\Labs), вызвать контекстное меню и выбрать пункт Git Bash Here, то откроется окно оболочки с приглашением.
В окно теперь можно вводить команды для работы с Git.
Настройка пользователя и почты
Во время одного из этапов первоначальных действий с Git придётся настроить имя пользователя и адрес почты:
Первый сценарий. Разработка собственного проекта
В каталоге c:\labs мы создадим свой учебный проект Hello, World! и пройдем через все этапы работы в Git.
Создадим папку Hello в каталоге c:\labs и перейдем туда в оболочке:
Создадим новый (пустой) репозиторий:
Далее, создадим файл-исходник hello.c с текстом программы на языке C для нашего проекта:
Файл можно создать в любом подходящем текстовом редакторе (notepad), но лучше использовать специальные редакторы для программистов (notepad++).
позволяет увидеть имя файла с программой, выделенное красным цветом. Git обнаружил в папке файл, но не включил его в свой индекс.
Добавим этот файл (а точнее: изменения в этом файле) к git:
Команда проверки статуса покажет имя добавленного файла зеленым цветом.
Теперь зафиксируем изменения:
Разработка программы предполагает внесение изменений в исходный код. После некоторого количества правок, когда очередной элемент программы завершен, файл сохранен, необходимо снова дать последовательность команд:
Комментарий к коммиту должен отражать суть сделанных правок, быть лаконичным, но понятным.
Рассмотрим теперь более подробно рабочий процесс.
Когда мы меняем (или создаем) файлы, то они размещаются в рабочем каталоге (working directory). Команда git add добавляет сделанные изменения в область подготовки (staging area). При вызове
git commit происходит фиксация изменений в репозитории. В истории разработки появляется точка, на которую можно ссылаться, к которой можно совершать откат и т.п.
В таком виде процесс разработки может продолжаться сколько угодно, но рано или поздно потребуется отправить изменения на сервер, где проект может быть использован другими разработчиками.
Первый сценарий. Работа с сервером
Для работы с серверной частью необходимо зарегистрироваться на https://github.com. Обратите, пожалуйста внимание, что пользователям можно указывать тарифные планы для использования ресурса, но мы выбираем бесплатный тариф.
Активирование аккаунта происходит после подтверждающего письма по электронной почте.
Далее, мы выбираем вкладку Repositories и нажимаем зеленую кнопку New:
После этого необходимо заполнить ряд полей.
Нужно ввести имя создаваемого репозитория (лучше, если оно будет совпадать с локальным именем). Тип репозитория надо оставить public для свободно распространяемых проектов и private для закрытых от внешнего мира.
Нажатие зеленой кнопки Create переносит к финальному шагу:
На последнем шаге нам предлагают связать локальный и удаленный репозитории командой git remote. Мы должны набрать в командной оболочке
и передать первый раз изменения на сервер:
Слово origin в данном случае означает псевдоним серверного репозитория, а master имя ветки. По сути мы связали локальную и удаленную ветки master и отправили изменения на сервер.
Страницу репозитория можно обновить
Как в дальнейшем отправлять обновления на сервер?
Как только на локальной машине накапливается достаточно изменений (новых коммитов), осуществляется их передача на удаленный сервер командой
Эта команда передает изменения из текущей ветки в удаленную. В процессе установления соединения, возможно, потребуется указать свои регистрационные данные для аккаунта Github.
Сценарий второй. Подключение еще одного локального компьютера для разработки
Рассмотрим теперь ситуацию, когда нам нужно подключить к удаленному серверу еще один компьютер, чтобы вести на нем разработку, параллельно другому. Или мы хотим, чтобы другие пользователи могли скачивать обновления нашего кода и пользоваться наше программой.
Любой пользователь Github может выполнить клонирование существующего public репозитория к себе на локальный компьютер.
Если раскрыть список в виде зеленой кнопки, то мы увидим две возможности:
Клонирование репозитория подразумевает сохранение связи с ним, позволяющее потом обновлять содержимое локальной копии при изменении серверной (и, наоборот).
Клонирование репозитория осуществляется командой
После выполнения этой команды в командной оболочке, обычно требуется войти в репозиторий с помощью команды cd
Если на сервере произошли изменения и мы хотим обновить локальную копию, то сделать это можно через команду
Данная команда скачивает изменения со стороны сервера на локальный компьютер и применяет их к текущей ветке (master).
Замечание. Для обновления локальной версии public репозитория не требуется вводить логин и пароль. В принципе, не требуется даже иметь аккаунт на github. А вот при попытке отправить изменения на сервер будут запрошены данные для идентификации.
Таким образом, сценарий №2 позволяет скачивать с сервера программное обеспечение (в том числе чужое) и периодически обновлять его.
Третий сценарий. «Социальное» программирование
Сценарий №3 является наиболее сложным из рассматриваемых, но и наиболее популярным и интересным. В лабораторных работах мы будем использовать именно его.
Точкой отсчета будет выступать уже имеющийся репозиторий в сети, принадлежащий другому пользователю и имеющий статус public.
Последовательность действий при данном сценарии:
Владелец гостевого аккаунта (пользователь) выполняет операцию под названием Fork
В результате серверный репозиторий копируется в аккаунт пользователя.
Выполняется клонирование удаленного репозитория из своего аккаунта на локальный компьютер.
Для того, чтобы владелец серверного репозитория мог вытянуть и применить изменения в своем проекте, прользователь направляет ему Pull request (пул-запрос).
Владелец оригинального репозитория проверяет направленный ему код и применяет его к своему репозиторию (или отклоняет).
При использовании данной схемы возникает ряд вопросов, главный из которых: как обеспечить безопасное слияние нескольких пул-запросов?
Это достигается использованием механизма веток.
Если каждый пользователь будет работать в своей индивидуальной ветке, то слияние всех изменений в один репозиторий не повредит уже слитым изменениям, при условии, что все изменения происходят в индивидуальных ветках.
About
Краткое введение в Git и его использование с GitHub
