DEV Community: Jhony Walker

Times - 7 dicas para uma melhor programação em pares

Jhony Walker — Sun, 11 Sep 2022 00:34:00 +0000

A colaboração eficaz é uma das principais características de qualquer equipe produtiva. Todo mundo pensa de forma diferente, então ter um segundo par de olhos em um problema pode oferecer vários pontos de vista e abordagens que você poderia ignorar. Para programadores, a forma mais comum disso é a programação em pares.

Às vezes, a programação em pares tem uma má reputação. Os críticos argumentam que colocar dois desenvolvedores na mesma tarefa diminui a velocidade geral da equipe, mas economiza tempo no grande esquema das coisas. A programação em par não apenas produz código de maior qualidade, mas também ajuda os desenvolvedores a resolver problemas rapidamente e remover bloqueadores. Eu tenho programado muito em pares com meus colegas recentemente, então gostaria de compartilhar algumas dicas para tirar o máximo proveito disso.

Concentre-se nas partes desafiadoras primeiro

Cada sessão de programação em pares difere, mas o objetivo geralmente é consistente. Na maioria das vezes, você está tentando desenvolver uma solução para algum problema complicado que merece dois pares de olhos. Enquanto alguns desenvolvedores podem preferir tirar as coisas simples do caminho primeiro, eu gosto de atacar o cerne do problema antes de fazer qualquer outra coisa.

As partes fáceis geralmente são tarefas que eu mesmo posso fazer rapidamente ou tarefas mundanas que são mais trabalhosas do que qualquer outra coisa. Ao trabalhar com alguém, não quero desperdiçar seu tempo e fazê-los me ver escrever documentação para minha interface ou adicionar log de erros. Eu prefiro pular e atacar os desafios que precisam de duas pessoas para resolver.

Deixe para trás sinais para você limpar mais tarde por conta própria, como comentários ou TODOs. Defina cabeçalhos e classes de métodos vazios que podem ser implementados posteriormente ou preencha partes com pseudocódigo.

Não se preocupe com o perfeccionismo

Com base no último ponto, geralmente tento evitar picuinhas ao programar em par. Há um tempo e um lugar para lêndeas. Para mim, geralmente é no final quando eu repasso o código que foi escrito e o limpo para que eu possa enviá-lo para revisão. Insistir em um código quase perfeito é razoável no estágio de limpeza, mas se você ainda estiver na fase de resolução de problemas, então a picuinhas apenas atrasa as coisas, é obvio que você não vai disponibilizar um código mal feito em produção, a ainda não se esqueça que tem o PR que a galera enfatiza pontos de melhoria.

Mude isso

Por mais que eu ame estar no banco do motorista, é bom mudar as coisas ocasionalmente e assumir o papel de banco de trás. Observar como outra pessoa trabalha pode ser tão perspicaz quanto fazê-lo você mesmo. Gosto de observar como eles abordam os problemas e os passos que dão para superá-los. Às vezes, isso me ajuda a aprender novas técnicas que posso aplicar a outras situações.

Por outro lado, tente tomar as rédeas se você costuma ser o observador. Às vezes, você só precisa sentir o problema com suas próprias mãos para entender o ambiente e as condições com as quais está trabalhando. A experiência prática geralmente é a maneira mais eficaz de aprender e desenvolver suas habilidades. Ter um parceiro para programar atua como uma rede de segurança para ajudá-lo a escrever código de boa qualidade e superar rapidamente problemas e bloqueios.

A programação em pares é uma via de mão dupla... se você só vai em uma direção, você não consegue ver o outro lado, e nem seu parceiro. Certifique-se de que ambos pratiquem os dois lados da experiência, e você ficará melhor no final por isso.

Mantenha as coisas casuais

Às vezes, sinto que posso sofrer de ansiedade de desempenho. Quando estou sendo observado, é como se meu cérebro desligasse completamente. Eu esqueço como digitar, cometo muitos erros bobos e não consigo pensar direito. Mesmo o pensamento de programação em par costumava me fazer começar a suar nervosamente. Entenda suas dificuldades e supere-as!

