Dando vida ao notebook com SSD usando um drive CADDY

Na Campus Party de Recife em 2015, conheci o drive CADDY e achei bem interessante para instalar um Disco SSD em meu notebook.
O Drive CADDY é uma "caixa" onde substituirmos o drive de DVD/CD-ROM, podemos instalar um HD nesta caixa, assim liberando um SATA para o drive SSD.

Instalando o sistema operacional no SDD, ganhamos muito em performance e velocidade. O seu sistema operacional será carregado de uma forma impressionante na inicialização e programas irão abrir de forma muito rápida.
Aquele seu notebook, que tem um drive de DVD e você quase não utiliza e está insatisfeito com a performance dele, poderá ganhar uma vida com um drive SSD.

Vou relatar de forma rápida como foi a instalação deste drive em meu notebook.
O modelo do notebook é um Lenovo z40-70, i7, 8GB RAM, 1TB de HD com o drive de DVD/ROM que utilizo pouco.

Medir o CADDY e o DVD. Empilhados.

O primeiro passo é adquirir o drive CADDY e o disco SSD.
Sobre o disco, temos várias opções no mercado. Eu comprei um da Sandisk. Fica a gosto do cliente, seguindo o tamanho de 2,5 pol e sendo SATA.
O CADDY tem poucas opções de mercado, prestando atenção no tamanho do drive.

CADDY de 9.5mm.

Dica:
A maioria dos drives de DVD/ROM são de 9.5mm, para garantir, recomendo já retirar o seu drive de DVD para poder medir ele. Existem os dois tamanhos de 9.5 e 12.7 pol.

Retirando HD do Notebook.

Dica:
Recomendam retirar o HD e colocar o SSD no Lugar.

SSD instalado no lugar do HD.

Os passos de abrir o notebook, desparafusar, retirar encaixes, varia de modelo para modelo de notebook. Contudo, não exige muita capacidade cognitiva. Vamos confiar nessa capacidade, por isso não é necessário fazer um passo-a-passo.

CADDY com o HD. Ao lado, DVD-ROM.

O HD irá ser instalado no CADDY. Existem parafusos laterais que irão ajudar a encaixar o HD no drive do CADDY.
Depois é só colocar o CADDY no lugar do DVD e correr para felicidade de ganhar mais performance em seu notebook.

Dica:
Após completar a instalação.
Verificar na BIOS do notebook se o mesmo identificou na porta SATA o SSD e se em "SATA Configuration" está como AHCI.

Configuração de AHCI na BIOS.

Agora será necessário instalar o Sistema Operacional desejado.
Eu escolhi um Linux, o Mint 18.
Agora fica ao gosto do cliente, escolher o melhor sistema que lhe agrade.
Lembrando que os seus arquivos pessoais estarão no Disco Rígido, mantendo somente o OS e programas no SDD, evitando escritas de arquivos direto no SSD.

Também temos outros posts, onde descrevo dicas para melhorar a performance e dicas de aumento da vida útil do SSD.

As dicas de configuração que podem ser aplicadas no Mint, Ubuntu e Debian.
Abaixo as dicas:

- SSD - Limitar o uso de Memória SWAP (Swappiness)

- SSD - Executar o TRIM

- SSD - Noatime

- SSD - Espaço reservado para overprovisioning do SSD

- SSD - Outras dicas para aumentar a vida útil

Mensagem de erro ao realizar Update Project Maven Eclipse

Tentando fazer update em um projeto Maven (botão direito no projeto → Maven → Update Project), aparecia uma mensagem de erro e tive dificuldades em solucionar este problema.

Mensagem de erro:
Cannot nest '/src/main/resources' inside 'atm/src'. To enable the nesting exclude 'main/' from '/src'

Para solucionar o problema, temos que definir o diretório "main/" como sendo "excluded" nas opções de Source Folders on Build Path.

Solucionando o Problema / Caminho:
→ Clicar botão direito no projeto → Properties →Java Build Path.
→ Selecionar a opção "Excluded"

 

→ Clicar em "Edit"

→ Add na opção de Exclusion Patterns.

→ Incluir o diretório "main/" para ser excluído.

Depois de realizar esses passos, poderá fazer o update do projeto pelo Maven.

Nome do StoryBoard IOS - XCODE 7

