Отказ от ответственности: этот блог был создан в качестве задания в рамках моего курса «Разработка программного обеспечения с открытым исходным кодом» (CSC 426).
Что касается движения за открытый исходный код, очень важно понимать рабочий процесс Git и то, как сделать коммит Git. Открытый исходный код процветает благодаря сотрудничеству, и Git является фундаментальным инструментом в этой экосистеме. Понимание рабочих процессов Git позволяет участникам слаженно работать вместе, разрешать конфликты и эффективно объединять изменения.
Создание коммитов Git с четкими и описательными сообщениями имеет важное значение для прозрачности и последовательности, позволяя другим понимать код и просматривать внесенные изменения. Это также способствует поддержанию высокого качества кода, что имеет решающее значение в проектах с открытым исходным кодом. Более того, коммиты Git служат записью проекта, что делает их важными для организации и доступности истории проекта. Поэтому в мире открытого исходного кода владение рабочими процессами Git и коммитированием кода является основополагающим навыком для эффективного участия и успеха проекта.
В системе контроля версий, такой как Git, атомарная фиксация относится к процессу создания одной фиксации за раз, и эта фиксация должна быть сосредоточена только на одной конкретной задаче.Чтобы сделать успешную фиксацию, необходимо понимать, что такое рабочий процесс Git и как чтобы сделать успешный коммит Git.
Прочитав рекомендации от Молли Немеревер и Джереми Хемса по работе с рабочим процессом Git и созданию эффективного сообщения о фиксации Git, я нашел рекомендации по использованию Git через командная строка имеет наибольший смысл. Мой профессор всегда и постоянно напоминает мне использовать командную строку Git вместо использования расширения Git в IDE/текстовом редакторе, потому что командная строка обеспечивает более глубокое понимание внутренней реализации Git. Используя командную строку, я могу получить больший контроль над операциями Git, обеспечивая полное понимание рабочих процессов Git.
Однако, что для меня имеет меньше всего смысла в этой статье, так это сообщение о фиксации длиной более 50 символов. Я не думаю, что опытные разработчики когда-либо будут писать длинное сообщение о коммите с объяснениями. При использовании системы контроля версий всегда рекомендуется использовать более короткое и лаконичное сообщение о фиксации. Более длинные сообщения о фиксации могут стать многословными и менее эффективными в передаче важной информации о фиксации. Более длинные объяснения всегда будут обсуждаться в комментариях в исходном коде. Поэтому я считаю, что для обеспечения ясности и быстрого понимания при просмотре истории проекта сообщение о фиксации всегда должно содержать менее 50 символов.
ЧТО ТАКОЕ РАБОЧИЙ ПРОЦЕСС GIT?
Согласно статье Nemerever, диаграмма ниже в основном описывает все, что касается рабочего процесса Git:
Рабочий процесс Git — это определенный набор шагов для успешного сотрудничества отдельного человека или группы над программным проектом с использованием Git, включая процесс создания, проверки, тестирования и развертывания изменений кода эффективно и последовательно. Следующие шаги технически необходимы для работы над проектом с Git:
- Клонирование репозитория. Если у вашего проекта есть удаленный репозиторий в GitHub, вы сможете клонировать репозиторий, как показано на изображении ниже. Вам необходимо клонировать репозиторий на локальный компьютер, обычно с помощью IDE, например PyCharm, или текстового редактора, например Visual Studio Code. Затем вы увидите папку с копией проекта в проводнике. Вы также можете клонировать репо с помощью командной строки.
git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY
2.Git pull: это действие обновит вашу главную (основную) ветку на локальном компьютере. Это необходимо, поскольку во время клонирования репозитория члены вашей команды могут внести изменения. Вам также следует часто выполнять команду git pull, чтобы избежать конфликта слияния.
# Git pull by using the command line: git pull <original master> or <branch name>
3. Создание новой локальной ветки: При работе в команде важно помнить, что вы всегда будете избегать внесения изменений в основную ветку. Вместо этого вам следует создать новую ветку и назвать ее проблемой, которую вы пытаетесь исправить. В противном случае, если вы работаете в одиночку или намеренно редактируете основную ветку, вы можете внести изменения в основную.
# Creating a new branch using the command line: git checkout -b new_branch_name
4. Git add: Когда вы закончите вносить изменения и тестировать код, первым шагом для фиксации изменений в удаленном репозитории будет использование git add. git add используется для подготовки изменений к следующему коммиту. Он поэтапно обрабатывает внесенные вами изменения, подготавливая их для включения в ваш следующий коммит.
# Git add using the command line: git add file_name
5. Статус Git: Вам необходимо запустить git status в командной строке, чтобы убедиться, что измененные файлы были добавлены в промежуточную область. Команда git status помогает вам отслеживать состояние ваших файлов и гарантирует, что изменения, которые вы хотите включить в следующий коммит, были правильно подготовлены.
6. Git commit: вы сохраните эти файлы в удаленном репозитории с помощью команды git commit. Вы предоставляете сообщение о фиксации, чтобы описать цель и детали изменений, которые вы фиксируете. Это сообщение имеет решающее значение для понимания истории вашего проекта. Теперь ваш коммит сохранен в вашем локальном репозитории. Вам нужно помнить, что коммиты являются локальными, пока вы не отправите их в удаленный репозиторий.
# Git commit using the command line: git commit -m "commit message"
7. Git push: Ого, вы только что успешно зафиксировали свой код. Теперь пришло время отправить их в удаленный репозиторий вашей команды и подготовить к проверке. Ваша команда должна иметь возможность просматривать ваше сообщение о фиксации, как показано на изображении ниже, и вы должны иметь возможность создать запрос на включение.
# Git push using the command line: git push <branch_name>
После того, как ваша команда успешно рассмотрит ваш запрос на включение и (возможно) одобрит ваш код и объединит его с основным, вам следует выполнить команду git commit еще раз, чтобы обновить эти изменения на вашем локальном компьютере. Этот шаг очень важен, чтобы избежать конфликта слияния при следующем внесении изменений.
СОЗДАНИЕ СООБЩЕНИЯ GIT COMMIT:
Согласно рекомендациям Джереми Хелмса, есть несколько общих правил, которым необходимо следовать при написании сообщения о коммите:
- Используйте
$ git diff --check, чтобы убедиться, что коммит содержит существенные изменения кода. - Сообщение о фиксации должно начинаться с одной строки длиной не более 50 символов.
- Сообщение о коммите должно быть написано в повелительном наклонении настоящего времени и содержать точную информацию, например,
git commit -m "Add images to index.html". - Если фиксация связана с проблемой, вы должны иметь возможность включить номер проблемы в сообщение о фиксации. При этом проблема будет автоматически передана в ваш коммит как решение на GitHub.
git commit -m "[#1] Add images to index.html". Помните, что номер выпуска должен быть заключен в квадратные скобки после знака решетки. Есть и другие способы включить номера проблем:
Fixes #xxx
Fixed #xxx
Fix #xxx
Closes #xxx
Close #xxx
Closed #xxx
- Вы также можете закрыть несколько задач, следуя этому примеру:
git commit -m "[Close #1][#2][#3] Add images to index.html"
БОЛЬШЕ О ФОССЕ И РУННОМ КАМНЕ:
Как я упоминал в предыдущей статье, Runestone Academy — это проект с открытым исходным кодом, ориентированный на создание и распространение бесплатных учебников по математике и информатике, целью которого является демократизация учебников в 21 веке. Судя по определениям FOSS, многие из них перекликаются с ключевыми принципами Runestone.
Сообщество:Runestone Academy может работать благодаря множеству участников/соавторов в США и мире, включая профессоров университетов, студентов (таких как я!), исследователей и авторов книг. Сообщество Runestone включает в себя широкий круг людей, каждый из которых привносит в проект свой уникальный опыт, взгляды и увлечения. Что касается определений FOSS, многие участники раньше пользовались рунными камнями, особенно студенты и преподаватели. Начав участвовать в Runestone, они продолжают вносить ценный вклад и рано или поздно могут стать ценными участниками в зависимости от ценности своего вклада.
Разветвление.Возможность разветвления, важнейший аспект проектов FOSS, позволяет любому создать ответвление кодовой базы проекта. Открытость Runestone Academy к форкам гарантирует, что ее кодовая база останется доступной и адаптируемой. Исходные коды учебников Runestone всегда доступны заинтересованным участникам, которые могут поделиться ими и внести свой вклад. Этим летом я, по сути, развил множество учебников Runestone, чтобы увидеть, как составляются упражнения от разных авторов и предметов, что дало мне возможность улучшить учебник, над которым я работаю вместе со своим профессором и товарищами по команде.
Коммуникация, планы и выпуски: проекты FOSS, включая Runestone Academy, полагаются на общие инструменты коммуникации, такие как IRC, вики, списки рассылки, системы отслеживания ошибок и системы контроля версий, чтобы облегчить сотрудничество и обмен информацией между участниками. . Вы можете легко найти дорожную карту или релизы Runestone на их веб-сайте. У них также есть канал Discord, который объединяет участников и помогает расширить миссию Runestone. Эти методы помогают Runestone Academy поддерживать структурированный процесс разработки и информировать участников.
Ссылки:
Определения FOSS. Документы Google, docs.google.com/document/d/1yNo951BpIq1Kmyk8BTLN95qXJknrqkXaESGrYebyx-w/edit.
Стандарты и соглашения Git/GitHub Commit. Gist, gist.github.com/digitaljhelms/3761873.
Никогда, Молли. Git, GitHub и основы рабочего процесса. Сообщество DEV, март 2019 г., dev.to/mollynem/git-github — workflow-fundamentals-5496.
