Como usar o github, branches e lançamentos automáticos para gerenciamento de versões? [fechadas]

Eu já entendo a maioria dos conceitos básicos do Git / Github, mas ainda tenho problemas para entender o cenário geral.

Estas são algumas das coisas que consegui trabalhar até agora:

• Enviar confirmações por push
• Trabalhar com ramificações
• Integre o Github ao Travis CI, um sistema de integração contínua
• Via Travis CI, construa automaticamente todos os commit para dominar e coloque o release como ZIP no Github em releases.

No entanto, eu só trabalhei em versões alfa / beta de projetos até agora, então nunca vi lançamentos de versão em prática ainda.

Portanto, quero aprender mais sobre controle de versão, manutenção de versões separadas, hotfix das versões, etc.

Como garantir que as seguintes coisas aconteçam:

• Tenho versões diferentes do meu projeto, por exemplo, versões 1.1.0 e 2.0.0
• Tem a capacidade de enviar hotfixes nas versões, passando a versão para 1.1.1 ou 2.0.1 etc.
• Faça com que um sistema de integração contínua construa essa versão automaticamente no commit e, se for bem-sucedido, publique um release para essa versão específica.

Estou duvidando das seguintes opções:

• Preciso usar tags para todas as versões? Em caso afirmativo, como um sistema de integração contínua cria versões automaticamente?
• Devo criar ramificações para todas as versões? Nesse caso, isso não criaria uma tonelada de ramificações (como uma ramificação 1.1 e 2.0, os hotfixes vão para essa ramificação, é claro)
• Como especificaria o número da versão? É bom ter um arquivo de configuração que especifique o número da versão ou há maneiras mais inteligentes de contornar isso? Nesse caso, seria um projeto Java, se isso importa.

Você deve olhar para o fluxo git . É um excelente (e popular) modelo de ramificação.

Resumo do fluxo Git

Ramificação

Os principais troncos que ficam para sempre são develope master. mastermantém sua versão mais recente e developsua cópia de desenvolvimento "estável" mais recente.

Os colaboradores criam featureramificações (prefixadas feature/por convenção) com develop :

$ git checkout -b feature/my-feature develop

e hotfixfiliais (prefixadas hotfix/por convenção) de master:

# hotfix the latest version of master
$ git checkout -b hotfix/hotfix-version-number master

# or hotfix from a specific version
$ git checkout -b hotfix/hotfix-version-number <starting-tag-name>

Esses galhos são "descartáveis", o que significa que eles têm uma vida útil curta antes de serem mesclados de volta aos troncos principais. Eles destinam-se a encapsular pequenos pedaços de funcionalidade.

Ramos de acabamento

Quando um colaborador termina uma featureramificação, ele o mescla novamente develop:

$ git checkout develop
$ git merge --no-ff feature/my-feature
$ git branch -d feature/my-feature

Quando eles terminam com uma hotfixramificação, eles os mesclam novamente nos dois mastere, developportanto, o hotfix avança:

$ git checkout master
$ git merge --no-ff hotfix/hotfix-version-number
$ git checkout develop
$ git merge --no-ff hotfix/hotfix-version-number
$ git branch -d hotfix/hotfix-version-number

Este é o aspecto da integração contínua.

Lançamentos

Quando você estiver pronto para iniciar o empacotamento de um release, crie uma releaseramificação a partir da ramificação "estável" develop(o mesmo que criar featureramificações). Você então colide com o número da versão em uma tag (descrita abaixo).

O uso de releaseramificações separadas permite continuar desenvolvendo novos recursos developenquanto você corrige bugs e adiciona retoques finais à releaseramificação.

Quando você estiver pronto para concluir o lançamento, mesclar o releaseramo em ambos mastere develop(como em hotfix) para que todas as suas alterações sejam levadas adiante.

Marcação

Ao criar uma releaseramificação ou hotfixramificação, você aumenta o número da versão adequadamente em uma marca. Com o vanilla git, fica assim:

$ git tag -a <tag-name> -m <tag-description>

Você também precisará enviar as tags (separadamente) para o seu repositório remoto:

$ git push --tags

Geralmente, é melhor usar versões semânticas nas quais suas versões assumem a forma major.minor.hotfix. Os grandes saliências são incompatíveis com versões anteriores, enquanto os pequenos e com hotfix não são incompatíveis com versões anteriores (a menos que você esteja na versão beta 0.x.x).

Mesclando

Como você viu acima, o git-flow incentiva você a mesclar ramificações com o seguinte comando:

$ git merge --no-ff <branch-name>

A --no-ffopção permite que você mantenha todo o seu histórico de ramificações sem deixar um monte de ramificações no commit atual do repositório (portanto, não se preocupe, você não terá uma ramificação para todas as versões).

Você também é incentivado a puxar com

$ git pull --rebase

Portanto, você não adiciona muitos commits de mesclagem inúteis.

Você pode configurar o git para fazer essas duas coisas por padrão no seu .gitconfig. Eu vou deixar você procurar isso;)

Navegando nas versões

Quando alguém procura uma versão específica da sua base de código, pode fazer o checkout da tag pelo nome:

# checkout in detached HEAD to browse
$ git checkout <tag-name>

# OR checkout and create a new local branch (as you might for a hotfix)
$ git checkout -b <new-branch-name> <tag-name>

Ou, se alguém estiver navegando no github, também haverá uma guia "tags" no menu suspenso "branches".

Usando a extensão git-flow (recomendado)