Em uma implementação de um @protocol do Facebook, queria redirecionar para um novo ViewController.
Contudo, teria que recriar o StoryBoard para realizar esta atividade.
Depois de fazer login no facebook, executa método loginButton. Implementei o método para recriar o SB e enviar para outro ViewController.
Veja o código abaixo:

 //Implementacoes do Protocol do botão do Facebook.  
 -(void)loginButton:(FBSDKLoginButton *)loginButton didCompleteWithResult:(FBSDKLoginManagerLoginResult *)result error:(NSError *)error{  
   NSLog(@"Logado");  
   UIStoryboard *sb = [UIStoryboard storyboardWithName:@"Main.storyboard" bundle:nil];  
   UIViewController *vc = [sb instantiateViewControllerWithIdentifier:@"SegundoLoginVC"];  
   vc.modalTransitionStyle = UIModalTransitionStyleFlipHorizontal;  
   [self presentViewController:vc animated:YES completion:NULL];  
   //[self performSegueWithIdentifier:@"segundoLoginFB" sender:self];  
 }  

Ocorria o seguinte erro, onde não sabia o nome id do meu StoryBoard.

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Could not find a storyboard named 'Main.storyboard' in bundle NSBundle 

Para saber o nome do StoryBoard, vemos no arquivo .plist.

Git - GitHub - Controle de Versão - Desfazendo e Refazendo

Este é o quinto artigo sobre o Git.
Para ler o primeiro artigo, com comandos essenciais. Clique aqui.
Para ler o segundo artigo, com comandos para servidores remotos. Clique aqui.
Para ler o terceiro artigo, com comandos para fazer Tags/Releases. Clique aqui.
Para ler o quarto artigo, com comandos para Branchs. Clique Aqui.

Estudando sobre como voltar versões de arquivos e commits, senti dificuldade em diferenciar os comandos checkout, reset e revert.
A diferença entre esses comandos são interessantes, vamos começar com exemplos práticos, para identificar a diferença entre eles e saber quando usar.
O Git tem três componentes principais:
1 - Diretório de Trabalho
2 - Snapshot
3 - Histórico de Commits
Lembre-se destes componentes para saber a diferença do que estamos fazendo.

Checkout.
O comando checkout já é conhecido para entrar em branch, contudo podemos utilizar ele para verificar revisões antigas do nosso sistema.
Imagina que queira verificar como era o seu sistema na versão v.2.0, simular algumas funções nesta versão antiga.
O comando checkout altera o seu diretório de trabalho com a versão informada, por isso, antes de realizar o comando é necessário fazer commit das alterações que você realizou.
Eu vi na Internet algumas pessoas usando o checkout de uma forma de desfazer os commits realizados, o checkout não deve ser usado desta forma, somente para verificar versões antigas, uma forma de consulta.
Vou verificar a versão do meu sistema de exemplo na versão v.2.0.
Primeiramente criei um branch, não economizem na criação de branch é rápido e utiliza poucos recursos. Como o git trabalha com apontamentos, criar um branch é bem economico e te ajuda muito no trabalho.
Depois verifiquei as tags que criei e utilizei o comando git checkout v.2.0, com este comando nosso diretório de trabalho já foi substituído para a versão 2.0 e podemos fazer as verificações necessárias.
Verifique os comandos abaixo.

$ git branch testeCheckout  
$ git checkout testeCheckout  
 Switched to branch 'testeCheckout'  
 MacMiniRomero:TesteStoryBoard douglasromero$ git branch  
  Teste_2  
  master  
 * testeCheckout  
$ git tag  
 v.1.0  
 v.2.0  
 v.3.0  
$ git checkout v.2.0  
 Note: checking out 'v.2.0'.  
 You are in 'detached HEAD' state. You can look around, make experimental  
 changes and commit them, and you can discard any commits you make in this  
 state without impacting any branches by performing another checkout.  
 If you want to create a new branch to retain commits you create, you may  
 do so (now or later) by using -b with the checkout command again. Example:  
  git checkout -b <new-branch-name>  
 HEAD is now at 2128d14... Segunda Parte do Tutorial  

O git somente faz um apontamento para a versão 2.0. Os snapshots e o histórico de commits continuam existindo.
No exemplo abaixo, mandei exibir os commits da versão 2.0 e depois fiz um checkout em um versão mais recente, 3.0, depois executei o git log para exibir os commits, verificamos que tudo isso continua existindo no branch, histórico de commits e shapshot

