{"id":265,"date":"2021-05-30T23:46:13","date_gmt":"2021-05-30T23:46:13","guid":{"rendered":"http:\/\/jplatz.com.br\/syntax\/?p=265"},"modified":"2021-09-13T01:31:08","modified_gmt":"2021-09-13T01:31:08","slug":"git-checkout-para-restaurar-um-unico-arquivo-ja-comitado","status":"publish","type":"post","link":"https:\/\/jplatz.com.br\/syntax\/2021\/05\/30\/git-checkout-para-restaurar-um-unico-arquivo-ja-comitado\/","title":{"rendered":"GIT CHECKOUT Para Restaurar um \u00danico Arquivo j\u00e1 Comitado"},"content":{"rendered":"\n
git log\n\/\/ encontre o hash da vers\u00e3o que voc\u00ea deseja retornar um arquivo\ngit checkout <commit hash> <caminho-completo-para-o-arquivo-desejado>\ngit status\ngit commit<\/pre>\n\n\n\n
Devs utilizando a metodologia “PMF<\/em><\/strong>” est\u00e3o em constante evolu\u00e7\u00e3o de seus c\u00f3digos e muitas vezes podem acabar numa sinuca de bico e invariavelmente em algum momento podem querer reverter suas altera\u00e7\u00f5es.<\/p>\n\n\n\n
Mas e se a revers\u00e3o a ser feita envolve apenas um \u00fanico arquivo e usar o git reset <\/em>pode dar aquele medo de piorar as coisas?<\/p>\n\n\n\n
Bom, nessas horas voc\u00ea pode fazer uso do git checkout <\/em>mesmo, afinal este comando \u00e9 bastante comum pois usamos este comando o tempo todo, ent\u00e3o n\u00e3o haveria raz\u00e3o para ter medo de us\u00e1-lo. Haveria?<\/p>\n\n\n\n
A sacada aqui \u00e9 apenas combinar o git checkout<\/em> com o hash do commit que tem a vers\u00e3o do arquivo a ser restaurado adicionando-se tamb\u00e9m o caminho completo para o arquivo desejado. A vers\u00e3o do arquivo ent\u00e3o \u00e9 baixada para a “working area<\/em>” e depois de voc\u00ea verificar o conte\u00fado dele basta apenas comitar novamente o arquivo para o reposit\u00f3rio.<\/p>\n\n\n\n
\u00c9 claro que voc\u00ea poderia alcan\u00e7ar o mesmo resultado com outros comandos GIT<\/strong> como o reset<\/strong> ou o revert<\/strong>. Mas se o git checkout faz este trabalho pra voc\u00ea com uma sintaxe extremamente limpa, pra que complicar?<\/p>\n\n\n\n
Vale ressaltar que este fluxo o git checkout <\/em>n\u00e3o ir\u00e1 funcionar para arquivos novos que acabaram de ser comitados, isto por que um arquivo novo n\u00e3o existir\u00e1 em um commit hash<\/em> anterior e no commit hash<\/em> atual ele \u00e9 o que \u00e9, um arquivo novo. <\/p>\n\n\n\n
Nesta situa\u00e7\u00e3o \u00e9 recomendado o uso do git rm<\/strong> que ir\u00e1 funcionar perfeitamente para esta necessidade… eu j\u00e1 escrevi um artigo sobre git rm<\/em> aqui no blog, recomendo dar uma olhada nele para maiores detalhes de uso.<\/p>\n\n\n\n
Agora sem complica\u00e7\u00f5es, vai de git checkout<\/em><\/strong> bro! …ou de git rm<\/strong><\/em> quando for um arquivo novo.<\/p>\n","protected":false},"excerpt":{"rendered":"
git log \/\/ encontre o hash da vers\u00e3o que voc\u00ea deseja retornar um arquivo git checkout <commit hash> <caminho-completo-para-o-arquivo-desejado> git status git commit Devs utilizando a metodologia “PMF” est\u00e3o em constante evolu\u00e7\u00e3o de seus c\u00f3digos e muitas vezes podem acabar numa sinuca de bico e invariavelmente em algum momento podem querer reverter suas altera\u00e7\u00f5es. Mas […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[33,35],"tags":[134],"class_list":["post-265","post","type-post","status-publish","format-standard","hentry","category-dev-ops","category-git","tag-git-checkout"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t