GitHub: criando um Fork e enviando um Pull Request

Já pensou em contribuir com aquele projeto bacana opensource e deixar sua marca, mostrando que você é uma pessoa aberta a interagir com a comunidade de desenvolvimento? Pois bem, neste artigo vou mostrar como criar um fork de um repositório do GitHub, e depois enviar a contribuição para o autor aprovar. Para nosso exemplo vou usar o projeto Flunt do André Baltieri para sugerir uma alteração.

Primeiro, vamos no repositório do Flunt, no perfil do André, acessando https://github.com/andrebaltieri/Flunt, e então vamos clicar em fork, que irá criar uma cópia de todo o projeto em um repositório na minha conta.

Aguarde o processo terminar.

Agora eu tenho um cópia do projeto em um repositório próprio, onde posso fazer todas as alterações na branch master que eu quiser.

Antes de prosseguir, é preciso criar clone local, clicando em Clone or download, e copiando a URL.

Agora vamos criar um clone no meu computador, usando o comando do Git e para isso abra o Git Bash e cole o endereço, como o exemplo a seguir.

Obs.: Se você for repetir o tutorial, use seus dados de usuário do seu repositório.

Acesse a pasta e abra no Visual Studio o projeto, e abra a classe Notifiable.cs, e nela vamos alterar o trecho de código destacado da linha 12.

Onde temos a variável somente leitura de notifications:

Vamos alterar a declaração usando a sintaxe chamada expression-bodied property, como segue:

Agora vamos fazer upload da alteração via comando do Git, usando a sequência que segue.

Na tela a seguir é mostrado todos os comandos, desde o acesso à pasta até o envio do código.

Abra o o seu repositório pelo site do GitHub, no meu caso, acessando https://github.com/tiagopariz/flunt e clique em Pull requests, em seguida em create a pull request.

Em Comparing changes, clique em compare across forks e por fim clique em Create pull request.

Em Open a pull request, confira a descrição e adicione informações adicionais se assim for necessário, e finalmente clique em Create a pull request.

A alteração será enviado ao dono do repositório, com os detalhes do que irá mudar. 

Pronto, agora é só esperar a aprovação.

Git: convenção para estrutura de pastas

Desde que comecei trabalhar com repositórios de controle de versão do Git, tenho buscado melhores práticas, tanto para armazenar projetos como versioná-los de forma eficiente. Mas o meu espírito metódico começou perceber que as pessoas e empresas armazenavam coisas muito além dos códigos fontes de seus projetos, criando um verdadeiro ambiente com todas informações e ferramentas usadas centralizadas no mesmo repositório, tornando assim algo que pareça realmente um projeto completo.

Acredito que não há um convenção oficial explicando como a estrutura de pastas deveria ser organizada dentro de um repositório, mas encontrei alguns exemplos, nos quais os desenvolvedores justificam suas escolhas, e estas justificativas fazem muito sentido. Portanto, o melhor modelo, na minha opinião, que encontrei foi este:

A solução de organização apresentada, possui uma lógica bem coerente, mas que não está livre de sugestões, adaptações e críticas:

src

Projetos principais, ou seja, o código fonte do produto. Mas é preciso deixar claro que, quando criamos uma nova solução no Visual Studio, o padrão criado não é este, então, é preciso alguns ajustes nos projetos existentes e a criar novo selecionar a pasta.

core

Assim como temos a pasta src na raíz do repositório, podemos criar superclasses genéricas que podem ser reaproveitadas em outras soluções, para isso, é possível criar uma pasta chamada core e dentro dela ter outras pastas de projeto, como src e tests.

tests

Projetos de testes. Embora os projetos de testes possam estar incluídos na mesma solução, nesta convenção, eles são fisicamente alocados em um pasta própria. Mas cuidado para não confundir esta pasta física com as Solution folders, que são diretórios que apenas existem dentro da estrutura de projetos do Visual Studio.

tools

Ferramentas e utilitários em geral. Este diretório serve como apoio ao desenvolvimento do projeto, podendo centralizar softwares, addons, executáveis bibliotecas úteis no dia a dia.

docs

Documentação em geral como arquivos de notas, ajuda, relatórios, etc.

samples

Projetos de exemplo ou exemplos de uso. Esta é uma pasta opcional, mas pode ser útil para demonstrar algum recurso ou funcionalidade na prática.

lib

Coisas que nunca poderão estar em um pacote NuGet, por exemplo.

sql

Arquivos SQL para criação do banco de dados ou para suporte.

artifacts

Armezene aqui as saídas de compilações do produto, todavia, é preciso configurar a IDE para usar esta pasta em seus builds, como por exemplo arquivos nupkgs, dlls, pdbs, etc.

packages

Armazene aqui os pacotes NuGet compilados.

build

Builds dos projetos, assim como scripts de build customizados, como por exemplo, para o Msbuild. Pastas bin e obj. É quase igual ao artefacts, mas difere pela relação com o produto final, sendo que em artefacts serão armazenadas já versão estáveis dos builds e aqui é a pasta de cache para o desenvolvimento do dia a dia, podendo até estar no .gitignore.

build.cmd

Arquivos de comando que geram o build para windows

build.sh

Arquivos de comando que geram o build para unix, linux…

global.json

Arquivo de solução ASP.NET Core

LICENSE