$ git log --oneline  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  
$ git checkout v.3.0  
 Previous HEAD position was 2128d14... Segunda Parte do Tutorial  
 HEAD is now at 02215fd... Inserindo arquivo de ignore.#  
$ git log --oneline  
 02215fd Inserindo arquivo de ignore.#  
 d28226b Update TesteStoryBoardTests.m  
 81c3aa1 Merge branch 'master' of https://github.com/dsromerobr/TesteStoryBoard  
 55f8e2a Deletando arquivos de configuração de usuário. Ok.  
 aa3945a Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 afb0c3e Create README.md  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  

O checkout também aceita passar um arquivo, caso queremos restaurar somente o histórico de um arquivo.

$ cat arquivo.txt   
 primeiro commit.  
 segundo commit.  
 terceiro commit.  
 quarto commit.  
$ git log --oneline  
 9d1e52e quarto commit  
 44bd001 terceiro commit  
 ce62788 segundo commit  
 7cc5847 arquivo de teste 1  
 02215fd Inserindo arquivo de ignore.#  
 d28226b Update TesteStoryBoardTests.m  
 81c3aa1 Merge branch 'master' of https://github.com/dsromerobr/TesteStoryBoard  
 55f8e2a Deletando arquivos de configuração de usuário. Ok.  
 aa3945a Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 afb0c3e Create README.md  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  
$ git checkout ce62788 arquivo.txt   
$ cat arquivo.txt   
 primeiro commit.  
 segundo commit.  

Lembrando que o checkout mexe somente com o diretório de trabalho. Se executarmos o git status, mostrará que tem um arquivo modificado para entrar em staged.

 $ git status  
 On branch testeCheckOutArquivo  
 Changes to be committed:  
  (use "git reset HEAD <file>..." to unstage)  
      modified:  arquivo.txt  

Reset.
O comando reset é um modo de voltar o snapshot para um ponto específico.
Imagina que você fez 3 commits e queira voltar para um ponto específico, assim removendo os commits, este comando consegue fazer isso.
O reset é o comando mais complicado e deve ser usado com cautela.
Este comando tem 3 flags.
--soft -> O diretório de trabalho e o snapshot não são alterados.
--mixed -> O snapshot é alterado mas o diretório de trabalho não altera. Default.
--hard -> Altera tudo para o ponto específico.

Vamos utilizar o parâmetro --soft, onde foram feitos diversos commits com somente o arquivo.txt, gostaria de realizar somente um commit dele. Executando o comando reset com o parâmetro --soft, gostaria de fazer somente 1 commit. Escolhi o commit de hash 7cc5847, assim o snapshot e o diretório de trabalho serão mantidos e farei somente um commit.

$ git log --oneline  
 9d1e52e quarto commit  
 44bd001 terceiro commit  
 ce62788 segundo commit  
 7cc5847 arquivo de teste 1  
 02215fd Inserindo arquivo de ignore.#  
 d28226b Update TesteStoryBoardTests.m  
 81c3aa1 Merge branch 'master' of https://github.com/dsromerobr/TesteStoryBoard  
 55f8e2a Deletando arquivos de configuração de usuário. Ok.  
 aa3945a Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 afb0c3e Create README.md  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  
$ git branch  
  master  
  testeCheckOutArquivo  
 * testeReset  
$ git reset --soft 7cc5847  
$ git log --oneline  
 7cc5847 arquivo de teste 1  
 02215fd Inserindo arquivo de ignore.#  
 d28226b Update TesteStoryBoardTests.m  
 81c3aa1 Merge branch 'master' of https://github.com/dsromerobr/TesteStoryBoard  
 55f8e2a Deletando arquivos de configuração de usuário. Ok.  
 aa3945a Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 afb0c3e Create README.md  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  
$ git status  
 On branch testeReset  
 Changes to be committed:  
  (use "git reset HEAD <file>..." to unstage)  
      modified:  arquivo.txt  

O git reset aceita um arquivo como parâmetro, diferente do checkout, que trás a versão antiga do arquivo para o snapshot atual, o reset manda a versão do arquivo atual para um determinado snapshot.
Veja o exemplo abaixo:

$ git reset Head~1 arquivo.txt   
 Unstaged changes after reset:  
 M     arquivo.txt  
 MacMiniRomero:TesteStoryBoard douglasromero$ cat arquivo.txt   
 primeiro commit.  
 segundo commit.  
 terceiro commit.  
 quarto commit.  
 quinto commit.  
 sexto commit.  
$ git log --oneline  
 cff27cc nova version  
 a22627f Commit de teste !!!  
 6584065 Merge branch 'teste2' into testeCheckOutArquivo Teste de Mergeeeeee  
 611c47d teste de commit do branch  
 9d1e52e quarto commit  
 44bd001 terceiro commit  
 ce62788 segundo commit  
 7cc5847 arquivo de teste 1  
 02215fd Inserindo arquivo de ignore.#  
 d28226b Update TesteStoryBoardTests.m  
 81c3aa1 Merge branch 'master' of https://github.com/dsromerobr/TesteStoryBoard  
 55f8e2a Deletando arquivos de configuração de usuário. Ok.  
 aa3945a Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 afb0c3e Create README.md  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  
$ git checkout a22627f  
 M     arquivo.txt  
 Note: checking out 'a22627f'.  
 You are in 'detached HEAD' state. You can look around, make experimental  
 changes and commit them, and you can discard any commits you make in this  
 state without impacting any branches by performing another checkout.  
 If you want to create a new branch to retain commits you create, you may  
 do so (now or later) by using -b with the checkout command again. Example:  
  git checkout -b <new-branch-name>  
 HEAD is now at a22627f... Commit de teste !!!  
$ cat arquivo.txt  
 primeiro commit.  
 segundo commit.  
 terceiro commit.  
 quarto commit.  
 quinto commit.  
 sexto commit.  

Revert.
Este é o comando seguro para desfazer coisas, os outros comandos são interessantes para branchs privados, contudo em branchs públicos, como o GitHub, utilizar o revert é a melhor opção para evitar problemas.
Execute o comando abaixo:

 $ git revert 2128d14  

Ele irá fazer um merge e poderá ocorrer conflitos.
Assim, tem os parâmetros para dar sequencia em caso de conflitos.
git revert --continue
git revert --abort
git revert --quit

Git - GitHub - Controle de Versão - Branchs

Este é o quarto artigo sobre o Git.
Para ler o primeiro artigo, com comandos essenciais. Clique aqui.
Para ler o segundo artigo, com comandos para servidores remotos. Clique aqui.
Para ler o terceiro artigo, com comandos para fazer Tags/Releases. Clique aqui.

Branch ou Ramificações é um conceito muito interessante no Git.
Nos sistemas CVS comuns no mercado, fazer um Branch é um processo trabalhoso e demorado, mas no Git este processo é bem rápido e fácil.
Somente é feito um apontamento para um snapshot do master, com isso, não é necessário copiar todos os arquivos como nos outros sistemas de controle de versão.

Criando um Branch.
Para criar um novo Branch, utilizamos o comando abaixo.

 $ git branch Teste  
 $ git branch  
  Teste  
 * master  

Depois digitamos o comando git branch, onde exibe todos branchs. Repare que o *, na frente do master, exibe qual branch estamos. Atualmente estamos trabalhando no Master. No branch que estamos trabalhando é chamado de Head.
Agora vamos mudar para o Branch que criamos, através do comando checkout.

$ git checkout Teste  
 Switched to branch 'Teste'  
$ git branch  
 * Teste  
  master  

Agora identificamos que alteramos para o branch Teste. Repare no * na frente do Branch Teste.
Alterei um arquivo no branch Teste e o mesmo arquivo no Master, para simular um conflito.
Sempre que for alterar de branch, verifique se fez commit das suas alterações.

 $ git commit -a -m "Testando Branch #1"  

Depois fazer o checkout para o master.

 $ git checkout master  
 Switched to branch 'master'  
 Your branch is ahead of 'origin/master' by 1 commit.  
  (use "git push" to publish your local commits)  

Agora usamos o comando git merge, para fazer o merge dos arquivos. No caso, irá ocorrer um conflito, conforme abaixo.

 $ git merge Teste  
 Auto-merging TesteStoryBoard/Base.lproj/Main.storyboard  
 CONFLICT (content): Merge conflict in TesteStoryBoard/Base.lproj/Main.storyboard  
 Automatic merge failed; fix conflicts and then commit the result.  
 MacMiniRomero:TesteStoryBoard douglasromero$ git status  
 On branch master  
 Your branch is ahead of 'origin/master' by 1 commit.  
  (use "git push" to publish your local commits)  
 You have unmerged paths.  
  (fix conflicts and run "git commit")  
 Unmerged paths:  
  (use "git add <file>..." to mark resolution)  
      both modified:  TesteStoryBoard/Base.lproj/Main.storyboard  
 no changes added to commit (use "git add" and/or "git commit -a")  

