Время выпить чашечку чая, начать совместную разработку с командой Git

Git
Время выпить чашечку чая, начать совместную разработку с командой Git

Эта статья была написана членами сообщества Tuque.mRcнаписано, присоединяйтесьСообщество Туке, чтобы вместе создавать замечательные бесплатные технические руководства, чтобы способствовать развитию индустрии программирования.

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

В этой статье кратко описаны процесс и спецификации совместной разработки команды Tuque, которая предназначена только для справки. Оптимальное решение по-прежнему необходимо сочетать с реальной ситуацией в команде, а конкретные проблемы необходимо детально анализировать.

Чтобы все могли очень четко и интуитивно понять процесс совместной разработки, вы можете открыть Learn Git Branching во время просмотра.среда песочницыдля практики (вы можете ввести предоставленный код напрямую). Введите команду в терминал слева, и вы увидите соответствующую анимацию справа. Сплошной кружок слева представляет локальный склад, а пунктирный кружок справа — удаленный склад.*Номер указывает на текущую ветку,o/masterэто удаленная ветвь (oэквивалентноorigin).

Так как Learn Git Branching упрощает некоторые команды для удобства демонстрации и изучения, я укажу команды, которые следует вводить на практике.

Основной процесс

Далее мы сосредоточимся на следующих двух процессах:

  • Добавить код

  • Обновите локальный репозиторий

Добавить код

Следующий процесс описывает, как добавить код в центральный репозиторий после получения задач разработки.

клонировать репозиторий локально

$ git clone

Фактическая команда должна предоставлять параметры URI, например:

$ git clone https://github.com/dhucst/cooperation.git

открыть новую ветку

$ git checkout -b B1

В демонстрационных целях мы назовем новую ветку какB1. В реальной разработке наименование новых веток должно следовать следующим принципам:

  • Используйте чехол для кебаба, например.new-branch, вместоnew_branchилиnewBranch

  • Постарайтесь максимально обобщить задачи, которые должна выполнить эта ветка.

  • Если это решение проблемы, добавьте номер проблемы в конце, напримерfix-75

Напишите код и отправьте

$ git commit

Фактическая команда должна быть выполнена первойgit addчтобы добавить измененные файлы в промежуточную область, например:

$ git add .
$ git commit

Написание Commit Message (Log) имеет относительно строгую спецификацию, которая будет описана позже.Отправить спецификацию по написанию информацииразработан в.

толкать ветку
$ git push

Фактическая команда находится впервый разКогда нажимайте любую ветку, должны быть указаны удаленные и веточные имена:

$ git push origin B1

Иногда наши ветки устаревают в одночасье. Что такое устаревшая ветка и как с ней бороться? Не стесняйтесь, мы поговорим об этом позже.

Отправить запрос на включение

Этот шаг не нужно выполнять в разделе «Изучение ветвления Git».

После отправки ветки в удаленный репозиторий откройте страницу репозитория GitHub, и вы должны увидеть желтое окно подсказки, подобное следующему:

image-20200429091859922

Затем нажмите кнопку «Сравнить и запрос на вытягивание», чтобы перейти на страницу «Отправить запрос на вытягивание».

Принципы заполнения заголовка запроса на включение примерно такие же, как и в сообщении о фиксации. При заполнении сведений о запросе на слияние, если он предназначен для решения одной или нескольких проблем, вы можете использоватьClose(s), Fix(es)илиResolve(s)Ключевые слова, чтобы закрыть вопрос, напримерFix #75.

После нажатия кнопки «Создать запрос на включение» этот PR может быть завершен. Если после обсуждения выяснится, что его необходимо изменить, измените его непосредственно на локальном складе.git pushПросто идите и отправьте. Если код пройдет проверку, менеджер проекта объединит эту ветвь с основной, и процесс добавления кода завершится.

Обновить локальный репозиторий

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

Если во время просмотра вы используете Learn Git Branching, введите следующую команду:

$ reset
$ git clone

Другие участники вносят свой код

$ git fakeTeamwork 2

Команды Git на самом деле нет 😂, она предоставляется Learn Git Branching для практического сотрудничества.

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

Получить удаленный код