Considere que seu parceiro pode estar se sentindo assim ao entrar em sua sessão. Alternativamente, você pode ser o único a se sentir ansioso. A programação em pares deve ser produtiva, não estressante. Certifique-se de que você e seu colega estejam confortáveis e não tenha medo de falar se algo estiver incomodando durante o processo.

Escusado será dizer que você deve ser respeitoso com seus colegas de trabalho (isso é obvio). Não os assedie por cometerem erros ou digitarem devagar. Não há nada a ganhar com tal comportamento. Nem todo mundo pode fazer o seu melhor quando os outros estão assistindo e isso não os torna inferiores ou incapazes de executar a tarefa que lhe foi proposta.

Esteja aberto a novas ideias

Isso se aplica a todos os aspectos da engenharia de software, mas é especialmente verdadeiro para programação em pares. Não destrua todas as ideias do seu parceiro porque elas não combinam com suas próprias filosofias. Isso apenas anula o propósito de trabalhar juntos em primeiro lugar.

Se uma ideia realmente não for viável, converse sobre ela primeiro e explique por que você acha que ela não funcionará, em vez de desconsiderá-la completamente. Ao falar sobre isso, você pode encontrar uma maneira de adaptá-lo em algo viável. Na pior das hipóteses, sempre vale a pena documentar quais opções foram consideradas, mesmo que não tenham sido aplicadas no final.

Defina um limite de tempo

Uma reclamação que tenho sobre programação em par é que às vezes é difícil encontrar um bom ponto de parada. Nessas situações, parece que a sessão se arrasta por muito tempo e passo mais tempo do que pretendia. Antes de começar, considere definir um limite de tempo rígido ou flexível apenas por precaução, entenda que o colaborador que irá “codar” com você tem outras tarefas e não pode ceder muito do tempo para estar mais de 1 hora em conjunto com você.

A duração ideal da sessão é a preferência pessoal, mas gosto de manter minhas sessões em torno de 30 minutos. Normalmente, planejo-os com antecedência e crio um evento de calendário para eles para que eu possa incorporá-los adequadamente à minha agenda e a delas consequentemente.
Uma nota sobre funções

Os livros didáticos ágeis falam sobre vários estilos de programação em pares com papéis definidos. Exemplos comuns incluem os estilos driver-navigator e ping-pong. Se você quiser usar um desses, tudo bem, mas geralmente não limito minha estratégia às especificidades de um desses estilos. Quando estou programando em pares, não estabeleço explicitamente regras sobre funções ou qualquer coisa. Eu apenas faço o que vem naturalmente para meu parceiro e para mim. Concedido, eu normalmente gosto mais do estilo clássico de navegador de driver, onde uma pessoa escreve o código enquanto a outra apresenta as ideias.

O desenvolvedor menos experiente deve ser o driver na maioria dos cenários. Implementar o projeto de um engenheiro sênior em uma sessão de programação em pares é uma experiência de aprendizado fantástica, pois ajuda você a absorver a ideia e entender os detalhes do esquema sugerido.
Desenvolvedores experientes também podem se beneficiar da programação em pares, mas, pela minha experiência, essas sessões são melhores quando as sessões são mais curtas e mais focadas. Engenheiros seniores geralmente são melhores em pegar uma ideia e executá-la, então trabalhar juntos em toda a implementação nem sempre é necessário.

Aprendizado

A programação em pares é uma prática comum em qualquer trabalho de tecnologia, portanto, ficar confortável com isso e aprender a fazê-lo bem é uma ótima maneira de obter uma vantagem extra em sua produtividade. Existem muitas variações dessa prática, então sinta-se à vontade para brincar com diferentes estilos e encontrar o que funciona melhor para você. O conselho que escolhi apresentar aqui pretendia ser aplicado a qualquer forma de programação em par e não limitando apenas a programação, tarefas em pares com uma pessoa que possui uma experiência maior do que a sua ou é novo na área, mas tem vivência em outras vertentes, pode ter certeza que vai ser super enriquecedor para vocês e acharam a solução do problema de forma bem mais rápida. Entenda e tenha a humildade de admitir que não sabemos tudo, independente da idade ou anos de experiência sempre aprendemos algo novo com as pessoas.

