Processos, compactação e introdução ao GIT

Básico sobre processos

O que é um processo?

Um processo é um programa em execução .

Um sistema operacional lida com uma infinidade de processos, que possuem as seguintes características:

Cada processo possui um número identificador, chamado de PID (Process Identifier), que é utilizado para controlá-lo.

Estados dos processos

Interrompendo e listando processos

Visualizando processos estaticamente com “ps”

O comando ps mostra os processos em execução atualmente e exibe os UIDs e PIDs de cada um.

Ao executar o ps sem nenhuma opção, serão apresentados os processos em execução no terminal.

$ ps
 PID TTY           TIME CMD
 1234 pts/0    00:00:02 bash
 9101 pts/0    00:00:00 ps

As opções mais importantes para o comando ps são:

-u [username] - mostra os processos existentes de um usuário específico;

-f - Exibe uma lista completa com informações adicionais como PPID (ID do processo pai).

-l - exibe mais campos no resultado;

-e ou -A : Lista todos os processos no sistema.

-x - exibe os processos que não iniciados no console do terminal junto com os inicializados no console.

aux: Exibe uma listagem detalhada com o uso de memória por cada processo.

O uso do “ps” com o “grep”

O ps é uma ferramenta essencial e corriqueira. Já a usamos quase que automaticamente com o grep, porém, somos limitados a filtrar um processo por vez. Por exemplo, para ver os processos systemd:

ps aux | grep systemd

Primeiro, o comando ps aux mostra todos os processos em execução, enquanto grep systemd filtra apenas os processos que contêm “systemd” em sua descrição.

Uso do “kill”

O comando kill é usado no Linux para enviar sinais a processos. Esses sinais podem instruir o processo a realizar várias ações, como terminar, parar ou continuar a execução. Quando usamos kill para matar um processo, estamos enviando um sinal específico que informa o processo que ele deve encerrar.

Como ver os possíveis sinais?

Existem múltiplos sinais disponíveis no Linux que podem ser utilizados para interromper, encerrar ou pausar processos. O comando pode ser usado como mostrado abaixo:

    kill -l

Este comando irá mostrar uma página do manual com diferentes sinais do comando kill e seus respectivos números. Embora existam muitos sinais disponíveis, na maioria das vezes utilizamos o SIGKILL (9) e SIGTERM (15).

Significados dos principais sinais

SIGHUP (1): Ocorre quando o terminal fecha ou quando o processo pai finaliza sua execução.

SIGINT (2): Interrompe ou para um processo, geralmente gerado pelo usuário pressionando Ctrl+C no terminal.

SIGKILL (9): Força a parada imediata de um processo, não pode ser capturado ou ignorado pelo processo.

SIGTERM (15): Solicita a terminação “elegante” do processo, permitindo que ele libere recursos antes de encerrar, termine o que está fazendo e feche.

SIGTSTP (20): Solicita ao terminal a interrupção temporária do processo (parar/pausar), geralmente gerado pelo usuário pressionando Ctrl+Z.

SIGCONT (18): Retoma um processo pausado pelo sinal SIGTSTP (ou SIGSTOP).

Como realmente matar processos?

Por padrão, é enviado o sinal SIGTERM, que requisita a finalização do processo, por isso o nome kill (matar). Em geral é usado desta forma:

kill PID

Você tamvém pode usar o comando kill seguido pelo número do sinal e o PID (Process ID) do processo que deseja terminar.

    kill -8 <PID>

Uso do killall

O comando killall no Linux envia sinais para os processos e recebe como parâmetro não o PID do processo, mas seu nome. Ele é usado geralmente para terminar a execução de processos que possuem diversos processos filhos executando ao mesmo tempo.

Sintaxe básica
killall [opções] nome_do_processo

Você pode enviar um sinal específico para os processos de mesmo nome como:

killall -9 firefox
Verificando antes de Encerrar

Para verificar quais processos seriam encerrados sem realmente matá-los, use a opção -i para interação

killall -i firefox
Encerrando Processos de um Usuário Específico

Para encerrar processos de um usuário específico, use a opção -u:

killall -u usuario firefox

Uso e visualização processos dinâmicamente com “htop”

O comando HTOP é um utilitário de linha de comando que tem como objetivo auxiliar o usuário a monitorar de forma interativa e em tempo real os recursos de seu sistema operacional Linux.