Resolvendo Conflitos.
Utilizamos a ferramenta mergetool. Na versão que estou utilizando, no MAC OSX, defini para utilizar a ferramenta externa opendiff, que veem com o mac.

 $ git mergetool --tool=opendiff   

Abrirá uma tela com os arquivos para você realizar o merge manual.

Depois de resolver os conflitos, conseguirá realizar o commit.

Deletando um Branch.
Para deletar um branch, utilizamos o comando branch com o parâmetro -D.

$ git branch -D teste  
 Deleted branch teste (was 4c9d7fd).  

Listagem de Branch.
Para ver o último commit em cada branch, interessante para saber os status de cada um.

 $ git branch -v  
  NorthWind 4c9d7fd Revert "Segunda Parte do Tutorial"  
  SouthWind 4c9d7fd Revert "Segunda Parte do Tutorial"  
 * master  4c9d7fd [ahead 1] Revert "Segunda Parte do Tutorial"  

Listar somente os branchs que sofreram merge.

 $ git branch --merged  
  NorthWind  
 * master  

Somente os branchs que não sofreram merge.

 $ git branch --no-merged  
  SouthWind  

Branch Remotos.
Quando fazemos o clone de um branch, cria automaticamente o server remoto como sendo origin.
Para referenciar branchs remotos, utilizamos: remote/branch
Veja o exemplo abaixo de um checkout em um server remoto.

$ git status origin/master  
 On branch master  
 Your branch is ahead of 'origin/master' by 2 commits.  
  (use "git push" to publish your local commits)  
 nothing to commit, working directory clean  
$ git checkout origin/master  
 Note: checking out 'origin/master'.  
 You are in 'detached HEAD' state. You can look around, make experimental  
 changes and commit them, and you can discard any commits you make in this  
 state without impacting any branches by performing another checkout.  
 If you want to create a new branch to retain commits you create, you may  
 do so (now or later) by using -b with the checkout command again. Example:  
  git checkout -b <new-branch-name>  
 HEAD is now at 02215fd... Inserindo arquivo de ignore.#  
$ git log --oneline  
 02215fd Inserindo arquivo de ignore.#  
 d28226b Update TesteStoryBoardTests.m  
 81c3aa1 Merge branch 'master' of https://github.com/dsromerobr/TesteStoryBoard  
 55f8e2a Deletando arquivos de configuração de usuário. Ok.  
 aa3945a Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 afb0c3e Create README.md  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  
$ git branch  
 * (HEAD detached at origin/master)  
  NorthWind  
  SouthWind  
  master  

Para sincronizar o seu branch com o remoto, utilizamos o seguinte comando:

 $ git fetch origin  

Criando Servidor Remoto.
Também é possível adicionar outro servidor remoto e fazer a referencia para acessar ele, para adicionar outro servidor remoto:

 $ git remote add testeremote https://github.com/dsromerobr/TesteStoryBoard.git  

Verificar os servidores remotos.

 $ git remote -v  
 origin     https://github.com/dsromerobr/TesteStoryBoard.git (fetch)  
 origin     https://github.com/dsromerobr/TesteStoryBoard.git (push)  
 testeremote     https://github.com/dsromerobr/TesteStoryBoard.git (fetch)  
 testeremote     https://github.com/dsromerobr/TesteStoryBoard.git (push)  

Enviando dados (Pushing).
Para enviar dados para o servidor remoto, utilizamos o comando Push.
Vamos criar um branch remoto SouthWind, também podemos criar o Branch com outro nome, alterando para SouthWind:NOVONOME.

 $ git push origin SouthWind:SouthWind  
 Counting objects: 23, done.  
 Delta compression using up to 8 threads.  
 Compressing objects: 100% (18/18), done.  
 Writing objects: 100% (23/23), 3.98 KiB | 0 bytes/s, done.  
 Total 23 (delta 6), reused 0 (delta 0)  
 To https://github.com/dsromerobr/TesteStoryBoard.git  
  * [new branch]   SouthWind -> SouthWind  