Hacks do Github - Criando seu Octocat único

Jhony Walker — Fri, 17 Jun 2022 02:43:54 +0000

O Github é cheio de funcionalidades e o mais utilizado isso vocês já sabem e pensando nisso que criei essa série de hacks porém, esse é nosso último post dessa série... fica tranquilo a qualquer momento podemos retornar com novos hacks.

⚠️ Importante: Os prints que serão exibidos para exemplificar podem estar diferentes da interface do seu GitHub, por que sou muito adepto a extensões que melhoram a usabilidade e que ajudam no meu dia a dia. Partindo desse ponto peço que dê uma olhada nesse artigo antes.

Esse hack é diferente, pois se trata de uma ferramenta que foi disponibilizada pela equipe do Github onde você pode criar seu próprio octocat (o mascote do Github)

Mãos na massa

Para criamos é necessário acessar [este link] onde teremos um site dedicado a edição do seu octocat na maneira que quiser

Caso antes de iniciar o processo você queira, uma inspiração podemos acessar a galeria onde visualizaremos todos os já criados e podemos ver o quanto o pessoal é criativo:

Depois dessa inspiração é só começar a criar o seu octocat, basta clicarmos no botão Create Your Octocat ou Get Started. Será apresentado a versão original então basta começar a edição de cada componente:

Compartilhando seu Octocat

Depois de pronto, precisamos clicar no botão de Share e enviar para seu e-mail ou Twitter. Mas ainda temos algo mais prático: tire um print de tela marcando somente a área do seu octocat, simples assim.

Agora deve estar se perguntado o que fazer com isso? Parece meio obvio, mas você pode fazer o que quiser! Colocar no seu Readme, criar um sticker ou até uma camiseta, tudo será limitado apenas a sua criatividade.

Fontes onde pesquisei esse conteúdo:

https://myoctocat.com/build-your-octocat/

Hacks do Github - Hospedando seu site no Github

Jhony Walker — Fri, 17 Jun 2022 02:18:36 +0000

O Github é cheio de funcionalidades e o mais utilizado isso vocês já sabem e vamos continuar a série de "hacks" da plataforma que vão otimizar e melhorar sua experiência.

Sabemos que eu podemos usar o Github para versionar nossos sites porém, existe também a possibilidade de nosso site poder ficar hospedado no Github (for free), e ser executado diretamente de lá, sem a necessidade de um servidor!

Uma ponto importante que precisamos frizar antes de começar e que o Github só aceita arquivos estáticos. Não adianta querer usar o Github para hospedar um site em PHP ou aquela API Node que não vai funcionar. Ele só vai funcionar com os arquivos estáticos gerados - HTML, CSS e JS, imagens, fontes, etc.

Para se aproveitar dessa feature, podemos cair em duas situações:

1ª) Tenho um site pessoal que quero hospedar no Github
2ª) Tenho um projeto Open Source, em um repositório dentro da minha conta, e quero criar um site para ele.

Site Pessoal

Para a situação do site pessoal, devemos fazer o seguinte:

Primeiro de tudo criaremos um novo repositório na nossa conta, com o seguinte padrão:

username.github.io

Obviamente, trocando username pelo seu nome de usuário no Github. Fazendo isso, você pode subir seus arquivos estáticos para a branch master normalmente, e acessá-los pelo endereço:

https://username.github.io

Site para projeto open source

Se temos um projeto open source no Github, e queremos criar um site para ele, precisaremos fazer o seguinte:

Criar uma branch em branco chamada gh-pages. Para criar uma nova branch em branco, usaremos o seguinte comando:

git checkout --orphan gh-pages

Depois subir os arquivos para essa branch.