Instalar “htop” no Ubuntu
sudo apt install htop

Iniciar a ferramenta

htop

Rodando processos em background

Uso do & comercial no shell

No Linux, um processo pode estar em foreground ou em background, ou seja, em primeiro plano ou em segundo plano. Por exemplo, ao digitar o comando:

ping google.com

Quando você executa o comando ping em primeiro plano (sem o ‘&’ no final), ele ocupa o terminal até que você interrompa manualmente a execução. Isso significa que você não poderá usar o terminal para outros comandos até que o ping termine ou seja interrompido.

Seu terminal ficará assim:

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.045 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.032 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.030 ms

Para interromper o ping em primeiro plano, use Ctrl + C. Isso envia um sinal de interrupção (SIGINT) para o processo ping, fazendo com que ele termine a execução e exiba um resumo das estatísticas:

^C
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.030/0.035/0.045/0.007 ms

Para o exemplo acima, é possível liberar o shell para outras atividades enquanto o o processo gerado pelo comando fica em segundo plano. Basta que você digite:

ping google.com &

O símbolo & indica que o comando deve ser executado em background, ou seja, em segundo plano.

Você verá uma mensagem que indica o número do trabalho ([1]) e o PID do processo (1234):

Ver lista de processos em segundo plano

Para poder ver quais processos em segundo plano, digite:

jobs

Irá aparecer algo como:

[1]+  Running          ping 127.0.0.1 &

Note que, se você fizer CTRL + C, o processo não será interrompido, pois ele não está em primeiro plano(foreground).

Trazer para “foreground”

Vamos supor que você pretende trazer o processo para primeiro plano. Para isso, utilize o seguinte comando :

fg %1

Agora você pode matá-lo diretamente utilizando o CTRL + c , que manda o sinal SIGINT, que faz com que ele termine a execução e exiba um resumo das estatísticas :

^C
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.030/0.035/0.045/0.007 ms
Retomando processos suspensos em background

Agora, digite o seguinte comando:

ping 127.0.0.1

Em seguida, digite CTRL + Z para suspender o comando bing. Esse comando pausa o processo e o colocar em segundo plano em estado de pausa(suspenso).

^Z
[1]+  Stopped                 ping 127.0.0.1

Para retomar o processo em segundo plano, é necessário utilizar o comando bg da seguinte forma:

bg %1

Agora, vamos digitar o comando jobs para ver o estado dos processos em background.

$ jobs
 [1]+  Running                 ping 127.0.0.1 &

Uso do “nohup”

Mesmo que um processo esteja em segundo plano, ele pode ser interrompido por vários motivos.

Digamos que você tenha terminado seu trabalho e feche sua sessão de SSH. Lembra daquele processo de longa duração que você iniciou? Sumiu! Quando você sai da sessão, o sistema envia um sinal especial para cada processo iniciado que ainda está em execução chamado “SIGHUP”. Esse sinal desliga o processo mesmo quando ele ainda tem trabalho a fazer. Isso é o que o comando nohup pretende corrigir.

Há outras maneiras, é claro, para um processo ser encerrado, mas o comando nohup refere-se especificamente aos encerrados devido ao sinal SIGHUP.

Nohup - abreviação de ‘no hang up’, ou ‘não desligar’, em Português - é um comando em sistemas Linux que mantém os processos em execução mesmo depois de sair do shell ou terminal. O Nohup impede que os processos ou trabalhos recebam o sinal SIGHUP (Signal Hang UP). Este é um sinal que é enviado para um processo ao fechar ou sair do terminal.

Sintaxe do comando nohup

A sintaxe para usar o comando Nohup é direta:

nohup command [options] &

command: especifica o comando ou script que você deseja executar.

[options]: argumentos opcionais ou sinalizadores que modificam o comportamento do comando.

&: Colocar este símbolo ao final de um comando instrui o shell a executar esse comando em segundo plano.

Iniciando um processo usando o Nohup

Para iniciar um processo usando o Nohup, basta preceder o comando desejado com nohup. Por exemplo, se você deseja executar o comando sleep 60(que faz o sistema esperar 60 segundos) chamado usando Nohup, você deve usar o seguinte comando:

nohup sleep 60 &

Com o comando acima, o sistema executa um comando “sleep”, que normalmente bloqueia todas as entradas, mas isso as envia para o segundo plano, graças ao parâmetro “&”. Executá-lo tem a seguinte aparência:

$ nohup sleep 60 &
[1] 4003
$ nohup : ignoring input and appending output to 'nohup.out'
Deixando de fora o caractere ‘&’

Você pode até mesmo usar o comando nohup sem o caractere “&” enviando o processo para o segundo plano. Mas isso simplesmente significa que o processo será executado em primeiro plano e que você não poderá fazer nenhum outro trabalho no terminal até que ele seja concluído. Geralmente, para tarefas de longa duração, o usuário envia para segundo plano, já que não faz sentido esperar sem necessidade.

Caso você use o nohup mantendo o processo em primeiro plano, pode ter certeza de que, se o terminal for fechado, ou a conectividade com a Internet for perdida, ou algo mais acontecer, o processo não será interrompido. Mas, como mencionado acima, você quase sempre vai querer executar o comando em segundo plano.

Uso do “wait”

O comando “wait” é uma ferramenta poderosa no Linux que permite que os scripts aguardem a conclusão de outros processos antes de continuar a execução.

Por exemplo:

 $ nohup sleep 30 &
 [1] 5010
$ wait 5010

Depois de digitar o comando wait <PID>, o terminal irá esperar o proceso ser finalizado.

Uso de programas de compatação para compartilhar e receber arquivos

Compactação

Compactando diretórios com zip

Compactar arquivos significa juntar todos eles em um único arquivo de modo que eles ocupem um espaço menor.

Provavelmente você já viu algum arquivo com a extensão .zip. No Linux, para compactar arquivos no formato .zip, é utilizado o comando zip.

Vamos supor que temos uma pasta chamada “projetos” e, dentro dela, dois subdiretórios chamados “ITP” e “PC”, onde estão todos os programas que você fez durante as disciplinas. Surgiu o seguinte problema: você gostaria de enviar esses arquivos pelo WhatsApp para um colega recém-chegado no curso, mas o WhatsApp não permite o envio devido ao tamanho dos arquivos. Por isso, você decidiu compactar os projetos.

Para isso, digitou:

    zip projetos.zip projetos/

depois, executou o seguinte comando para poder visualizar se todos os diretórios foram armazenados no arquivo compactado “projetos.zip”:

    unzip -l projetos.zip

e viu o seguinte:

  $ Archive:  projetos.zip
    Length      Date    Time    Name
    ---------  ---------- -----   ----
            0  2023-07-09 12:00   projetos/
    ---------                     -------
            0                     1 file

Note que ocorreu um problema, pois os subdiretórios não foram inseridos na compactação. Isso ocorre pois, por padrão, o comando zip não inclui os arquivos e subdiretórios de um diretório. Assim, nosso .zip contém apenas o diretório Projetos/ vazio. Para resolver, basta passar o argumento -r(recursive).

O -r fará com que o comando zip processe recursivamente todos os subdiretórios e arquivos dentro do diretório especificado, garantindo que tudo seja incluído no arquivo compactado. Vamos corrigir o comando para incluir o argumento -r:

    zip -r projetos.zip projetos/

Agora, vamos ver se tudo foi compactado:

    $ unzip -l projetos.zip 
    Archive:  projetos.zip
    Length      Date    Time    Name
    ---------  ---------- -----   ----
            0  2023-07-09 12:00   projetos/
            0  2023-07-09 12:00   projetos/ITP/
        2048  2023-07-09 12:00   projetos/ITP/programa1.c
        1024  2023-07-09 12:00   projetos/ITP/programa2.c
            0  2023-07-09 12:00   projetos/PC/
        5120  2023-07-09 12:00   projetos/PC/programa1.py
    ---------                     -------
        8192                     6 files

Compactando arquivos e diretórios com tar e gzip

Outra forma de compactar arquivos é utilizando tar e gzip. Quando nos deparamos com arquivos do tipo arquivo.tar.gz, significa que ocorreram dois processos.

Qual a vantagem do tar?

A vantagem é que o tar consegue manter as permissões dos arquivos, bem como links diretos e simbólicos, sendo interessante, por exemplo, para realizar backups.

Utilizamos o comando tar para realizar as compactações. A compactação do diretório “projetos/” ficaria da seguinte forma:

tar -czf projetos.tar.gz projetos/

Note que não precisamos usar o -r. Isso acontece pois o tar age de forma recursiva por padrão.

Descompactação

Descompactando diretórios com unzip

