{"id":16151643,"url":"https://github.com/felipeorlando/git-conventions","last_synced_at":"2025-03-18T19:31:22.785Z","repository":{"id":144834559,"uuid":"46443310","full_name":"felipeorlando/git-conventions","owner":"felipeorlando","description":":octocat: git commit -m \"Add pattern now\"","archived":false,"fork":false,"pushed_at":"2023-02-28T05:19:47.000Z","size":124,"stargazers_count":18,"open_issues_count":0,"forks_count":2,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-02-28T11:49:26.703Z","etag":null,"topics":["conventions","git","github"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/felipeorlando.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2015-11-18T19:50:21.000Z","updated_at":"2023-02-28T05:19:52.000Z","dependencies_parsed_at":null,"dependency_job_id":"b289df74-06b3-4702-b82d-cf4b153329e3","html_url":"https://github.com/felipeorlando/git-conventions","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/felipeorlando%2Fgit-conventions","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/felipeorlando%2Fgit-conventions/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/felipeorlando%2Fgit-conventions/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/felipeorlando%2Fgit-conventions/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/felipeorlando","download_url":"https://codeload.github.com/felipeorlando/git-conventions/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243945626,"owners_count":20372897,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["conventions","git","github"],"created_at":"2024-10-10T00:58:19.552Z","updated_at":"2025-03-18T19:31:22.769Z","avatar_url":"https://github.com/felipeorlando.png","language":null,"readme":"\u003cp align=\"center\"\u003e\n\t\u003cimg src=\"https://raw.githubusercontent.com/felinalabs/git-conventions/master/cover.png\" alt=\"Git Conventions Cover\" style=\"max-width:100%;\"\u003e\n\u003c/p\u003e\n\n\u003ch1 align=\"center\"\u003e\n\t\u003ca id=\"user-content-octocat-git-conventions\" class=\"anchor\" href=\"#octocat-git-conventions\" aria-hidden=\"true\"\u003e\u003csvg aria-hidden=\"true\" class=\"octicon octicon-link\" height=\"16\" role=\"img\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"\u003e\u003cpath d=\"M4 9h1v1h-1c-1.5 0-3-1.69-3-3.5s1.55-3.5 3-3.5h4c1.45 0 3 1.69 3 3.5 0 1.41-0.91 2.72-2 3.25v-1.16c0.58-0.45 1-1.27 1-2.09 0-1.28-1.02-2.5-2-2.5H4c-0.98 0-2 1.22-2 2.5s1 2.5 2 2.5z m9-3h-1v1h1c1 0 2 1.22 2 2.5s-1.02 2.5-2 2.5H9c-0.98 0-2-1.22-2-2.5 0-0.83 0.42-1.64 1-2.09v-1.16c-1.09 0.53-2 1.84-2 3.25 0 1.81 1.55 3.5 3 3.5h4c1.45 0 3-1.69 3-3.5s-1.5-3.5-3-3.5z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\n\tGit Conventions\n\u003c/h1\u003e\n\n\u003cp align=\"center\"\u003e\n\t:warning:\u003cbr\u003e\u003cstrong\u003eATENÇÃO\u003c/strong\u003e\n\u003c/p\u003e\n\u003cp align=\"center\"\u003e\n\tEsse repositório foi feito há anos atrás, agora está descontinuado. Recomendo seguirem o \u003ca href=\"https://www.conventionalcommits.org/en/v1.0.0/\" target=\"_blank\"\u003eConventional Commits\u003c/a\u003e.\n\u003c/p\u003e\n\n---\n\nTodos nós, desenvolvedores, trabalhamos com versionamento. E grande parte de nós optamos por trabalhar com Git, por sua popularidade e facilidade de aprendizagem.\n\nTodo bom programador descobre cedo que é preciso padronizar seu workflow. Seja no modo em que escreve seu código, seja na arquitetura do projeto, seja no método de trabalho. \n\nE trabalhar com Git muitas vezes significa trabalhar em equipe. E nisso ele é uma mão na roda! Porém também é preciso criar um padrão para que a equipe possa sempre ser performática.\n\nPorém, antes de começar, precisamos analisar o projeto em que estamos trabalhando. \n\n**As soluções descritas aqui não são balas de prata**!\n\n## :us: Yes, we can! And we must!\nPrimeiramente é preciso DITAR: todo o trabalho com o Git/GitHub precisa estar escrito em inglês. Sem mais, nem menos. Esse é o primeiro passo. Afinal, você não escreve seu código em português (ao menos não deveria).\n\n## :recycle: Siga padrões já estabelecidos\nNão seja rebelde, não reinvente a roda. Se o projeto que você começou a trabalhar já tem um **padrão definido** e bem estruturado, não há razão para mudanças drásticas. Se o projeto já tem tempos de vivência, significa que o padrão atual já dá conta do recado.\n\n## :rocket: Commit a cada mudança\nO ideal para manter tudo bem versionado é, para cada mudança, um commit. Seja adição de nova funcionalidade, correção de bug ou até remoção de uma funcionalidade antiga.\n\nIsso não só é necessário para o processo de **deploy** da aplicação para mudanças necessárias, mas nos dá a facilidade de usar uma das principais funcionalidades do versionamento: retroceder ao código antes do commit indicado. \n\n## :anchor: Sintaxe é o segredo para o início triunfal\nAo lidarmos com versionamento, o mais importante não é o software, mas sim a equipe por trás do desenvolvimento dele. E é válido lembrar que esta equipe é composta por humanos. Precisamos não só humanizar nosso software, nosso código mas também nosso processo de trabalho **por inteiro**.\n\nTemos que lidar com **commits** e **merges** descrevendo nossas ações, de forma compreensíva até mesmo para alguém completamente leigo na área de TI.\n\n### Commits\nCada ação significativa realizada no código deve ser tratada como uma ação, um **verbo**. A mensagem dos commits deve ser direta, compreensíva porém breve.\n\nTodo commit deve começar com um verbo, seguido da(s) alteração(ões) feita(s) – apesar do singular, dê prioridade por fazer commit a cada alteração no sistema, seja uma adicão, atualização, remoção.\n\nAlguns dos verbos que costumo usar bastante são: **add, create, update, edit, remove**.\n\n**Exemplo:** Em um projeto onde teremos comentários e trabalharemos com algum framework MVC, ao criarmos uma migration para os comentários, podemos fazer o seguinte commit:\n\n```\ngit commit -m \"Create comments migration\"\n```\n\nO mais interessante ainda, seria fazer este commit após a criação da migration e do model. Assim, unificamos um commit para criação tanto do database, quanto do model:\n\n```\ngit commit -m \"Create comments migration and Comment model\"\n```\n\nObs: É bom notar nos dois exemplos o início da mensagem com letra maiúscula. Como eu disse: padrões são necessários... inclusive os pequenos detalhes.\n\nA ideia não é fazer nem muitos e nem poucos commits. Muitos commits tornam o \"changelog\" do projeto sujo e grande. Poucos não mantém o projeto devidamente atualizado com atualizações primordiais do projeto e não beneficia no workflow quando se trabalha com **integração contínua**.\n\nOutro ponto que podemos atingir é a necessidadede de uma PAUSA, o momento em que nosso trabalho precisa de um hiato para dormirmos, comermos, sairmos ou **tomar um café** :coffee:. Nessas horas, podemos estabelecer nosso trabalho em partes, usando os números que a matemática neandertal nos provém: 1, 2, 3, 4...\n\n**Exemplo:** Estou lá eu, resolvendo uma awesome feature quando o meu ~~combustível~~ café e percebo que preciso ir comprar mais, do outro lado da cidade... Lá vou eu, mas antes vou commitar para não perder nada! Então, como sei que parei na metade do caminho, vou dar um commit enumerado:\n\n```\ngit commit -m \"Add awesome feature #1\"\n```\n\nAssim que eu tiver café o suficiente e codando novamente, posso terminar meu trabalho e commitar quando tudo estiver pronto:\n\n```\ngit commit -m \"Add awesome feature #2\"\n```\n\n### Merges\nO conceito de merge é extremamente simples. Simples assim! Não há o porquê complicar, pois não é uma cilada, Bino. :laughing:\n\nA nomeclatura de um merge deve ser simples e coesa, condizendo com o motivo daquele merge. Mais específicamente, indicar a ação realizada naquele merge logo no início.\n\nÉ comum usar **fix**, **add**, **remove**, **refactoring**.\n\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffelipeorlando%2Fgit-conventions","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ffelipeorlando%2Fgit-conventions","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffelipeorlando%2Fgit-conventions/lists"}