Para fazer push para o branch.

 $ git push origin SouthWind  
 Everything up-to-date  

Pegando um novo Branch remoto.
Caso você tenha que trabalhar em um branch, para fazer checkout e criar este branch remoto, utilizamos o comando checkout.

 $ git checkout -b SouthWind origin/SouthWind  
 Branch SouthWind set up to track remote branch SouthWind from origin.  
 Switched to a new branch 'SouthWind'  
 $ git branch  
  NorthWind  
 * SouthWind  
  master  

Leia o quinto artigo, desfazendo e refazendo.

Git - GitHub - Controle de Versão - TAGS

Esta é a terceira parte do artigo sobre Git.
Para ler o primeiro artigo, com comandos essenciais. Clique aqui.
Para ler o segundo artigo, com comandos para servidores remotos. Clique aqui.

Um recurso interessante é criar TAGs, para marcar pontos de release do seu sistema/aplicativo.

Listando Tags.
O comando abaixo exibe as Tags cadastradas no repositório.

  $ git tag   
  v.3.0   

Executando o comando show, podemos ver os detalhes sobre a tag, como a anotação, quem fez a tag, etc.

 $ git show v.3.0  
 tag v.3.0  
 Tagger: Douglas Romero <romero@dsromero.com.br>  
 Date:  Tue Oct 20 10:20:38 2015 -0200  
 Teste de Tags  
 commit 02215fdcd470b0c55bc8a1cb94cc56897e9bc892  
 Author: Douglas Romero <romero@dsromero.com.br>  
 Date:  Tue Oct 20 08:53:43 2015 -0200  
   Inserindo arquivo de ignore.#  
 diff --git a/.gitignore b/.gitignore  
 new file mode 100644  
 index 0000000..07cb108  
 --- /dev/null  
 +++ b/.gitignore  
 @@ -0,0 +1,2 @@  
 +TesteStoryBoard.xcodeproj/xcuserdata/  
 +TesteStoryBoard.xcodeproj/project.xcworkspace/xcuserdata/  
 diff --git a/TesteStoryBoard/Base.lproj/Main.storyboard b/TesteStoryBoard/Base.lproj/Main.storyboard  
 index 5482739..73b6efb 100755  
 --- a/TesteStoryBoard/Base.lproj/Main.storyboard  
 +++ b/TesteStoryBoard/Base.lproj/Main.storyboard  
 @@ -80,7 +80,7 @@  
              <autoresizingMask key="autoresizingMask" widthSizable="YES" heightSizable="YES"/>  
              <subviews>  
                <label opaque="NO" userInteractionEnabled="NO" contentMode="left" horizontalHuggingPriority="251" verticalHuggingPriority="251" fixedFrame="YES" restorationIdentifier="sbSegundoLabel" text="Segunda Tela " textAlignment="natural" lineBreakMode="tailTruncation" baselineAdjustment="alignBaselines" adjustsFontSizeToFit="NO" translatesAutoresizingMaskIntoConstraints="NO" id="GKn-eI-peT">  
 -                <rect key="frame" x="29" y="101" width="108" height="21"/>  
 +                <rect key="frame" x="29" y="101" width="541" height="21"/>  
                  <fontDescription key="fontDescription" type="system" pointSize="17"/>  
                  <color key="textColor" red="0.0" green="0.0" blue="0.0" alpha="1" colorSpace="calibratedRGB"/>  
                  <nil key="highlightedColor"/>  

Criando Tags.
Utilizando o comando abaixo, criamos uma Tag anotada, utilizando o parametro -a, passando o nome da versão e o -m e em seguida a mensagem para a tag anotada.
Também pode-se criar tag sem esta anotação, chamada de Tag leve.

 $ git tag -a v.3.0 -m "Teste de Tags"  

Criando Tags de commits anteriores.
Vamos ver o log de commits de nossa aplicação.

 $ git log --oneline  
 02215fd Inserindo arquivo de ignore.#  
 d28226b Update TesteStoryBoardTests.m  
 81c3aa1 Merge branch 'master' of https://github.com/dsromerobr/TesteStoryBoard  
 55f8e2a Deletando arquivos de configuração de usuário. Ok.  
 aa3945a Commit com alterações do exemplo de GIT. Inclusão de uma property na primeira tela.  
 afb0c3e Create README.md  
 2128d14 Segunda Parte do Tutorial  
 7eda703 Initial Commit  