Vamos supor que seu colega, que recebeu o arquivo projetos.zip, deseja descompactá-los . Para isso, ele executará os seguintes passos:

unzip projetos.zip

Isso irá extrair todos os arquivos e diretórios contidos no arquivo “projetos.zip” para o diretório atual. Se desejar extrair para um diretório específico, você pode usar a opção -d:

unzip projetos.zip -d /home/ubuntu/Music

Se você quiser que o progresso não apareça e sua tela fique cheia de informações, é possível utilizar o -q, que significa quiet, para que ele apenas descompacte e não mostre cada coisa que fez:

unzip -q projetos.zip -d /home/ubuntu/Music

Descompactando arquivos e diretórios com tar e gunzip

Para descompactar um arquivo tarball comprimido com gzip, utilizamos o comando tar novamente, desta vez com a opção -x para extrair o conteúdo. Vamos supor que você recebeu o arquivo “projetos.tar.gz” e deseja extrair seu conteúdo:

tar -xzf projetos.tar.gz

Versionadores e Git: Fundamentos e Conceitos

Introdução aos Versionadores

O que são Versionadores?

Versionadores são sistemas que registram alterações em um arquivo ou conjunto de arquivos ao longo do tempo, permitindo lembrar versões específicas mais tarde. Eles surgiram devido à necessidade de aumentar a eficiência, gerenciar um número maior de colaboradores e projetos de software moderno.

Tipos de Versionadores

1. Sistemas Locais

Utilizam um banco de dados simples para manter todas as alterações nos arquivos sob controle de versão.

2. Sistemas Centralizados

Têm um único servidor que contém todos os arquivos de controle de versão e um número de clientes que usam esses arquivos a partir desse lugar central. Suas desvantagens incluem a necessidade de estar sempre conectado ao servidor e a paralisação em caso de falha do servidor.

São utilizados por plataformas como a Wikipédia.

3. Sistemas Distribuídos

Cada cliente possui uma cópia completa do repositório, funcionando como um backup completo de todos os dados.

Não dependem de um servidor central, oferecendo maior eficiência e segurança contra ataques.

Vantagens dos Sistemas Distribuídos

Escalabilidade: Suporta um grande número de colaboradores.

Independência: Não depende de um servidor central.

Eficiência: Processos mais rápidos e eficientes.

Segurança: Maior proteção contra falhas e ataques.

Introdução ao Git

Surgimento do Git

A criação do Linux foi um marco importante na história do desenvolvimento de software, principalmente por sua natureza colaborativa e open-source. Linus Torvalds, o criador do Linux, enfrentou desafios significativos ao coordenar as contribuições de inúmeros desenvolvedores ao redor do mundo.

Durante os anos iniciais do Linux Kernel, as mudanças eram gerenciadas através do envio de arquivos entre desenvolvedores. Posteriormente, usou-se o versionador BitKeeper, mas quando este se tornou pago, a comunidade Linux, liderada por Torvalds, decidiu criar o Git, aprendendo com as lições adquiridas durante o uso do BitKeeper e com um desafio de fazer um sistema de versionamento mais eficiente e com funcionalidades que acelerassem o processo de desenvolvimento de software.

Os objetivos principais para o novo sistema incluíam:

De onde vem o nome “Git”?

O nome “Git” tem uma origem curiosa. Em uma entrevista, Linus Torvalds explicou sarcasticamente que ele nomeia todos os seus projetos em sua homenagem , sendo “Linux” o primeiro e “Git” o segundo. Na gíria britânica, “git” significa “pessoa desagradável”. Além disso, há uma interpretação alternativa em que “Git” pode significar “Global Information Tracker” quando você estiver de bom humor.

Para mais detalhes, você pode consultar o manual do Git no terminal usando o comando man git.

Git como um Versionador

O Git é um dos sistemas de controle de versão mais utilizados no mundo, conhecido por ser:

Como o Git Funciona?

O Git é uma ferramenta de versionamento que gerencia diferentes versões de um arquivo ou conjunto de arquivos. Sempre que você salva o estado do projeto, o Git “tira uma foto” dos arquivos naquele momento e salva uma referência a esse snapshot. Por eficiência, se um arquivo não foi modificado, o Git não o salva novamente, mas cria um “link” para a versão anterior que já está salva.

