Лучшая практика рабочего процесса с мерзавцем и GitHub?
Используйте принятый ответ в Генерирующие Случайные Пароли , пока он не будет соответствовать Вашему regexp.
3 ответа
В принципе, вы можете очень хорошо работать с одним «центральным» репозиторием GitHub.
- Теги являются неизменяемыми указателями, их можно использовать (и вставлять) в любое время, чтобы их можно было проверить в любой тестовой или производственной среде. Это позволяет провести некоторую проверку, но обычно не служит для разработки.
- Вытягивание ветки означает, что вы можете внести некоторые изменения в эту ветвь (из-за некоторых исправлений и корректировок, которые необходимо внести, когда код находится в производственной среде) и вернуть его в репозиторий всех других разработчиков, чтобы они могли откатиться и принять во внимание.
Так что это зависит от того, что вы делаете на этих серверах: только проверка (со статусом принято или отклонено) или также дальнейшие разработки.
В любом случае тег с соответствующим соглашением об именах удобен для отслеживания конкретных коммитов в истории, но ветки необходимы каждый раз, когда вам нужно изолировать усилия по разработке.
На GitHub я использую одну учетную запись для своей компании, в которой живет «благословенный» код; Затем я поддерживаю личный форк, где работаю над вещами, которые еще не совсем стабильны. На моем локальном компьютере я обрабатываю оба в одном репо, так что master - это благословенный код (и отправляет его в учетную запись компании), в то время как все другие ветки предназначены для моей вилки. Вот часть моего .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.
Прочтите книгу Pro Git . Вы можете читать справочные страницы git в течение года и все равно не понимать: пытаться изучить git, читая справочные страницы, все равно что пытаться выучить новый язык, читая словарь, это можно сделать. Книга научит вас нескольким рабочим процессам, которые можно использовать с git, и тем, какие команды git использовать и в каком контексте их использовать.