comandos básicos git

Comandos básicos do git

#iniciar um repositório. Colocamo-nos na pasta que queremos no git e iniciamos com:
$ git init

# adicionar todos os ficheiros da pasta ao git
$ git add .

#Podemos adicionar só um documento ou pasta. Consultar help do git. Neste caso adicionamos tudo

#Fazer commit para guardar no master o conteúdo adicionado ao header
$ commit -m "Qualquer coisa"

# adicionar todos os ficheiros da pasta ao git

$ git config --global core.autocrlf false

# Remover ficheiros e pastas (-r) do index. Ficheiros e pastas físicos não são apagados (--cached). Devemos adicionar um ficheiro .gitignore para que no próximo commit estes não voltem a ser adicionados.

$ git rm -r --cached .

# adicionar dados do utilizador (name) ao config Global
$ git config --global user.name xpto

# adicionar dados do utilizador (email) ao config Global
$ git config --global user.email xpto@gmail.com

# adicionar local do repositório externo ao config local, porque isto é feito por repositório ( namerepo - será o nome do nosso repositório)
$ git config --local remote.origin.url=https://github.com/xpto/namerepo

# Para enviarmos o nosso repositório para o guithub fazemos
$ git push 

Read More

.gitignore

O Git vê todos os arquivos em sua cópia de trabalho como uma das três coisas:

1. rastreado - um arquivo que foi previamente preparado ou confirmado;
2. não rastreado - um arquivo que não foi preparado ou confirmado; ou
3. ignorado - um arquivo que foi dito explicitamente ao Git para ignorar.

Arquivos ignorados geralmente são artefatos de construção e arquivos gerados por máquina que podem ser derivados da origem do repositório ou, caso contrário, não devem ser confirmados. Alguns exemplos comuns são:

• caches de dependência, como o conteúdo /node_modulesou/packages
• código compilado, tais como .o, .pyce .classarquivos
• construir diretórios de saída, tais como /bin, /outou/target
• arquivos gerados em tempo de execução, tais como .log, .lockou.tmp
• arquivos de sistema ocultos, como .DS_StoreouThumbs.db
• arquivos de configuração IDE pessoais, como .idea/workspace.xml

Os arquivos ignorados são rastreados em um arquivo especial chamado .gitignore na raiz do seu repositório. Não há um comando explícito git ignore: em vez disso, o .gitignore arquivo deve ser editado e confirmado manualmente quando você tiver novos arquivos que deseja ignorar. Os ficheiros.gitignore contêm padrões que são comparados com os nomes de arquivo no seu repositório para determinar se devem ou não ser ignorados.

Git ignorar padrões

.gitignore usa padrões de globbing para combinar com nomes de arquivos. Você pode construir seus padrões usando vários símbolos:

padronizar	Correspondências de exemplo	Explicação*
**/logs	logs/debug.log logs/monday/foo.bar build/logs/debug.log	Você pode anexar um padrão com um asterisco duplo para corresponder aos diretórios em qualquer lugar do repositório.
**/logs/debug.log	logs/debug.log build/logs/debug.log mas não logs/build/debug.log	Você também pode usar um asterisco duplo para corresponder aos arquivos com base no nome e no nome do diretório pai.
*.log	debug.log foo.log .log logs/debug.log	Um asterisco é um curinga que corresponde a zero ou mais caracteres.
*.log !important.log	debug.log trace.log mas não important.log logs/important.log	Anexar um ponto de exclamação a um padrão o nega. Se um arquivo corresponder a um padrão, mas também corresponder a um padrão de negação definido posteriormente no arquivo, ele não será ignorado.
*.log !important/*.log trace.*	debug.log important/trace.log mas não important/debug.log	Os padrões definidos após um padrão de negação irão ignorar todos os arquivos negados anteriormente.
/debug.log	debug.log mas não logs/debug.log	O prefixo de uma barra corresponde aos arquivos apenas na raiz do repositório.
debug.log	debug.log logs/debug.log	Por padrão, os padrões correspondem aos arquivos em qualquer diretório
debug?.log	debug0.log debugg.log mas não debug10.log	Um ponto de interrogação corresponde exatamente a um caractere.
debug[0-9].log	debug0.log debug1.log mas não debug10.log	Os colchetes também podem ser usados ​​para corresponder a um único caractere de um intervalo especificado.
debug[01].log	debug0.log debug1.log mas não debug2.log debug01.log	Os colchetes correspondem a um único caractere no conjunto especificado.
debug[!01].log	debug2.log mas não debug0.log debug1.log debug01.log	Um ponto de exclamação pode ser usado para corresponder a qualquer caractere, exceto um do conjunto especificado.
debug[a-z].log	debuga.log debugb.log mas não debug1.log	As faixas podem ser numéricas ou alfabéticas.
logs	logs logs/debug.log logs/latest/foo.bar build/logs build/logs/debug.log	Se você não anexar uma barra, o padrão corresponderá aos arquivos e ao conteúdo dos diretórios com esse nome. No exemplo corresponde à esquerda, os diretórios e os arquivos denominados logs são ignorados
logs /	logs/debug.log logs/latest/foo.bar build/logs/foo.bar build/logs/latest/debug.log	Anexar uma barra indica que o padrão é um diretório. Todo o conteúdo de qualquer diretório no repositório correspondente a esse nome - incluindo todos os seus arquivos e subdiretórios - será ignorado
logs/ !logs/important.log	logs/debug.log logs/important.log	Espere um minuto! Não deve logs/important.logser negado no exemplo à esquerda Não! Devido a uma peculiaridade relacionada ao desempenho no Git, você não pode negar um arquivo que é ignorado devido a um padrão que corresponde a um diretório
logs/**/debug.log	logs/debug.log logs/monday/debug.log logs/monday/pm/debug.log	Um asterisco duplo corresponde a zero ou mais diretórios.
logs/*day/debug.log	logs/monday/debug.log logs/tuesday/debug.log mas não logs/latest/debug.log	Os curingas também podem ser usados ​​nos nomes de diretório.
logs/debug.log	logs/debug.log mas não debug.log build/logs/debug.log	Os padrões que especificam um arquivo em um diretório específico são relativos à raiz do repositório. (Você pode acrescentar uma barra, se quiser, mas ela não faz nada de especial.)

** essas explicações assumem que seu arquivo .gitignore está no diretório de nível superior do seu repositório, como é a convenção. Se o seu repositório tiver vários arquivos .gitignore, substitua mentalmente "raiz do repositório" por "diretório que contém o arquivo .gitignore" (e considere unificá-los, para a sanidade da sua equipe). *

Além desses caracteres, você pode usar # para incluir comentários em seu .gitignore :

# ignore all logs
*.log

Você pode usar \ para escapar dos caracteres padrão se tiver arquivos ou diretórios que os contenham:

# ignore the file literally named foo[01].txt
foo\[01\].txt

Read More

Git - ignore file and folder

Digamos que você já tenha adicionado/confirmado alguns arquivos ao seu repositório git e depois os adicione ao seu .gitignore; esses arquivos ainda estarão presentes no seu índice de repositório. Este artigo vamos ver como se livrar deles.

Etapa 1: confirmar todas as suas alterações

Antes de continuar, verifique se todas as alterações foram confirmadas, incluindo o arquivo .gitignore.

Edit .gitignore

#ignore folder name "session" session/

No entanto se esta pasta  já tinha sido adicionada antes ao repositório ela ainda continua lá

Etapa 2: Remova tudo do repositório ou de uma directoria específica

Para limpar esta pasta do seu repositório, use:

cd /session git rm -r --cached .

• rm é o comando remove
• -r permitirá a remoção recursiva
• --Cached irá remover apenas arquivos do índice. Seus arquivos ainda estarão lá.
• O . indica que todos os arquivos serão rastreados. Você pode rastrear um arquivo específico com git rm --cached foo.txt.

O rm comando pode ser implacável. Se você quiser experimentar o que faz antes, adicione o sinalizador -nou --dry-runpara testar as coisas.

Etapa 3: Se na linha anterior tivermos removido tudo,adicione novamente tudo. Se o objectivo for remover a pasta do índice e do repositório remoto podemos passar à etapa 4

git add .

Etapa 4: confirmar

git commit -m ".gitignore fix"

Seu repositório está limpo :)

Faça um push  para repositório remoto para ver as alterações efectivas também.

Read More

JEE, JSE, JRE, JDK entenda as diferenças

JEE - Plataforma Java, Enterprise Edition
O que é o Java Enterprise Edition (Java EE)?
O Java EE é um ambiente independente da plataforma, centrado em Java que cria e implementa aplicativos corporativos baseados na Web on-line. O Java EE inclui muitos componentes do Java Standard Edition (Java SE). A plataforma Java EE consiste em um conjunto de servidores APIs e protocolos que fornecem a funcionalidade para desenvolver aplicativos multicamadas com base na Web.
O Java EE simplifica o desenvolvimento do aplicativo e diminui a necessidade de programação e de treinamento do programador, criando componentes modulares reutilizáveis padronizados e ativando a camada para tratar de muitos aspectos da programação de forma automática.
Se você for um desenvolvedor corporativo, precisará do Java EE. Os desenvolvedores corporativos necessitam do Java EE porque a criação de aplicativos de negócios distribuídos não é fácil, e eles precisam de uma solução de alta produtividade que lhes permitam se concentrarem apenas na criação da lógica de negócios e ter uma grande variedade de serviços de nível corporativo nos quais confiar, como objetos transacionais distribuídos, middleware orientado à mensagem e serviços de nomenclatura e de diretório.


JSE - Plataforma Java, Standard Edition
Necessitam disto os desenvolvedores de software que criam mini-aplicativos e aplicativos utilizando a tecnologia Java.
Trata-se de Um kit de desenvolvimento de software usado para criar mini-aplicativos e aplicativos que utilizam a linguagem de programação Java.
Ele é distribuído gratuitamente e está disponível no site: oracle.com/javase

JRE - Java Runtime Environment - (O java normal que todos tem no seu computador)
Necessitam disto os Utilizadores de computador que executam mini-aplicativos e aplicativos desenvolvidos com a tecnologia Java.
Este componente é um ambiente necessário para a execução de mini-aplicativos e aplicativos desenvolvidos com a linguagem de programação Java.
Ele é distribuído gratuitamente e está disponível no site: java.com
É uma implementação do Java Virtual Machine* que na verdade executa programas Java.
O Java Runtime Environment é um plug-in necessário para a execução de programas Java.
O JRE é menor que o JDK, portanto, ele necessita de menos espaço em disco.
Inclui o JVM, as bibliotecas centrais e outros componentes adicionais para executar aplicativos e applets criados em Java.

JDK - Java Development Kit
É um pacote de software que você pode usar para desenvolver aplicativos baseados em Java.
O Java Development Kit é necessário para desenvolver aplicativos java.
O JDK necessita de mais espaço em disco porque ele contém o JRE juntamente com várias ferramentas de desenvolvimento.
Inclui o JRE, conjunto de classes de API, compilador Java, Webstart e arquivos adicionais necessários para criar applets e aplicativos Java.

Read More