Arquivo que contém a licença de uso do software e seu código fonte

README.md

Arquivo com informações relevantes do projeto em formato markdown, podendo  ser um tutorial ou resultados de testes

Outros arquivos

Os arquivos .editorconfig, .gitignore, .gitattributes são arquivos do Git e/ou para configurações pessoais de editores

NuGet.Config

Arquivo de configuração para pacotes NuGet

Referências:

https://gist.github.com/davidfowl/ed7564297c61fe9ab814
https://github.com/kriasoft/Folder-Structure-Conventions

Git: publicando em dois ou mais servidores de repositórios diferentes

Introdução

Quando pensamos em criar um projeto open-source, é preciso pensar na estratégia de publicação, e muitas vezes não queremos trabalhar direto no GitHub ou outro servidor de repositórios aberto durante algumas etapas de desenvolvimento. Pra isso é possível adotar um forma de publicar em dois locais o mesmo código, com os mesmos commits. Neste exemplo vou abordar uma projeto que nasceria no Git privado, dentro de um servidor de TFS da Microsoft e depois seria publicado em um diretório público do GitHub. Vou mostrar duas maneiras de fazer esta publicação dupla, uma onde os commits são simultâneos e outra onde trabalho em um repositório privado e depois envio o código para o espaço compartilhado.

Publicação simultânea

Crie dois repositórios em servidores diferentes, no caso, eu criei um repositório no TFS e outro no GitHub.

  • GitTFSProject
  • GitHubProject

Abra o GitBash e clone um dos repositórios.

Faça uma alteração no diretório, como incluir um arquivo de texto. Execute o comando:

E agora execute um commit com a devida mensagem:

Adicione a configuração de push para o diretório original:

Em seguida a configuração para o outro servidor:

Execute finalmente o push:

Se quiser ver todos os repositórios que estão configurados, execute:

Referência: https://stackoverflow.com/questions/14290113/git-pushing-code-to-two-remotes

Commits em tempos diferentes

Crie dois repositórios em servidores diferentes, no caso, eu criei um repositório no TFS e outro no GitHub.

  • GitTFSProject
  • GitHubProject

Abra o GitBash e clone um dos repositórios.

Abra o diretório pelo GitBash:

Neste caso, você pode criar uma branch a partir da master, executando o comando:

Faça uma alteração no diretório, como incluir um arquivo de texto. Execute o comando:

E agora execute um commit com a devida mensagem:

Faça mais algumas alterações, para que tenha ao menos 3 commits.

Execute o push e publique a branch.

Agora temos 3 commits com push no TFS.

Vamos alterar o servidor de repositórios para o GitHub e enviar pra lá estes commits.

Agora precisamos executar novamente o processo de publicação da branch e envio dos commits, com o comando:

Então, temos a mesma branch com os mesmos commits no GitHub!

Agora, retorne a configuração de push para a URL original:

Referência: https://git-scm.com/docs/git-remote

Conclusão

Assim é possível criar uma estratégia de publicação de códigos, sem precisar lançar em todos os diretórios ao mesmo tempo.

TFS: criar um projeto com vários repositórios

Muitos projetos são compostos por um arquitetura que envolve mais de uma solução, e pra que isso seja gerenciado como um projeto inteiro, é preciso gerenciar demandas em vários projetos menores. Um cenário bem comum são arquiteturas que usam microservices, onde a mesma equipe desenvolve vários serviços relacionados à uma ferramenta maior, ou quando temos uma aplicação monolítica que está sendo dividida a partir de um repositório único.

A aplicação de exemplo simula um ambiente onde teremos um projeto Rest API, um Gateway e uma aplicação Web que consome a API.

Crie o projeto principal dos repositórios

Abra a página principal dos projetos do TFS e clique em New Project.

Em  Create new project, preencha os campos de Project name, Description, em Version control selecion Git, em Work item process selecione Scrum e então clique em Create.

Crie os repositórios a partir do Visual Studio

Para fins de organização, crie um pasta com o nome do projeto no computador local. Como por exemplo C:\Contacts.

Abra o Visual Studio e em Team, clique em Manage Connections…, em Team Explorer – Connect, clique em Manage Connections, clique em Connect to a Project.

Em Connect to a Project, clique em Showing hosted repositories for e por ultimo em Add an account.

Digite as informações da Conta Microsoft e clique em Sign in, Clique no projeto e por último em Connect.

Crie um nova solução e deixe a opção Create new Git repository clicada.

Faça uma pequena alteração, como incluir uma Solution folder ou um arquivo Readme.md.

Clique o botão direito sobre a Solution e em seguida clique em Commit…

Escreva uma descrição para o commit inicial, e clique em Commit All and Push.

Clique em Publish Git Repo

Clique em Advanced e selecione o projeto em Team project e digite o nome da solução em Repository name, e por fim clique em Publish repository.

Repita o processo para outros repositórios.

Exclua o repositório padrão

O TFS cria um repositório padrão como o mesmo nome do projeto, mas não é possível excluí-lo sem criar um novo repositório, portanto, após criar todos os repositórios necessários, ou menos um extra, é possível deletá-lo.

Na página principal do projeto, clique em Code e em seguida em Manage repositories.

 

Clique em ao lado do repositório que deseja excluir, e clique em Delete repository.

Digite o nome do repositório e clique em Delete.