O Git, em geral, apenas adiciona informações. É difícil que o sistema apague dados ou faça algo irreversível, especialmente se você enviar suas alterações para o servidor remoto regularmente (push). Esse comportamento garante a integridade e a segurança do histórico do projeto.

Hospedagem Remota e Conexões SSH

Introdução a plataformas de hospedagem remota

Voltando aos versionadores

A utilização de versionadores como o Git se torna ainda mais poderosa quando combinada com plataformas de hospedagem remota.

Essas plataformas permitem que você armazene, compartilhe e colabore em projetos de software com desenvolvedores de todo o mundo. Elas não só armazenam o código, mas também oferecem ferramentas para gerenciamento de projetos, integração contínua, e muito mais.

Algumas diferentes plataformas: GitLab, BitBucket, Codeberg

Existem várias plataformas de hospedagem remota que suportam Git, cada uma com suas características únicas.

Git e Github : diferenças

Embora Git e GitHub sejam frequentemente mencionados juntos, eles não são a mesma coisa. Aqui estão as principais diferenças:

Git
GitHub

Chave SSH

Para que serve a chave SSH?

As chaves SSH (Secure Shell) são utilizadas para autenticar conexões seguras entre computadores, permitindo uma comunicação criptografada. Elas substituem a necessidade de senhas tradicionais, proporcionando uma maneira mais segura e conveniente de acessar sistemas remotos e serviços, como repositórios Git.

Ao configurar uma chave SSH, você cria um par de chaves: uma chave privada, que deve ser mantida em segredo no seu computador, e uma chave pública, que é adicionada ao servidor ou serviço remoto. Quando uma conexão é iniciada, o servidor usa a chave pública para verificar a identidade do usuário, sem que a chave privada precise ser transmitida pela rede, garantindo assim a segurança.

No contexto do Git, a autenticação via chave SSH é especialmente útil ao interagir com repositórios remotos hospedados em plataformas como GitHub, GitLab e Bitbucket. Essas plataformas suportam autenticação por chave SSH, permitindo que os desenvolvedores enviem (push) e busquem (pull) alterações de forma segura.

CLique aqui para ver o manual de como configurar a chave SSH para a sua máquina

Workflow e primeiro repositório

Um pouco mais sobre Git

O Git é um sistema de controle de versão distribuído que gerencia informações armazenando cada versão do projeto como um snapshot completo, em vez de apenas as diferenças entre versões. Ele utiliza uma estrutura de objetos que inclui blobs (conteúdo de arquivos), trees (diretórios), commits (mudanças com metadados) e tags (marcadores de versão).

Cada objeto é identificado por um hash SHA-1, garantindo a integridade dos dados. Git permite a criação de branches para desenvolvimento paralelo e merges para combinar mudanças.

As modificações são preparadas na staging area antes de serem commitadas.

Com funcionalidades robustas de colaboração e resolução de conflitos, o Git suporta operações offline e sincronização com repositórios remotos através de comandos como push e pull, facilitando o trabalho simultâneo de múltiplos desenvolvedores.

Workflow básico

1) Você modifica arquivos na sua árvore de trabalho

2) Você seleciona apenas as mudanças que você quer que façam parte do seu próximo commit, e apenas essas mudanças serão adicionadas à staging area

3) Você faz um commit: os arquivos como eles estão na staging area são armazenados em forma de snapshot permanentemente no seu diretório Git.

Assim, podemos perceber que um arquivo pode estar em um dos 3 estados:

modified - quando o arquivo foi modificado e não está rastreado pelo Git.

staged - quando a modificação foi colocada na ‘staging area’ - uma área na qual armazenamos as mudanças antes de tê-las como definitiva para a próxima versão, ou seja, para o próximo commit.

commited - Mudanças que são definitivas, ou seja, a snapshot permanente foi guardada na linha do tempo do Git.

Comandos e Práticas do Git

Inicializando o git no repositório: “git init”

Para criar um repositório local, vamos ir ao diretório onde queremos criar o resositório Git e, em seguida, vamos inicializar o Git com o comando git init 

cd OneDrive/Documentos/projeto
git init

Agora, temos um subdiretório chamado .git que contém todos os arquivos necessários de seu repositório – um esqueleto de repositório Git.

Nada em seu projeto é monitorado ainda.

cd OneDrive/Documentos/projeto
git init
Initialized empty Git repository in /home/anna/OneDrive/Documentos/projeto/.git/

Gravando alterações em seu repositório

