Лучшая практика работы с git и github?

Question

Я использую git и github со своей небольшой командой разработчиков для наших проектов.Я не могу отделаться от мысли, что мы делаем это неправильно.Мне интересно услышать, как другие используют этот рабочий процесс в своих проектах.

Как мы это используем: Мы разветвляемся перед каждым изменением, сливаемся обратно в мастер, фиксируем локально и отправляем в наше репозиторий github.Затем мы подключаемся по ssh к нашей тестовой среде и извлекаем главную ветвь репозитория github.Мы еще не совсем поняли rebase, fetch или tagging только пока.

Как бы я хотел это использовать: Я хотел бы иметь возможность подключаться по ssh к разным серверам и загружать на сервер определенную помеченную версию, например "phase 1".Возможно ли это, или мне понадобятся два разных репозитория github?

А ты должен это делать git pullопределенную ветку на веб-серверах или создайте новый псевдоним для git push кому?

Можете ли вы контролировать кандидатов на выпуск или среды (тестирование, разработку, продакшн) в рамках одного репозитория git?или вам нужно несколько?

Если вытягивание - это решение, можете ли вы вытянуть конкретное tag ?

Answer 1

В принципе, вы можете очень хорошо функционировать с одним "центральным" репозиторием GitHub.

• Теги, являющиеся неизменяемыми указателями, могут быть использованы (и отправлены) в любое время для проверки в любой тестовой или производственной среде.Это позволяет выполнить некоторую проверку, но обычно не служит для разработки.
• Извлечение ветки означает, что вы можете внести некоторые изменения в эту ветку (из-за некоторых исправлений ошибок и корректировок, которые необходимо внести, как только код будет размещен в производственной среде), и отправить его обратно во все другие репозитории разработчика, чтобы они отклонили и приняли во внимание.

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

Answer 2

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

Answer 3

На GitHub я использую одну учетную запись для своей компании, которая является "благословенной". код жизни; Затем я поддерживаю личную вилку, где я работаю над вещами, которые еще не совсем стабильны. На моем локальном компьютере я работаю с обоими в одном репо, так что мастер - это благословенный код (и отправляет на учетную запись компании), а все остальные ветви - для моего форка. Вот часть моего .git / config:

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = git@github.com:xiongchiamiov/fourU.git
[branch "hacking"]
        remote = origin
        merge = refs/heads/hacking
[branch "editor"]
        remote = origin
        merge = refs/heads/editor
[branch "problem-utils"]
        remote = origin
        merge = refs/heads/problem-utils
[branch "tests"]
        remote = origin
        merge = refs/heads/tests

[remote "trunk"]
        fetch = +refs/heads/*:refs/remotes/trunk/*
        url = git@github.com:xyztextbooks/fourU.git
[branch "master"]
        remote = trunk
        merge = refs/heads/master

Поскольку у меня есть разрешения на коммиты для репозитория компании, я могу просто объединить (или выбрать вишню) коммиты из одного филиала в другой и перенести его в соответствующее место. Теперь отдельные репозитории, разумеется, не нужны, но, поскольку это проект с открытым исходным кодом, я хотел бы сохранить " официальный " репо без случайных веток, созданных моими касательными. Как только он достигнет точки, где он получит версионирование, появится ветвь 0.x с тегами для каждой версии (0.1, 0.1.1, 0.2 и т. Д.), Что особенно выгодно, потому что github автоматически создает тарболы файлов на каждом теге, отлично подходит для загрузки определенной версии на машину, которая не нуждается в полной истории.

Вы должны прочитать блог GitHub; у них были хорошие посты, описывающие их рабочий процесс развертывания, который, конечно, в значительной степени связан с git.