Лучшая практика рабочего процесса с git и github? - PullRequest
Новая
       9

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

21 голосов
/ 22 октября 2009

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

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

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

Предполагается, что вы git pull определите ветку на веб-серверах или создадите новый псевдоним git push для?

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

Если решение проблемы - это вытащить конкретную tag?

Ответы [ 3 ]

16 голосов
/ 24 ноября 2009

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

8 голосов
/ 22 октября 2009

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

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

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

4 голосов
/ 03 ноября 2009

На 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.

...