10 различий между Git и Github, а также 16 лучших практик Github для обеспечения безопасности, функциональности и профессионального обслуживания ваших проектов.
Git hub — это платформа для размещения кода для контроля версий и совместной работы.
Я расскажу о двух областях: (1) десять различий между Git и Github и (2) 16 лучших практик Github.
10 различий между Git и Github
1. Git — это система контроля версий, а GitHub — веб-хостинг для контроля версий с использованием Git.
2. С помощью Git разработчики могут управлять и отслеживать изменения в исходном коде локально, тогда как GitHub создает центральный репозиторий, который упрощает совместную работу разработчиков.
3. Git бесплатный и с открытым исходным кодом, в то время как у GitHub есть платные планы для частных репозиториев и некоторых функций.
4. Git использует интерфейс командной строки, в то время как GitHub имеет пользовательский интерфейс и множество клиентов с графическими пользовательскими интерфейсами.
5. В Git у каждого разработчика есть полная локальная копия всей истории проекта, тогда как в GitHub по умолчанию загружается самая последняя версия проекта.
6. Git можно использовать в автономном режиме, а GitHub требует подключения к Интернету.
7. В Git нет ограничений на размер файла и количество репозиториев, в то время как GitHub накладывает определенные ограничения на хранилище в зависимости от выбранного пользователем плана.
8. Git быстрее, чем GitHub, поскольку ему не нужно связываться с сервером для каждой операции.
16 лучших практик Github
1. Держите свой код коротким и понятным
Пишите в чистом, последовательном стиле, который сделает ваш код очень читабельным. Он должен быть достаточно кратким, чтобы вы могли понять, что происходит, не вдаваясь в множество ненужных формулировок. Когда ваш код легко читается, его легче поддерживать. И когда его легче поддерживать, более вероятно, что люди будут работать с вашим кодом (если вы настроены на совместное участие с другими).
2. Пишите четкие сообщения фиксации
Это кажется очевидным, но все же стоит упомянуть. Когда вы фиксируете код в своем репозитории, пишите четкие и краткие сообщения коммитов, объясняющие, что изменилось и почему. Такой подход помогает вам и вашим соавторам понять историю проекта, упрощая поиск конкретных изменений, когда это необходимо.
3. Не делайте коммитов ненужных файлов
Прежде чем коммитить свой код, просмотрите список измененных файлов, чтобы убедиться, что вы случайно не коммитите что-то, чего не хотите. Легко забыть удалить временные или сгенерированные файлы перед фиксацией, но это может загромождать ваш репозиторий и затруднить поиск важных вещей позже.
4. Держите свои ветки в актуальном состоянии
Если вы работаете над своим проектом с другими людьми, важно поддерживать актуальность ваших веток с последними изменениями [6] из основной ветки. Таким образом, когда вы отправляете запрос на извлечение, не будет конфликтов слияния, и ваше изменение с большей вероятностью будет принято. Конечно, вы не должны слепо принимать каждое изменение из основной ветки — если есть изменения, с которыми вы не согласны, обсудите их со своей командой, прежде чем объединять их в свою собственную ветку.
5. Сгруппируйте связанные коммиты вместе
Если вы вносите несколько связанных изменений в свою кодовую базу (например, добавляете новую функцию и исправление нескольких ошибок), попробуйте сгруппировать эти изменения вместе в один коммит. Таким образом, когда кто-то еще просматривает ваш код, он может увидеть все связанные изменения в одном месте, вместо того, чтобы прыгать туда-сюда между коммитами.
6. Используйте ветки функций для новых функций
Если вы работаете над новой функцией для своего проекта, создайте для нее отдельную ветку вместо того, чтобы работать непосредственно в основной ветке [7]. Таким образом, если ваша функция еще не готова к использованию в прайм-тайм, вы можете оставить ее вне основной ветки до тех пор, пока она не будет готова к слиянию.
7. Пишите тесты для своего кода
Если в вашем проекте есть автоматизированный набор тестов [1] (а он должен быть), убедитесь, что вы написали тесты для своего нового кода перед его фиксацией. Таким образом, вы можете быть уверены, что ваш код делает то, что должен, и что он ничего не сломает при слиянии с основной веткой.
8. Убедитесь, что ваши тесты пройдены перед фиксацией
Говоря о тестах, убедитесь, что все ваши тесты пройдены, прежде чем фиксировать свой код! В противном случае вы можете внести в свою кодовую базу ошибки, которых можно было бы легко избежать. Если возможно, настройте непрерывную интеграцию, чтобы ваши тесты автоматически запускались всякий раз, когда вы фиксируете код.
9. Следуйте руководству по стилю
Если в вашем проекте есть руководство по стилю, убедитесь, что ваш новый код соответствует ему, прежде чем коммитить его. Это не только сделает ваш код более согласованным с остальной частью проекта, но также облегчит чтение и понимание другим людям. Руководство по стилю не является оправданием для небрежного кода — во всяком случае, оно должно улучшить ваш код!
10. Используйте хорошие имена переменных
Выбор хороших имен переменных [2] является важной частью написания читаемого кода. В конце концов, если кто-то не может понять, что должна представлять переменная, он не сможет понять код, который ее использует. Итак, потратьте некоторое время на выбор описательных имен переменных, которые облегчат чтение и обслуживание вашего кода.
11. Не дублируйте код без необходимости
Дублирование кода обычно считается плохой идеей [8], поскольку оно может привести к ошибкам и несоответствиям в будущем. Если вы обнаружите, что копируете фрагменты кода в своем проекте, сделайте шаг назад и посмотрите, есть ли лучший способ структурировать вещи, чтобы вам не приходилось дублировать столько кода.
12. Держите вещи сухими
Связанный с предыдущим пунктом, «Не повторяйся» (DRY) [3] — это принцип разработки программного обеспечения, который гласит, что дублирования следует избегать, когда это возможно. Есть много способов убедиться, что ваш код СУХОЙ. Например, узнайте, как использовать функции или модули.
13. Не используйте неработающий код
Как и предупреждения, неработающий код также говорит вам, что что-то не так. Итак, не совершайте этого! Вместо этого исправьте все ошибки в своем коде перед фиксацией; иначе вы рискуете что-то сломать в процессе разработки.
14. Маркировка релизов
После отправки новой версии программного обеспечения пометьте фиксацию номером версии, чтобы облегчить ее обнаружение позже.
15. Правильное игнорирование файлов
Убедитесь, что вы добавили в файл .gitignore [4] файлы, которые Git не должен отслеживать (например, скомпилированные двоичные файлы).
16. Использование задач GitHub
Отслеживайте ошибки, функции и задачи с помощью GitHub Issues [5] и ссылайтесь на проблемы в своих коммитах, чтобы связать их вместе.
Подумайте о том, чтобы поделиться со мной своими мыслями, если у вас есть какие-либо изменения / исправления, которые вы можете порекомендовать, или рекомендации по дальнейшему расширению этой темы.
Также, пожалуйста, подпишитесь на мой еженедельный информационный бюллетень:
Ссылки:
1. https://github.com/dvsa/mot-automated-testsuite
2. https://docs.github.com/en/actions/learn-github-actions/environment-variables
3. https://deviq.com/principles/dont-repeat-yourself
4. https://git-scm.com/docs/gitignore
5. https://docs.github.com/en/issues
6. Синхронизируйте свои изменения с удаленным репозиторием Git — Azure Repos. https://docs.microsoft.com/en-us/azure/devops/repos/git/pushing
7. GitHub — vtraag/intro-python: введение в Python. https://github.com/vtraag/intro-python
8. Visual Studio 2010: самый простой способ дублировать класс? https://stackoverflow.com/questions/5008893/visual-studio-2010-easyest-way-to-duplicate-a-class