Minha maneira favorita de usar esse modelo é com a extensão git flow para git.

( Edit: Louis recomendou o garfo AVH que funciona melhor git describee pode estar mais ativo agora. Obrigado Louis.)

A extensão automatiza todas as partes confusas (como usar merge --no-ffe excluir ramificações após a mesclagem) para que você possa continuar sua vida.

Por exemplo, com a extensão, você pode criar uma ramificação de recurso assim:

$ git flow feature start my-feature-name

e termine assim

$ git flow feature finish my-feature-name

Os comandos para hotfixes e releases são semelhantes, embora eles usem o número da versão no lugar do nome de uma filial, assim:

# Create hotfix number 14 for this minor version.
$ git flow hotfix start 2.4.14

# Create the next release
$ git flow release start 2.5.0

O Git flow então cria a tag version para você e lembra-o de aumentar a versão em qualquer configuração ou arquivo de manifesto (o que você pode fazer com um gerenciador de tarefas como o grunt).

Espero que ajude :) Não sei exatamente como você integraria tudo isso à sua configuração do Travis CI, mas acho que os githooks o levarão até lá.

Preciso usar uma tag para todas as versões?

Não, você não precisa usar tags. Se você quiser marcar todas as versões, tudo bem, ou se quiser marcar todas as vezes que o sistema de IC for criado, você também pode fazer isso. As tags estão basicamente fornecendo um nome amigável ao commit, para que você possa acessá-lo facilmente e visualizá-lo mais tarde.

Devo criar ramificações para todas as versões?

Certo! A ramificação é barata / gratuita no Git, então eu aproveito todas as chances que tenho. Você também pode mesclar e excluir ramificações rapidamente. Se você acha que tem muitos ramos, sempre poderá reduzi-los mais tarde com alguma fusão seletiva. Existem vários esquemas de ramificação do Git disponíveis também se você quiser usar um esquema testado e verdadeiro.

Como especificaria o número da versão?

As tags geralmente são da maneira que você especifica o número da versão, no que se refere ao git. Se você está falando sobre como fazer a versão de um projeto, ou a melhor maneira de fazer isso, precisará escavar algumas vezes, pois é uma pergunta bastante baseada em opiniões. Alguns projetos ficam na versão beta para sempre, outros aumentam versões de números inteiros como se estivessem ficando fora de moda (olhando para você no chrome)

Preciso usar tags para todas as versões?

Se por "versão" você quer dizer um conjunto de arquivos que compõem um release ou um candidato a lançamento, recomendo fortemente que você marque todas as versões. Se você precisar consultar a versão 1.2.7 no futuro, deseja procurar o hash de um commit ou apenas usar o número da versão?

Além disso, se você usa git describepara gravar informações de compilação em algum lugar (como eu faço), o uso de tags permite fornecer uma saída muito melhor.

Em caso afirmativo, como um sistema de integração contínua cria versões automaticamente?

Um sistema de integração contínua pode criar releases independentemente de como você usa tags. Você poderia dizer para criar uma liberação com base no hash de uma confirmação. Tags tornam sua vida mais fácil.

Devo criar ramificações para todas as versões? Nesse caso, isso não criaria uma tonelada de ramificações (como uma ramificação 1.1 e 2.0, os hotfixes vão para essa ramificação, é claro)

Não vejo ramificação como algo "por versão". Eu tenho alguns projetos em que minhas versões são confirmadas no masterramo. Por enquanto, não preciso de nada mais complicado do que isso, porque nenhum dos projetos está no estágio estável e não há necessidade de oferecer suporte a versões antigas a longo prazo. Mas digamos que eu libero a versão 1.0, 1.1, 1.2 e, em seguida, a versão 2.0 e ainda tenho que dar suporte à série 1.0 com correções de segurança etc. .

Como especificaria o número da versão? É bom ter um arquivo de configuração que especifique o número da versão ou há maneiras mais inteligentes de contornar isso? Nesse caso, seria um projeto Java, se isso importa.

Ter uma única fonte para o número da sua versão, como um arquivo de configuração, é a melhor maneira, pois evita erros de dedos grossos que de outra forma podem ocorrer se você precisar atualizar números em vários locais. Estou falando de ... hmm ... experiência embaraçosa. Você libera a 1.3 e descobre que o software ainda informa que é a versão 1.2. Opa!

Em outra resposta, mxdubois recomendou o gitflow para você. Se você decidir usar o gitflow, recomendo usar a edição AVH . A versão original não é mais mantida ativamente. Uma diferença notável é que a edição AVH realiza mesclagens de release que permitem git describetrabalhar de forma inteligente. A versão original executa a mesclagem de uma maneira que desarmagit describe .

Digitalizando sua lista, vejo a versão como seu foco, então ...

Uma maneira de manter versões é com ramificações e mesclagem (ou rebasing).

Então você tem:

master

então você cria uma ramificação

v1

você adiciona mais alterações a

master(diff1)

então você cria uma ramificação

v3

você adiciona mais alterações a

master(diff2)

Agora:

Para atualizar a versão 2, agora você faz

git checkout v2
git merge master  # for the changes you want to bring into version 2
# rebasing is also an option
# resolve any merge conflicts
# Done.

Para atualizar a versão 3

git checkout v3
git merge master

O acima é para atualizações por atacado.

Provavelmente, é mais provável que você queira escolher alterações específicas para que haja

git cherry-pick

Mais sobre a escolha de cerejas em http://git-scm.com/docs/git-cherry-pick