Рассмотрим первый, более простой случай:

В это время с первого взгляда видно, что только удаленныйC2а такжеC3Потяните его напрямую и заберите на местеC1Сразу после:

$ git pull

Теперь давайте рассмотрим другой более сложный случай:

Команды, которые необходимо ввести, следующие:

$ reset
$ git clone
$ git checkout -b B2
$ git commit
$ git fakeTeamwork 2

Глядя на картину, мыB2Филиал разрабатывает новую функцию, на этот раз обновлен удаленный склад.C4, очевидно, наша локальная основная ветка иB2Ветки уже не актуальны. Такая ситуация очень распространена: несколько мелких партнеров стартуют из одной отправной точки (вотC1) каждый разрабатывает новые функции, в то время как другие фиксируют до нас.

В большинстве случаев следуйте одному правилу:Обновляйте только основную ветку.

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

$ git checkout master
$ git pull

В этот момент мы будем думать, чтоB2филиал ужеустаревший(устарело), ​​потому что у него нет последней версииC3а такжеC4. Но устаревшая ветка не означает, что она бесполезна, мы можем отправить ее в удаленный репозиторий, как объяснялось ранее:

$ git checkout B2
$ git push

Затем вы также можете инициировать запрос на слияние. GitHub сообщит вам, что эта ветка устарела, вы можете нажать кнопку «Обновить ветку», чтобы обновить эту ветку (обычно это делает менеджер проекта).

резюме

Модель совместной групповой разработки включает только два основных процесса: добавление кода и обновление локальных репозиториев.

Процесс добавления кода:

$ git clone <REPO_URI>
$ git checkout -b new-branch
$ git add .
$ git commit
$ git push origin new-branch

Процесс обновления кодовой базы:

$ git checkout master
$ git pull

Параллельная разработка

Разработка проекта часто состоит из нескольких задач разработки, и каждый человек отвечает за одну или несколько задач разработки. Самая простая и идеальная ситуация, конечно, такова: одноклассник А начинает добавлять код, и все обновляют локальную кодовую базу после успешного слияния; затем одноклассник Б начинает добавлять код, и все обновляют локальную кодовую базу после слияния; затем одноклассники С, Д, Е...

Конфликтов не будет, просто используйте фронтОсновной процессКакая беззаботная и восхитительная команда была введена!

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

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

Независимо друг от друга и не изменяя один и тот же файл

Например, есть задача разработки целевой страницы, Datang отвечает за создание страницы «О нас», которая называется about-us.html, а Simmering Pigeon отвечает за создание страницы «Свяжитесь с нами», которая называется contact.html. Эти два файла независимы друг от друга.

Здесь мы предполагаем, что учащиеся Датанг выполнили задание первыми и были объединены вorigin/master. Тогда согласно предыдущей главеОбновить локальный репозиторийВ одном разделе говорится, что ветка, над которой работает Simmer Pigeon, «устарела». На этом этапе ему просто нужно продолжить заполнение своей страницы contact.html и отправить ее.

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

Зависимость существует, и тот же файл не изменен

Теперь предположим, что Datang разрабатывает index.html главной страницы лендинга, а голубь отвечает за написание стиля index.css лендинга Очевидно, что задачи разработки Datang зависят от голубя. После дня разработки Датанг закончил писать основную часть.C2, кипящий голубь также написал стильC3И он был отправлен на удаленный склад.Теперь ему нужно добавить таблицу стилей кипящего голубя, чтобы выполнить свои задачи по разработке.

существуетLearn Git BranchingВведите следующий код в:

$ git clone
$ git checkout -b html
$ git commit
$ git fakeTeamwork

Затем Датанг использует команду fetch, чтобы захватить удаленный C3 (на самом деле, более строго говоря, локальныйo/masterфилиал и удаленныйmasterСинхронизировать):

$ git fetch

Как видите, фиксация файла html и фиксация файла css находятся в разных ветках. html — это ветка, над которой мы работаем (и ветка, в которой мы сейчас находимся), поэтому поместитеC3Существующийo/masterОбъединено:

$ git merge o/master

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