Só lembre de NUNCA fazer merge dessa branch na master. Os arquivos das duas branches serão completamente diferentes! Na master, ficarão os arquivos do seu projeto. Na gh-pages, somente os estáticos do site do projeto. Vamos conseguir acessar pelo seguinte endereço:

https://username.github.io/repositoryname

Além de trocar o username para o nome do seu usuário deveremos trocar o repositoryname pelo nome do nosso repositório.

Usando um domínio personalizado

Para usar um domínio personalizado, você só precisa criar um arquivo chamado CNAME na branch onde estão os estáticos do seus site e o conteúdo dele deve ser o seu domínio. Por exemplo:

blog.test.com.br

Não precisa do http(s) pode ficar tranquilo. Depois você só precisa configurar para que o seu domínio aponte para os DNS do Github. Para fazer isso, siga esse tutorial.

Fontes onde pesquisei esse conteúdo:

Hacks do Github - Commits que fecham issues

Jhony Walker — Fri, 17 Jun 2022 01:57:26 +0000

O Github é cheio de funcionalidades e o mais utilizado isso vocês já sabem e vamos continuar a série de "hacks" da plataforma que vão otimizar e melhorar sua experiência.

Abre uma issue, resolve o problema, commita, faz o push, fecha a issue. Abre uma issue, resolve o problema, commita, faz o push, fecha a issue. E se eu te disse existe uma forma de automatizar esse processo?

Essa coisa de ficar lembrando de fechar a issue logo após a sua solução, em alguns casos, torna-se bastante chato e repetitivo. O Github tem um hack, onde você consegue fechar uma issue através de uma mensagem de commit.

Entendendo o hack

Você já deve saber que inglês é essencial hoje em dia. Quando codificamos, principalmente se pretendemos colaborar com projetos Open Source, deveríamos escrever seus nomes de funções, métodos, variáveis, entre outras coisas tudo em inglês, correto? Pois assim, mais pessoas poderão ter acesso ao projeto, já que inglês é uma linguagem mundial!

E com o Github não seria diferente, existe algumas palavras mágicas que podemos utilizar na mensagem de commit, para fechar uma issue. Precisamos referenciar também, o ID da issue (aquele número que aparece na URL quando você acessa a issue). E essss palavras mágicas são:

fix, fixes, fixed, close, closes, closed, resolve, resolves, resolved

Então podemos escrever a mensagem de commit mais ou menos assim:

git commit -m "Fix error on issue #32"

Usando uma das palavras mágicas, e referenciando a issue com a hash # + número/ID da issue, essas informações só precisam aparecer na mensagem de commit, não precisam ter uma ordem específica, nesse exemplo a issue #32 será fechada.

Essa é uma dica bem simples, mas que pode te poupar muito tempo com seus projetos open source.

Fontes onde pesquisei esse conteúdo:

https://docs.github.com/pt/issues/tracking-your-work-with-issues/about-issues

Hacks do Github - Licenças

Jhony Walker — Fri, 17 Jun 2022 01:44:34 +0000

O Github é cheio de funcionalidades e o mais utilizado isso vocês já sabem e vamos continuar a série de "hacks" da plataforma que vão otimizar e melhorar sua experiência.

No mundo do software, o que define como aquele software será distribuído, se o software será pago, se outras pessoas poderão distribuí-lo sem problemas, ou terão que pagar por isso, Ou ainda podem distribuir o software, mas terão que citar o autor são as famosas Licenças. Mas nesse post não vou entrar em muitos detalhes sobre as licenças (farei um post somente dedicados a elas posteriormente). Hoje falaremos sobre como o Github nos ajuda com elas.

Aprofundando nas licenças

Quando colocamos nosso código na internet, ele fica disponível para milhões de pessoas o aproveitarem como bem entenderem. Algumas irão utilizar seu código, citando que você é o autor, outras simplesmente irão copiá-lo, como se fossem os próprios autores. O que te “garante” algo é a licença que você disponibiliza junto com seu código e existem vários tipos delas sendo algumas das mais utilizadas conhecidas: MIT, GPL, LGPL, BSD.