Queremos criar como sendo o primeiro commit a versão v.1.0, para isso pegamos o código de verificação do commit e fazemos o comando abaixo.

 $ git tag -a v.1.0 -m "Primeira versão do tutorial de trabalhando com StoryBoard" 7eda703   

A tag está criado para o nosso Initial Commit.

 $ git show v.1.0  
 tag v.1.0  
 Tagger: Douglas Romero <romero@dsromero.com.br>  
 Date:  Tue Oct 20 10:47:54 2015 -0200  
 Primeira versão do tutorial de trabalhando com StoryBoard  
 commit 7eda7033bcc848f39fc73f643a0b6babe153af3e  
 Author: Douglas Romero <douglasromero@macminiromero.local>  
 Date:  Mon Oct 5 17:25:22 2015 -0300  
   Initial Commit  

Compartilhando as Tags para o servidor remoto.
Por padrão, utilizando o comando git push, não manda as tags para o servidor remoto.
Utilizamos o comando git push, passando o servidor e o nome da tag, assim as tags serão transferidas para o servidor.

$ git push origin v.1.0  
 Counting objects: 1, done.  
 Writing objects: 100% (1/1), 202 bytes | 0 bytes/s, done.  
 Total 1 (delta 0), reused 0 (delta 0)  
 To https://github.com/dsromerobr/TesteStoryBoard.git  
  * [new tag]     v.1.0 -> v.1.0  
$ git push origin --tags  
 Counting objects: 2, done.  
 Delta compression using up to 8 threads.  
 Compressing objects: 100% (2/2), done.  
 Writing objects: 100% (2/2), 322 bytes | 0 bytes/s, done.  
 Total 2 (delta 0), reused 0 (delta 0)  
 To https://github.com/dsromerobr/TesteStoryBoard.git  
  * [new tag]     v.2.0 -> v.2.0  
  * [new tag]     v.3.0 -> v.3.0  

O segundo comando, passando o parametro --tags, manda todas as tags para o servidor remoto.
É isso Pessoal... agora sabemos como trabalhar com Tags. : )

Leia o terceiro artigo, trabalhando com branchs.

Git - GitHub - Controle de Versão - Servidores Remotos

Esta é a segunda parte do artigo sobre Git, caso não tenha lido a primeira parte, com os comandos essenciais, veja no seguinte link.

Nós temos o nosso Git local e agora vamos ver como trabalhar com o servidor remoto, neste exemplo vou utilizar o GitHub. Você poderá ter o servidor remoto na sua empresa ou em qualquer outro local.

Listando servidores remotos.
Caso tenha feito um git clone de algum servidor remoto, terá os servidores remotos configurados.
Executando o comando abaixo, temos o seguinte retorno.

 $ git remote -v  
 origin     https://github.com/dsromerobr/TesteStoryBoard.git (fetch)  
 origin     https://github.com/dsromerobr/TesteStoryBoard.git (push)  

Por padrão, o git chama o servidor remoto de origin.

Pull - Pegando novos dados do Servidor.
Este comando irá pegar todas as atualizações do servidor remoto e tentar fazer o merge automático, caso alguém tenha enviado uma nova alteração para o servidor remoto.

 $ git pull origin

Push - Enviando dados para o Servidor.
Enviando para o servidor remoto as alterações, executar o seguinte comando.

 $ git push origin master  

Para ajudar a lembrar... : )

Inspecionando um Servidor Remoto.
Este comando retorna informações do servidor remoto, como qual servidor ele realiza o git push e git pull automático, sem definir servidor. Também branchs monitoradoros, etc.

$ git remote show origin  
 * remote origin  
  Fetch URL: https://github.com/dsromerobr/TesteStoryBoard.git  
  Push URL: https://github.com/dsromerobr/TesteStoryBoard.git  
  HEAD branch: master  
  Remote branch:  
   master tracked  
  Local branch configured for 'git pull':  
   master merges with remote master  
  Local ref configured for 'git push':  
   master pushes to master (up to date)  

Estes são os comandos básicos para trabalhar com servidores remotos git.
Agora leia o terceiro artigo sobre Git, trabalhando com TAGs.