В филиал нельзя просто понимать как строку Commit (хотя это понимание очень интуитивно понятно в большинстве случаев), следует понимать, что следует указывать на указатель коммита, и все родительские узлы коммитата являются узлами на ветке (коммит. Поэтому после того, как слияние выполняется, мы можем сказатьC2а такжеC3уже тамhtmlветвь на.

После слияния мы что-то модифицируем и отправляем какC5, а затем отправить в удаленный репозиторий:

$ git commit
$ git push

Напомните реальную команду push, чтобы добавить имя удаленного хранилища и имя ветки при первом нажатии ветки, напримерgit push origin html.

Следующим шагом является отправка запроса на слияние и ожидание слияния.

изменить тот же файл

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

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

$ mkdir conflict-demo && cd conflict-demo
$ git init
$ touch index.js
$ git add .
$ git commit -m "Add index.js"

Затем начинаем новую веткуadd-func :

$ git checkout -b add-func

В index.js добавьтеaddфункция:

function add(x, y) {
  return x + y;
}

Сохраните и зафиксируйте:

$ git add .
$ git commit -m "Implement add function"

Затем мы переключаемся обратно на ветку master и запускаем вызовorigin-masterВетка (послушайте, название тоже известно, оно имитирует удаленную ветку master):

$ git checkout master
$ git checkout -b origin-master

Затем добавьте вызов index.jsmultiplyФункция:

function multiply(x, y) {
  return x * y;
}

Ну а теперь местныеadd-funcРабочие ветки и «пульты»origin-masterВетка модифицирует тот же файл index.js, и конфликт неизбежен! Давайте зажжем этот фитиль!

На самом деле, вы можете просто продолжать рубить ветки вокруг (вводя по очередиgit checkout add-funcа такжеgit checkout origin-master), вы увидите, что содержимое index.js меняется вместе с ним, и прелесть системы контроля версий очевидна.

$ git checkout add-func
$ git merge origin-master

Мы обнаружим, что Git выводит информацию, которую вы никогда раньше не видели:

Auto-merging index.js
CONFLICT (content): Merge conflict in index.js
Automatic merge failed; fix conflicts and then commit the result.

Важный момент: index.js имеет конфликт при слиянии, разрешите конфликт и выполните коммит.

Мы просмотрели содержимое index.js и обнаружили нечто удивительное (просматривается с помощью cat в командной строке):

<<<<<<< HEAD
function add(x, y) {
  return x + y;
=======
function multiply(x, y) {
  return x * y;
>>>>>>> origin-master
}

Если мы откроем его с помощью VSCode, то увидим еще более крутые результаты:

Это видно с первого взгляда! Зеленая часть - это наша текущая веткаadd-func, синяя частьorigin-masterСодержание. Поскольку нам нужны оба варианта, нажмите «Принять оба изменения». Потом немного подправил, поменял index.js на следующий:

function add(x, y) {
  return x + y;
}

function multiply(x, y) {
  return x * y;
}

Зафиксируйте коммит, который мы использовали для обработки конфликта:

$ git add .
$ git commit -m "Merge conflict of index.js"

Обработка конфликта завершена, мы фиксируем эту ветку, и задача выполнена.

резюме

Параллельная разработка — сложная, но очень важная часть совместной работы команды Git. Обычно в большинстве случаев мы сталкиваемся с первой ситуацией. Если вы «к сожалению» столкнулись с последними двумя случаями, вы можете вернуться и просмотреть этот документ, если вы незнакомы.

PS: Для последних двух случаев необходимо добавить одну вещь: если вы хотите отменить слияние, используйте следующую команду:

$ git merge --abort

Отправить спецификацию по написанию информации

Сообщения фиксации, также известные как сообщения фиксации или журналы фиксации, представляют собой информацию, необходимую для каждого шага фиксации. Мы можем взглянуть на запись коммита репозитория React:

Благодаря этому мы можем лучше понять, что делается на каждом этапе проекта.

Формат

Каждое сообщение фиксации состоит из трех частей: заголовка, тела и нижнего колонтитула.

<header>
// 空一行
<body>
// 空一行
<footer>

Среди них Заголовок обязателен, а Тело и Нижний колонтитул можно опустить.

Header

В разделе «Заголовок» есть только одна строка, представляющая собой краткий обзор коммита иглагол-объектная структураа такжеИзменить объект (необязательно)изповелительное предложение(Не добавляйте точку!).

Давайте рассмотрим несколько примеров.

Remove 'warning' module from the JS scheduler

Структура глагола-объекта здесь — удалить модуль «предупреждение», а объект модификации — планировщик JS.

Add @flow directive to findDOMNode shim

Структура глагола-объекта здесь — это директива Add @flow, а объект модификации — прокладка findDOMNode.

Update www warning shim

Структура глагола-объекта здесь — Update www warning shim, Поскольку объект модификации уже ясен (в структуре глагол-объект), нет необходимости писать его заново.

Body

Часть Body — это подробное описание этого коммита, которое можно разделить на несколько строк. Ниже приведен пример.

More detailed explanatory text, if necessary.  Wrap it to 
about 72 characters or so. 

Further paragraphs come after blank lines.

- Bullet points are okay, too
- Use a hanging indent

Есть два предостережения.

  • Используйте настоящее время от первого лица, например,changeвместоchangedилиchanges.

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

Footer

Раздел нижнего колонтитула используется только в двух случаях.

(1) несовместимые изменения

Если текущий код несовместим с предыдущей версией, раздел нижнего колонтитула начинается сBREAKING CHANGEВ начале следует описание изменения, а также причина изменения и способ миграции.

(2) Закрыть выпуск

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

Closes #234

Также возможно закрыть несколько вопросов одновременно.

Closes #123, #245, #992

Наша командаРекомендуется закрыть вопрос в запросе на слияние., как преждеОсновной процесскак описано.

Revert

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

revert: feat(pencil): add 'graphiteWidth' option

This reverts commit 667ecc1654a317a13331b17617d973392f415f02.

Формат части Body фиксирован и должен быть записан какThis reverts commit <hash>.,один из нихhashявляется SHA-идентификатором отозванной фиксации.

Как изменить

При написании Commit Message в начале неизбежно, что оно будет написано плохо, как правило, кто-то подскажет, как его лучше написать, или вы сами придумали более подходящий способ его написания. Как изменить его в это время?

Изменить последний коммит

Если все, что вы хотите изменить, это самый последний коммит, это довольно просто. В Git есть специальные команды для простого изменения коммита прямо сейчас:

$ git commit --amend

Затем вы войдете в интерфейс vi, чтобы повторно отредактировать информацию о представлении. Конечно, вы также можете использовать его напрямую-mВозможность указать информацию о коммите:

$ git commit --amend -m "Updated commit message"

хочу быть вLearn Git BranchingВидишь, что происходит? Введите следующую команду, чтобы испытать это:

$ git commit
$ git commit --amend

Изменить n-й последний коммит

будет представлено нижеrebaseМожно сказать, что командная сила очень велика, но овладеть ею непросто. Все в порядке, давайте сначала посмотрим, как его использоватьrebaseИзменить обратный отсчет 3-го представления:

$ git rebase -i HEAD~3

-iозначает--interactive, после входа в Git откроется редактор vi и появится следующее:

pick 0f78800 倒数第4次提交
pick 459014c 倒数第3次提交
pick 38009c7 倒数第2次提交
pick dff7f7d 最新的提交

# Rebase 500d110..dff7f7d onto 500d110 (4 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

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

вы также можетеLearn Git Branchingиспытать этоrebaseЗаказ:

$ reset
$ git commit
$ git commit
$ git rebase -i HEAD~3

Learn Git Branching предоставляет графический интерфейс, который немного отличается от интерфейса Git vi.

Принудительно отправить изменения

Иногда вы можете разветвлятьсяpushв удаленный репозиторий и даже отправил запрос на слияние. если напрямуюpush, Git отклонит отправку из-за конфликта удаленных и локальных ветвей. Просто добавь-fпараметр, чтобы заставить локальную ветку перезаписать удаленную ветку:

$ git push -f

Ссылаться на

Руан Ифэн "Сообщение фиксации и руководство по написанию журнала изменений"

проверка кода

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

Проверка кода — это систематическая проверка исходного кода компьютера (иногда называемая рецензированием). Его цель — найти ошибки, которые были упущены из виду на ранних этапах разработки, тем самым улучшив общее качество программного обеспечения. -Википедия

Зачем проверять код

Код-ревью не означает отсутствие рецензентов. Следующие причины демонстрируют важность проверки кода.

снизить риск

Совершенно нормально писать ошибочный код. Код, который каждый вносит, сначала проходит серию тестов сборки для непрерывной интеграции (CI, Continuous Integration), за которыми следует ручная проверка кода, поэтому можно сказать, что проверка кода является последней линией защиты.

Значительно улучшить качество кода

Обзоры кода — это не только поиск ошибок или исправление проблем с форматированием, но и повышение эффективности кода.

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

Облегчает знакомство с проектом

Когда над проектом работает команда, маловероятно, что каждый разработчик будет работать над каждой частью приложения. Бывает так, что в какой-то момент один разработчик усердно работает над большей частью модулей проекта, а другой занимается совсем другим.

Обмен знаниями

Работая вместе, каждый может учиться друг у друга и добиваться прогресса. Авторы, скорее всего, получат обратную связь от работы и узнают о возможных проблемах и областях для улучшения; рецензенты также могут узнать что-то новое, читая код других людей и узнавая, что применимо к их собственному плану работы.

Как провести код-ревью

Начать проверку кода

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

Затем участник, который был запрошен для проверки, открывает страницу запроса на слияние, и появляется окно подсказки:

Мы нажимаем кнопку «Добавить отзыв», чтобы перейти на страницу обзора (или вы можете щелкнуть вкладку «Файлы изменены»). На странице просмотра отображаются все измененные файлы в этом запросе на включение. Процесс проверки заключается в проверке этих измененных кодов.

Обзор на GitHub

Это самый простой метод прямо на странице запроса на вытягивание Github. Этого метода вполне достаточно для относительно небольшого филиала.

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

Щелкните знак плюса, чтобы прокомментировать эту строку:

Притянуть к местному обзору

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

$ git fetch origin lots-of-changes
$ git checkout logs-of-changes

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

Отправьте результаты проверки

Независимо от того, проверяете ли вы непосредственно на GitHub или локально, результаты проверки должны быть представлены в конце. Результаты проверки включают все ваши комментарии в строке кода, сводку проверки и окончательные комментарии.

Резюме обзора состоит в основном из нескольких слов. Если отправитель кода действительно делает очень хорошую работу, конечно, его следует похвалить; если есть какие-то недостатки, необходимо дать указания по улучшению и немного поощрения.

Есть три окончательных мнения:

  • Комментарий: Просто сделайте объективную оценку, не давайте четкого мнения о том, можно ли объединить эту ветку.

  • Утвердить: согласиться объединить эту ветку с основной веткой.

  • Запросить изменения: не соглашайтесь с объединением этой ветки, требуется дальнейшая модификация.

Затем коммиттер кода вносит изменения на основе отзывов других людей и отправляет их, а затем продолжает проверку и так далее, пока ветка не будет объединена.

Лучшие практики

Для коммиттеров кода

минимизация задач

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

предоставить достаточно контекста

Вы должны сознательно добавлять достаточно комментариев или документации при написании своего кода, потому что ваш код будет прочитан многими людьми. Хорошие комментарии облегчают остальным членам команды просмотр вашего кода и легче обнаруживают проблемы. Кроме того, при заполнении информации описания запроса на слияние также должны быть четко объяснены проблема, которую необходимо решить, и соответствующие изменения, которые произошли.

Для рецензентов

Пересмотрите самые важные вещи

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

  • Хорошо ли читается код?

  • Можно ли сделать его более кратким и более идиоматичным?

  • Соответствует ли код хорошим принципам проектирования?

  • Как насчет эффективности использования пространства и времени кода?

Сохраняйте позитивный и открытый ум

Не будьте слишком придирчивы, с удовольствием хвалите чужой труд и учитесь ценить чужой кодекс.

Хотите узнать больше интересных практических технических руководств? ПриходитьСообщество ТукеМагазин вокруг.

Категории