Mas o que o Github tem a ver com isso? Quando você cria um novo repositório, o Github te dá a opção de adicionar uma licença:

Mas caso tenha um projeto, e não tenho uma licença ainda podemos escolher a opção de criar o arquivo de licença através do link +, mostrado abaixo:

Então será apresentado a tela para criar um novo arquivo:

Coloque o nome do arquivo como LICENSE, e veja a mágica acontecer. Agora basta escolher uma licença, e salvar ao fazer isso, já fica registrado um novo commit com a alteração, mas claro não se esqueça da conveção dos commits semânticos para ficar bem organizado.

Fontes onde pesquisei esse conteúdo:

https://docs.github.com/pt/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository

Hacks do Github - Parâmetros na URL

Jhony Walker — Fri, 17 Jun 2022 01:25:02 +0000

O Github é cheio de funcionalidades e o mais utilizado isso vocês já sabem e vamos continuar a série de "hacks" da plataforma que vão otimizar e melhorar sua experiência.

Hoje é dia de falar um sobre alguns parâmetros na URL e ver o que podemos fazer com eles.

Ignorando espaços em branco no commit

Sabe quando você tem um commit onde tem um monte de espaços em branco sendo removidos, e fica difícil visualizar onde realmente foi alterado no código? Então, se passarmos ?w=1 na URL, o Github ignora os espaços em branco, e mostra só o que realmente é necessário e que você realmente quer saber.

Tamanho da tabulação

Sabe aquele código indentado com 4 tabs que fica com tamanho de 8 em qualquer outro lugar diferente do seu editor? Sim, mesmo você jurando que usou a tríade de formatação ele ainda corre o risco de ocorrer esse problema. Então passando o parâmetro ?ts=4, o Github mostra o código indentado com o valor passado para o parâmetro ts. No nosso caso vai ser 4.

Separar commits por autor

Quer rever só os seus commits que você ou um usuário específico fez naquele projeto open source, mas tem outros milhões de colaboradores? Nesse caso, podemos adicionar o parâmetro ?author=username, passando o seu username do Github (ou o que deseja) para mostrar somente eles.

O hack que hoje foi bem rápido e ao invés de colocar os prints com os exemplos na prática eu quero que você faça veja a mágica acontecer.

Fontes onde pesquisei esse conteúdo:

https://docs.github.com/pt/enterprise-server@3.1/developers/apps/building-github-apps/creating-a-github-app-using-url-parameters

Hacks do Github - Incentive a contribuição para seus projetos open source

Jhony Walker — Fri, 17 Jun 2022 00:58:05 +0000

O Github é cheio de funcionalidades e o mais utilizado isso vocês já sabem e vamos continuar a série de "hacks" da plataforma que vão otimizar e melhorar sua experiência.

Contribuir para projetos open source é algo que nos faz crescer muito como profissionais. Temos a oportunidade de aprender coisas novas e praticar o que muitas vezes não utilizamos comumente no nosso dia-a-dia.

Cada pessoa que cria um projeto open source tem sua forma de escrever seus códigos, organizar a estrutura de arquivos, etc. Se o projeto é interessante, outras pessoas acabam ficando interessadas em contribuir. Mas a frustração vem quando descobrimos que cada um escreve seu código de uma forma: alguns usam tabs, outros espaços; uns preferem 4 espaços, outros preferem 2; colocar espaço entre o if e os () ou não, escrever o else em uma nova linha, ou na mesma linha do fechamento do } e assim por diante. Nenhuma destas formas estão erradas, São apenas diferentes modos de escrever o mesmo código! Mas se um mesmo código tiver várias dessas formas misturadas, o projeto vai acabar virando uma zona o famoso padrão sem padrão.

Então, normalmente colocamos no README.md do repositório uma área de como contribuir, citando os padrões que você utilizou no código, mostrando como criar uma nova feature, bugfix entre outras coisas. Mas no momento de empolgação, muitas vezes os devs nem chegam nessa parte do seu README.md (aposto que você mesmo já passou batido), e acabam enviando pull requests com seus próprios padrões.