Cada arquivo em seu repsitório pode estar em um dos seguintes estados: rastreado e não-rastreado. Arquivos rastreados são arquivos que foram incluídos no último snapshot; eles podem ser não modificados, modificados ou preparados (adicionados ao stage). Em resumo, arquivos rastreados são os arquivos que o Git conhece.

Quando você clona um repositório pela primeira vez, todos os seus arquivos serão rastreados e não modificados, já que o Git acabou de obtê-los e você ainda não editou nada.

Assim que você edita alguns arquivos, Git os considera modificados, porque você os editou desde o seu último commit. Você prepara os arquivos editados e então faz commit das suas alterações, e o ciclo se repete.

Verificando o status dos arquivos: “git status”

A principal ferramenta que você vai usar para determinar quais arquivos estão em qual estado é o comando git status.

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

Digamos que você adicionou um simples arquivo chamado ‘chat’ ao seu projeto. Se o arquivo não existia antes, e você executar git status, você verá seu arquivo não rastreado da seguinte forma:

$ echo 'código do chat' > chat
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)

    chat

nothing added to commit but untracked files present (use "git add" to track)

Nós queremos incluir esse arquivo ‘chat’, então vamos rastreá-lo.

Rastreando arquivos novos

Para começar a rastrear um novo arquivo, você deve usar o comando git add

git add chat

Executando o comando status novamente, você pode ver que seu README agora está sendo rastreado e preparado (staged) para o commit:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)

    new file:   chat

É possível saber que o arquivo está preparado porque ele aparece sob o título “Changes to be committed”. Se você fizer um commit neste momento, a versão do arquivo que existia no instante em que você executou git add, é a que será armazenada no histórico de snapshots.

Preparando Arquivos Modificados (Adicionando arquivos modificados à staging area)

Vamos modificar um arquivo que já está sendo rastreado.

Se, por exemplo, adicionarmos mais uma linha de código ao arquivo ‘feed’ que já era rastreado e estava dentro do projeto, e executarmos o git status, teremos isso:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   chat

Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   feed

Isso significa que o arquivo rastreado foi modificado no diretório mas ainda não foi mandado para o stage (preparado).

Para isso, vamos usar o git add.

Pode ser útil pensar nesse comando mais como “adicione este conteúdo ao próximo commit”.

$ git add .
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)

    new file:   chat
    modified:   feed

Fazendo o commit do que foi feito: “git commit”

Agora que a área de stage está preparada, podemos fazer commit nas alterações.

O jeito mais simples de fazer commit é digitar o seguinte comando:

git commit

e adicionar uma mensagem no editor de texto.

Alternativamente, podemos fazer:

git commit -m "mensagem"

Lembre-se que o commit grava a snapshot que você deixou na área de stage. Qualquer alteração que você não tiver mandado para o stage permanecerá como estava, em seu lugar; você pode executar outro commit para adicioná-la ao seu histórico. Sempre que você executa um commit, você está gravando uma snapshot do seu projeto que você pode usar posteriormente para fazer comparações, ou mesmo restaurá-lo.

Exercícios : 1-2

Configurando o Repositório Remoto: “git remote”

Depois de inicializar o repositório local, você pode querer vinculá-lo a um repositório remoto para facilitar a colaboração e o backup. Para isso, vamos usar o comando git remote

git remote add origin https://github.com/seu-usuario/seu-repositorio.git
Como verificar os repositórios remotos configurados?

Basta utilizar a opção -v

git remote -v

note o que seguinte aparecerá:

origin  git@github.com:SEU_USUARIO/SEU_REPOSITORIO.git (fetch)
origin  git@github.com:SEU_USUARIO/SEU_REPOSITORIO.git (push)

Isso indica que o repositório remoto chamado origin está configurado para buscar (fetch) e enviar (push) atualizações para a URL especificada, que é onde o seu repositório remoto está.

Como desconectar o repositório local do remoto?
git remote remove origin

Depois de executar esses comandos, o repositório local estará desconectado do repositório remoto.

Como renomear o repositório remoto

Use o comando ‘git remote rename’ para alterar o nome do repositório remoto. No exemplo abaixo, vamos renomear ‘origin’ para ‘novo-nome’.

git remote rename origin novo-nome

Note que:

$ git remote -v
novo-nome  git@github.com:SEU_USUARIO/SEU_REPOSITORIO.git (fetch)
novo-nome  git@github.com:SEU_USUARIO/SEU_REPOSITORIO.git (push)

