Instrutor: Julio Cesar Martins
quarta-feira, 29 de maio de 2013
segunda-feira, 27 de maio de 2013
git reset {soft | hard | mixed} - como lembrar
Por
JonatasCD
Qual a diferença entre o soft, hard e mixed do commando git reset ?
Veja um jeito fácil de lembrar.
Bem, considere que você está trabalhando no seu código a partir de um git checkout
. Então você segue trabalhando, coda, compila, testa e então faz git add e git commit
Seria algo:
{fonte}
$ git checkout trampo …. coda …. compila …. testa … $ git add …. $ git commitSe nesse ponto você fizer um git reset , veja como cada tipo de reset afeta as coisas:
$ git checkout trampo # --hard fará o reset nesse ponto …. coda …. compila …. testa … # --mixed (é o padrão) reseta nesse ponto $ git add …. # --soft reset até esse ponto $ git commitVale falar que o git commit --amend faz com que o git reset --soft se torne um tanto redundante.
{fonte}
domingo, 26 de maio de 2013
Como trocar a url de um repositório remoto Git
Por
JonatasCD
Toda vez que clonamos um repositório local, a url clonada fica armazenada como "origin" no repositório local.
Como saber qual o remote do Git?
$ git remote -v origin https://github.com/joncasdam/repositorio.git (fetch) origin https://github.com/joncasdam/repositorio.git (push)
Mas se você quer ter mais informações sobre o "origin", por exemplo:
$ git remote show origin * remote origin Fetch URL: https://github.com/joncasdam/repositorio.git Push URL: https://github.com/joncasdam/repositorio.git HEAD branch: master Remote branches: dev tracked master tracked Local branches configured for 'git pull': dev merges with remote dev master merges with remote master Local refs configured for 'git push': dev pushes to dev (up to date) master pushes to master (local out of date)
Agora, se você precisa trocar a url do repositório, há um comando no git que permite fazer essa alteração:
$ git remote set-url origin https://github.com/user/repositorio.git
agora confirme a alteração:
$ git remote -v origin https://github.com/user/repositorio.git (fetch) origin https://github.com/user/repositorio.git (push)
pronto!
quinta-feira, 16 de maio de 2013
Apache: Could not bind address to port (make_sock)
Por
JonatasCD
Um tanto em função do último post, passei por uma situação bem semelhante ao post abaixo que resolvi traduzi-lo.
--
Se você está atualizando software ou alterando a configuração das portas, provavelmente dará de cara com esse erro ao tentar reiniciar o Apache.
--
Se você está atualizando software ou alterando a configuração das portas, provavelmente dará de cara com esse erro ao tentar reiniciar o Apache.
O Apache está tentando 'ouvir' (Listen) a porta 8080, um exemplo, mas não consegue porque já está em uso. Eis algumas razões pelas quais isso pode acontecer.
Problema de configuração da porta
Se tiver entradas duplicadas para Listen, o Apache irá reclamar. Certifique-se que seu apache.conf e ports.conf NÃO tenham ambos essa diretiva. Se ela for listada apenas uma vez (veja o exemplo do arquivo ports.conf abaixo), então verifique se acidentalmente você não duplicou inadvertidamente seus ports.conf em algum lugar do seu Apache
NameVirtualHost *:81 Listen 81 <IfModule mod_ssl.c> Listen 443 </IfModule> <IfModule mod_gnutls.c> Listen 443 </IfModule>
Vale também dar uma olhada nas configurações de seus Virtualhosts, pois já vi a declaração Listen ser feita junto dos VirtualHosts, então, se for o caso, veja em apache2/sites-enabled.
Outro servido pode estar usando a porta
Quando me deparei com esse erro, foi porque outra instância do apache já estava usando-a. Esse próximo exemplo usa netstat, grep e kill para resolver o problema.
$ netstat -tulpn | grep :8888
Que retornará:
tcp 0 0 0.0.0.0:8888 0.0.0.0:* LISTEN 30661/apache2
Então faça:
$ sudo kill -9 30661 (ease é o PID que aparece para a instância)
Lembre-se que você deve investigar e avaliar problemas no servidor antes de simplesmente reiniciá-lo. Dei o boot quatro vezes antes de assumir que eu deveria ter errado em algo.
terça-feira, 14 de maio de 2013
Mais de um apache no servidor
Por
JonatasCD
Você sabia que é possível ter múltiplas instâncias de apache no seu servidor? Sabia que ter 2 apaches no servidor (ou mais) já é algo previsto e préprogramando pelo próprio Apache?
Sim! Porém, antes é bom pensar: por que precisamos rodar múltiplas instâncias do apache no host?
Boa pergunta, afinal, com uma boa configuração em VirtualHost, você consegue ter tudo bem separado e organizado. Contudo esse caminho pode, com o tempo, te levar a um servidor pesado e lento.
Imagine que você trabalhe com diferentes sites, com requisitos distintos: um com mod_python outro com mod_php e etc); você configuraria isso tudo em uma instãncia apache, mas como resultado teria grande consumo de memória.
Uma solução provida pelo próprio apache é ter configurações mais leves e separadas para, por exemplo, cada mod, usando portas diferentes.
E como fazer? Não precisa fazer uma série de sudo cp em tudo que é pasta.
Sim! Porém, antes é bom pensar: por que precisamos rodar múltiplas instâncias do apache no host?
Boa pergunta, afinal, com uma boa configuração em VirtualHost, você consegue ter tudo bem separado e organizado. Contudo esse caminho pode, com o tempo, te levar a um servidor pesado e lento.
Imagine que você trabalhe com diferentes sites, com requisitos distintos: um com mod_python outro com mod_php e etc); você configuraria isso tudo em uma instãncia apache, mas como resultado teria grande consumo de memória.
Uma solução provida pelo próprio apache é ter configurações mais leves e separadas para, por exemplo, cada mod, usando portas diferentes.
E como fazer? Não precisa fazer uma série de sudo cp em tudo que é pasta.
$ sh /usr/share/doc/apache2.2-common/examples/setup-instance NOMEDAINSTANCIA
Assinar:
Postagens (Atom)