O arquivo CONTRIBUTING.md

Uma feature bem simples do Github, mas que pode ajudar a organizar melhor a colaboração nos seus projetos e que poucos conhecem, é a adição de um arquivo chamado CONTRIBUTING.md. Nesse arquivo você coloca tudo o que a pessoa que vai colaborar com o seu projeto precisa saber e quando criamos esse arquivo, sempre que alguém for criar uma nova issue ou enviar um pull request, olha o que vai aparecer pra ele:

O guidelines for contributing que aparece na mensagem acima, é linkado diretamente com o nosso arquivo CONTRIBUTING.md! Assim, sempre que alguém for colaborar, ele verá esse aviso, e ainda que não leia o README.md, verá que existem alguns padrões a serem seguidos para que ele possa contribuir.

Fontes onde pesquisei esse conteúdo:

https://github.com/github/docs/blob/main/CONTRIBUTING.md

Hacks do Github - Imagens

Jhony Walker — Fri, 17 Jun 2022 00:40:46 +0000

O Github é cheio de funcionalidades e o mais utilizado isso vocês já sabem e vamos continuar a série de "hacks" da plataforma que vão otimizar e melhorar sua experiência.

Nada como alegrar aquela mensagem de commit, o comentário de uma issue ou um pull request com os famosos os emojis, e para utiliza-los, basta você colocar o nome do emoji entre dois-pontos: :emoji-name:. Alguns exemplos se encontram nesse site incrível ou se preferir pode acessar esse repo que apresenta diversos exemplos (assim acho que na verdade são todos)

Imagens / GIFs

Podemos usar qualquer imagem ou gif em qualquer lugar que aceite markdown no Github: issues, pull requests, arquivos Markdown. Se quiser pegar a imagem de algum repositório, pode usar o seguinte formato:

![Alt Text](https://github.com/{user}/{repo}/raw/{branch}/path/to/image.gif)

Claro que o trecho acima é apenas um exemplo, será necessário trocar as informações acima pelas corretas da sua imagem. Algo bem interessante é a possibilidade de trocar a imagem com base no tema que está utilizando... sim é possível e falei como realizar essa façanha neste artigo.

Upload de imagens

Quando abrir uma issue ou pull request, você pode adicionar uma local, de 3 formas:

1ª) Arrastando a imagem para área onde você digita o texto da issue / pull request;

2ª) Colando a imagem da sua área de transferência (Ctrl + C ou Cmd + C). Essa é clássica, pensou que o famoso comando usando por milhares de pessoas ficaria de fora da plataforma do Github?

3ª) A última, porém não menos importante é clicando no link apresentado e selecionando a imagem que deseja:

Fato é... as imagens e gifs são extremamente necessárias, pois melhoram ainda mais seu repo, issue e pull requests, mas claro que você não pode abusar delas ou então isso irá acabar atrapalhando mais do que ajudando.

Fontes onde pesquisei esse conteúdo:

https://docs.github.com/pt/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

Hacks do Github - Variáveis

Jhony Walker — Thu, 16 Jun 2022 22:58:16 +0000

O Github é cheio de funcionalidades e o mais utilizado isso vocês já sabem e vamos continuar a série de "hacks" da plataforma que vão otimizar e melhorar sua experiência.

Sabia que é possível utilizar variáveis nos seus arquivos Markdown? Mostrarei hoje como e, porque você deveria utilizar! Imagine que o seu Markdown tem vários links, como por exemplo:

[![NPM version](https://badge.fury.io/js/getmodule.svg?style=flat)](https://npmjs.org/package/getmodule)
[![Build Status](https://travis-ci.org/fdaciuk/getmodule.svg)](https://travis-ci.org/fdaciuk/getmodule)
[![Coverage Status](https://img.shields.io/coveralls/fdaciuk/getmodule.svg?style=flat)](https://coveralls.io/r/fdaciuk/getmodule?branch=master)
[![Code Climate](https://codeclimate.com/github/fdaciuk/getmodule/badges/gpa.svg?style=flat)](https://codeclimate.com/github/fdaciuk/getmodule)
[![NPM](https://nodei.co/npm/getmodule.png?downloads=true&downloadRank=true&stars=true)](https://nodei.co/npm/getmodule/)

Como você pode ver, no exemplo ele faz chamadas de alguns badges com links apontando para versão do módulo no NPM, Status do TravisCI, Status do Code Coverage no Coveralls, Code Climate, etc. Isso acaba ficando bastante verboso no seu arquivo e, se você precisar usar a mesma URL em outro lugar do seu README, terá que repetí-la.

Variáveis

Mas podemos usar um segredo guardado a sete chaves pelos Ninjas do Github, que são as variáveis. No final do seu arquivo, podemos colocar as suas variáveis nesse formato:

[nome-da-variavel]: valor-da-variavel

E para usar, só fazer assim:

[nome-da-variavel]

No caso do arquivo Markdown acima, aquele trecho de código ficaria assim:

[![NPM version][npm-version-image]][npm-version-url]
[![Build Status][travis-image]][travis-url]
[![Coverage Status][coveralls-image]][coveralls-url]
[![Code Climate][codeclimate-image]][codeclimate-url]
[![NPM][npm-image]][npm-url]

Assim como falei no artigo sobre Task lists e Tabelas interessante no Github a linguagem utilizada para escrita desses textos é o Markdown que é uma linguagem simples de marcação originalmente criada por John Gruber e Aaron Swartz. Markdown converte seu texto em HTML válido, mas essa linguagem é utilizada também no Discord, Notion entre outros que possuem como base essa linguagem.

Isso significa que a output de saída será a mesma inserindo o texto formatado conforme o que está inserido no Github, é um pouco repetitivo mas é importante que tenham isso em mente.

Fontes onde pesquisei esse conteúdo:

https://docs.github.com/pt/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes

Hacks do Github - Mantendo repositório forkado sincronizado com o original

Jhony Walker — Sun, 12 Jun 2022 21:30:36 +0000

O Github é cheio de funcionalidades e o mais utilizado isso vocês já sabem e vamos continuar a série de "hacks" da plataforma que vão otimizar e melhorar sua experiência.

Depois que você forka um projeto no Github, você faz as alterações necessárias e envia um Pull Request para o repositório original.

Se você precisa fazer mais alguma alteração no mesmo repositório no futuro, mas já tem outras colaborações no repositório original, como você procede para manter seu repositório atualizado? Copia as alterações manualmente para o seu repositório? Apaga e forka novamente?

O Git é uma ferramenta excepcional e, quando você passa a conhecê-lo mais a fundo, vai ver que não vai precisar fazer mais nada manualmente quando ele é usado no seu projeto. Existe uma forma muito prática de sincronizar os dois repos, e vou mostrá-la agora mesmo!

O seu repositório forkado normalmente é adicionado como origin quando você faz o clone. Para sincronizar com o repositório principal, adicione esse repositório com outro nome (no caso do exemplo, upstream), com o comando abaixo:

git remote add upstream [ENDEREÇO DO REPOSITÓRIO PRINCIPAL]

Substituindo [ENDEREÇO DO REPOSITÓRIO PRINCIPAL] pelo endereço do repositório.

Depois, para sincronizar os repositórios, execute o comando:

git fetch upstream

Finalmente, só dar merge na branch master:

git merge upstream/master

A sincronização do fork só atualiza a cópia local do repositório. Para atualizar a bifurcação no GitHub.com, você precisa fazer push das alterações.

Fontes onde pesquisei esse conteúdo:

https://docs.github.com/pt/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

Hacks do Github - Mantendo a ordem

Jhony Walker — Fri, 10 Jun 2022 22:30:43 +0000

O Github é cheio de funcionalidades e o mais utilizado isso vocês já sabem e vamos continuar a série de "hacks" da plataforma que vão otimizar e melhorar sua experiência.

Quando criamos uma nova feature para um projeto open source, normalmente criamos uma branch nova, fazemos as alterações, fazemos o push para o repositório nessa nova branch e então envia um pull request.

Quando o pull request é aceito é feito o processo para atualizar o repositório com o repositório forkado e tudo fica 100% como deveria! Mas, com o tempo, a lista de branchs no Github vai aumentando, mas não vamos precisar delas, pois seu pull request já foi aceito. Como limpar a sujeira e deixar somente as branchs que precisamos?

Removendo branchs do Github

Para remover uma branch do Github, você pode usar o comando no seu terminal (sim, claro que vamos utilizar os comandos GIT você ainda tinha dúvida?)

git push origin nome_da_branch --delete

E com esse comando iremos deletar a branch do Github! Ou podemos utilizar este comando também:

git push origin :nome_da_branch

Com os dois pontos : na frente do nome da branch, o resultado é o mesmo

Removendo branchs localmente

Aproveitando o gancho, vou falar como você pode remover as branchs locais também cujo o comando é:

git branch -D nome_da_branch

Então é isso pessoal, sei que você provavelmente já conhecia esse comando (uns 98% de certeza), mas é sempre bom relembrar e utiliza-ló para organizar seus repositórios.

Fontes onde pesquisei esse conteúdo:

https://docs.github.com/pt/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches

Hacks do Github - Shortcuts

Jhony Walker — Fri, 10 Jun 2022 15:48:40 +0000

O Github é cheio de funcionalidades e o mais utilizado isso vocês já sabem e vamos continuar a série de "hacks" da plataforma que vão otimizar e melhorar sua experiência.

Atalhos sempre agilizam o trabalho com qualquer ferramenta para isso esse post veio mostrar alguns atalhos interessantes do Github.

Buscando arquivos

Quando visualizamos um repositório, podemos pressionar t e começar a digitar um nome de arquivo que contenha nesse diretório, que o arquivo será buscado recursivamente em todos os diretórios:

Usando as setas ↑ e ↓, conseguimos navegar pelos arquivos encontrados e ao pressionar enter o arquivo é aberto.
Esse comando funciona na listagem de arquivos de um repositório.

Branch selector

Agora quando trabalhamos com várias branchs, podemos usar o w, na tela principal do repositório, para abrir o Branch Selector. O campo de busca de branchs receberá foco.

Pressionando tab, você navega entrea as abas como nomes das branches e tag e para selecionar basta pressionar enter

Command bar

Pressionando s, o barra de busca recebe foco para você poder encontrar conteúdos dentro do Github:

Labels

Na tela de issues, pressionando l, podemos filtrar as issues por labels. Podemos navegar por elas usando as setas ↑ e ↓ e pressionar enterpara selecionar:

Congelar uma alteração de arquivo

Ao visualizar um arquivo, se quando pressionarmos y, a URL irá mudar para uma que “congela” como o arquivo está atualmente. Se esse arquivo mudar, você pode usar essa URL para ver exatamente como estava o arquivo antes das alterações.

VScode Online

Recentemente foi disponibilizado pela equipe do Github o atalho . que "apenas" abre em um VScode Online com toda estrutura do projeto que está no repositório. Para isso basta escolher o repositório que deseja ver e pressione .

Ou basta alterar o link do repositório adicionando no lugar do github.com o github.dev

Todos os atalhos

pPor último, mas não menos importante, se pressionarmos o ? em qualquer lugar, será mostrada a tela com todos os atalhos disponíveis no Github. Inicialmente são mostrados somente os mais utilizados. Mas clicando no link Show all, você pode ver todos os atalhos!

Basta você testar todos que estão presentes nessa lista gigantesca e otimizar cada vez mais seu trabalho.

Fontes onde pesquisei esse conteúdo:

https://docs.github.com/pt/get-started/using-github/keyboard-shortcuts