Exercício : 3

Como ver todos os commit feitos com “git log”

É um comando feito para exibir os históricos de commits do projeto.

Aparece nome, hora, data e a mensagem relacionada a cada commit.

$ git log
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Jane <jane.doe@example.com>
Date:   Fri Jun 30 14:32:16 2024 +0000

    Adicionando modificação no feed 

commit 3ad45c37a9f1b251545b8b2f4a3db7b683ed8e53
Author: John Smith <john.smith@example.com>
Date:   Thu Jun 29 09:12:10 2024 +0000

    adicionando a funcionalidade chat
Uma flag eficiente

Utilizando o comando “git log –oneline”, podemos ver os commits de forma mais simplificada.

Ele irá mostrar o número hash ou sha que é o identificador (ID) do commit e em seguida a sua mensagem.

git log --oneline

$ git log --oneline
9fceb02 (HEAD -> main) Adicionando modificação no feed 
b75f610 adicionando a funcionalidade chat
c1b4d83 Commit inicial com arquivos de configuração do projeto

Clonando um repositório

Para começar a trabalhar com um repositório que já existe em um servidor remoto, você pode cloná-lo para o seu ambiente local usando o comando git clone. Este comando cria uma cópia completa do repositório, incluindo todo o histórico de commits e branches.

Para clonar um repositório que está por exemplo no GitHub, faça:

  1. No GitHub.com, navegue até a página principal do repositório e faça o seguinte:

    • Para clonar o repositório usando HTTPS, em “HTTPS”, clique no ícone de cópia
    • Para clonar o repositório usando uma chave SSH, clique em “SSH” e depois no ícone de cópia.
    • Para clonar um repositório usando a GitHub CLI, clique em “GitHub CLI” e depois no ícone de cópia.

  2. Abra o Terminal.

  3. Altere o diretório de trabalho atual para o local em que deseja ter o diretório clonado.

  4. Digite git clone e cole a URL já copiada.

  5. Pressione ENTER para criar seu clone local.

$ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY
> Cloning into `YOUR-REPOSITORY`...
> remote: Counting objects: 10, done.
> remote: Compressing objects: 100% (8/8), done.
> remote: Total 10 (delta 1), reused 10 (delta 1)
> Unpacking objects: 100% (10/10), done.

Subindo alterações para o repositório remoto: “git push”

Se você tem um commit pronto e quer adiciona-lo ao repositório remoto, podemos fazer:

git push

Fazendo o git push os seus commits irão subir para o seu repositório remoto que foi configurado inicialmente por padrão.

git push origin master

Vamos supor que o nome no repositório remoto seja main, mas sua cópia local é chamada de master. Para corrigir essa diferença, você pode referenciar diretamente a branch (que é o local onde estamos desenvolvendo e enviando as modificações para o Git) do repositório remoto usando o seguinte comando:

git push origin master:main

Dessa forma, você está enviando o conteúdo da sua cópia local chamada master para a cópia no repositório remoto que é chamada de main.

Trazendo alterações para o repositório local: “git pull”

Se foram feitas alterações no repositório remoto por outros desenvolvedores ou por você mesmo e você deseja trazê-las para o seu repositório local, basta digitar o comando git pull:

git pull

Por padrão, esse comando irá puxar as alterações do origin, que é o nome padrão do repositório remoto referenciado quando você conectou o repositório local com o remoto pela primeira vez. No caso de um clone, o origin é o repositório de onde você fez o git clone.

Para atualizar uma branch local com as alterações da branch remota sem usar diretamente git pull, você pode usar o comando git pull com a especificação direta da branch remota, o que é na prática uma forma direta de realizar a operação. Aqui está como fazer isso:

git pull origin nome-da-branch:nome-da-branch-local

Exercícios : 4- 5

Exercícios

Orientações sobre os exercícios

Envie os exercícios de cada dia separados para o email linuxgitpetcc@gmail.com com o assunto sempre sendo: Dia (dia de aula) - (Nome do aluno)

Exercícios Obrigatórios

Exercício 01 - Iniciando um novo repositório Git

Clique para voltar ao conteúdo

  1. Crie um novo diretório chamado projetos.

  2. Entre no diretório projetos e crie outro diretório chamado calculadora_pyton.

  3. Inicialize um repositório Git vazio no diretório calculadora_pyton.

  4. Faça o comando para visualizar a pasta oculta que foi criada.

Como resolução, descreva os passos que você fez em um arquivo de texto com o nome dia3exercicio1.txt para o email “linuxgitpetcc@gmail.com”. Lembre-se de adicionar seu nome ao arquivo!

Exercício 02 - Adicionando arquivos ao seu repositório Git

Clique para voltar ao conteúdo

  1. Crie um arquivo chamado ‘README.md’ dentro do diretório calculadora_pyton.

  2. Adicione o conteúdo “Este é um projeto de uma calculadora em Python que realiza operações básicas.” ao README.md.

  3. Adicione o arquivo README.md ao repositório Git.

5.Faça um commit no repositório Git com a mensagem “Adicionei o README.md”.

Exercício 03 - Configurando um repositório remoto e enviando os commits

Clique para voltar ao conteúdo

  1. No GitHub, crie um novo repositório chamado calculadora_pyton.

  2. No terminal, dentro do diretório calculadora_pyton, configure seu repositório Git local para apontar para este repositório remoto.

  3. Envie seus commits para o repositório remoto.

Para a avaliação, mande o link do repositório pelo email “linuxgitpetcc@gmail.com”.

Exercício 04 - Adicionando funções de soma e multiplicação à calculadora

Clique para voltar ao conteúdo

  1. Adicione um novo arquivo chamado calculadora.py com a função de soma:

Copie o seguinte código:

def soma(a, b):
    return a + b

  1. Adicione o arquivo ao repositório:

  2. Faça um commit com a mensagem “Adicionei a função de soma”.

  3. Adicione a função de multiplicação ao arquivo calculadora.py: Copie o código da mesma forma que está aqui abaixo (mesmo com o erro):

def multiplicacao(a, b):
    c+b=4
    return a * b

  1. Adicione e “comite” as mudanças com a seguinte mentagem: “Adicionei a função de multiplicação”

  2. Verifique o erro após o commit e corrija-o apagando o “c+b=4” no arquivo.

  3. Adicione a modificação ao repositório e faça o commit com a mensagem “Correção de bug na função de multiplicação”

  4. Use o comando que sobe as alterações locais para o repositório remoto para subir os seus commits.

Exercício 05 - Clonando um repositório

Clique para voltar ao conteúdo

  1. Criar e clonar o repositório:
    • O aluno responsável pelo primeiro repositório remoto deve criar um novo repositório no GitHub com o nome “projeto 02” e compartilhar o link com o colega de dupla.
    • O colega deve clonar esse repositório usando o comando git clone [link do repositório].
  2. Criar uma pasta no repositório:
    • Cada aluno deve criar uma pasta com seu número de matrícula e primeiro nome, seguindo o formato 201003948_luiz.
    • Adicione a pasta ao Git com git add [nome da pasta] e “comite” com a mensagem “Adicionei a pasta 201003948_luiz”.
  3. Desenvolver o projeto individualmente:
    • Dentro da pasta criada, cada aluno pode desenvolver o projeto que quiser, aplicando o que foi aprendido:
      • Criar uma história fictícia em um arquivo .txt com 3 capítulos, fazendo commits a cada capítulo, a cada erro ortográfico corrigido ou a cada modificação de personagem.
      • Fazer uma calculadora ou qualquer outro programa em qualquer linguagem de programação, fazendo commits a cada funcionalidade implementada.
      • Fazer um site pequeno e básico, fazendo commits a cada funcionalidade implementada.
  4. Sincronizar as alterações com o repositório remoto:
    • Traga para o repositório local as alterações que estão no remoto com git pull (para verificar se o colega já subiu algum arquivo).
    • Após isso, suba todos os commits para o repositório remoto com git push.
  5. Criar o segundo repositório:
    • O outro aluno da dupla deve criar um novo repositório no GitHub com o nome “projeto 03” e repetir os passos 1 a 4, criando sua própria pasta no novo repositório do colega.
  6. Envio dos links dos repositórios:
    • Ao final do exercício, cada aluno deve enviar por e-mail os links de ambos os repositórios (projeto 02 e projeto03) para a avaliação.

O que será avaliado aqui são os commits, e não se os códigos estão corretos. Cada aluno deve fazer, no mínimo, 3 commits em cada projeto

© PET-CC/UFRN 2024 Licenciado sob CC BY-NC-SA.