create-writerkit 1.0.0 → 1.1.0

package/livro-com-template/capitulos/cap03-branches.tex

@@ -0,0 +1,114 @@
+\chapter{Gerenciamento de Ramificações: Paralelismo e Isolamento}
+
+\section{Conceito de Branches: Universo Paralelo}
+Em um ambiente de desenvolvimento colaborativo ou em um projeto complexo, não se pode arriscar que uma nova funcionalidade (\textit{feature}) instável ou experimental comprometa o código principal que está em produção.
+
+As **Branches (Ramificações)** resolvem isso, permitindo que a equipe crie cópias isoladas da linha do tempo principal. Elas servem para:
+
+\begin{itemize}
+    \item \textbf{Isolamento:} Novas features ou correções de bugs são desenvolvidas em um ambiente seguro, sem afetar o código de produção (\texttt{main}).
+    \item \textbf{Paralelismo:} Múltiplos desenvolvedores podem trabalhar simultaneamente na mesma base de código sem interferir uns nos outros.
+\end{itemize}
+
+\subsection{O Apontador Vital: HEAD}
+Sempre que você troca de branch, o Git move um ponteiro interno chamado **HEAD**. O HEAD aponta para o último commit da branch que você está visualizando no momento. Quando você faz um novo commit, ele é adicionado imediatamente após o commit apontado pelo HEAD. Entender o HEAD é entender \textit{onde} você está trabalhando.
+
+\begin{figure}[H]
+\centering
+\begin{tikzpicture}[
+    commit/.style={circle, draw=black!60, fill=white, thick, minimum size=0.8cm},
+    pointer/.style={->, >=Stealth, thick}
+]
+    % Main branch
+    \node[commit] (c1) at (0,0) {A};
+    \node[commit] (c2) at (2,0) {B};
+    \node[commit] (c3) at (4,0) {C};
+    \draw[pointer] (c1) -- (c2);
+    \draw[pointer] (c2) -- (c3);
+    
+    % Branch Feature
+    \node[commit, fill=gitfeatcontainer] (f1) at (5.5, 1.5) {D};
+    \node[commit, fill=gitfeatcontainer] (f2) at (7.5, 1.5) {E};
+    \draw[pointer] (c3) -- (f1); % Branch sai de C3
+    \draw[pointer] (f1) -- (f2);
+    
+    % Labels
+    \node[right=0.2cm of c3, text=primary] {\textbf{main}};
+    \node[right=0.2cm of f2, text=gitfeat] {\textbf{feature-X}};
+
+    % HEAD Pointer
+    \draw[<-, very thick, color=error] (f2.north) -- ++(0, 1) node[above, text=error] {\textbf{HEAD}};
+
+\end{tikzpicture}
+\caption{O ponteiro HEAD indica a branch ativa. Novos commits (F) ocorreriam após E.}
+\label{fig:git-head}
+\end{figure}
+
+\section{Estratégias de Fusão: A Arte do Merge}
+Após concluir o trabalho na branch isolada, ela deve ser integrada de volta à branch base (ex: \texttt{main} ou \texttt{develop}). Existem dois mecanismos principais:
+
+\begin{enumerate}
+    \item \textbf{Fast-Forward Merge (Avanço Rápido):} Ocorre quando a branch principal não teve commits novos desde que a branch de feature foi criada. O Git simplesmente move o ponteiro HEAD da branch principal para o último commit da feature. **Não cria um commit de merge.**
+    \item \textbf{3-Way Merge (Três Vias):} Ocorre quando a branch principal *também* teve commits novos. O Git precisa de um ponto de origem comum e cria um novo commit (\textbf{Merge Commit}) que une as duas linhas de história, preservando o histórico de ambas as ramificações.
+\end{enumerate}
+
+\begin{figure}[H]
+\centering
+\begin{tikzpicture}[
+    node distance=1.5cm,
+    commit/.style={circle, draw=black!60, fill=white, thick, minimum size=0.5cm, inner sep=0pt},
+    connection/.style={->, >=Stealth, thick, draw=black!70},
+    merge_commit/.style={commit, fill=primary}
+]
+
+    % --- 1. Fast-Forward Merge (Corrigido o posicionamento do título) ---
+    \node[font=\bfseries\small, anchor=west] at (-1.5, 3.7) {A) Fast-Forward (História Linear)}; % Ajuste de posição
+    
+    \node[commit, fill=primary] (ff1) at (0, 1.5) {A}; % Ponto de partida (subiu 0.5cm)
+    \node[commit, fill=gitfeat] (ff2) at (1.5, 1.5) {B};
+    \node[commit, fill=gitfeat] (ff3) at (3.0, 1.5) {C}; % Head da feature/Novo Main
+    \draw[connection] (ff1) -- (ff2);
+    \draw[connection] (ff2) -- (ff3);
+    
+    % Main pointer ANTES do merge (em A)
+    \draw[<-, very thick, color=primary] (ff1.north) -- ++(0, 0.7) node[above, font=\small, text=primary] {\textbf{Main} (Antes)};
+    
+    % Main pointer DEPOIS do merge (em C)
+    \draw[->, very thick, color=primary] (ff3.north) -- ++(0, 0.7) node[above, font=\small, text=primary] {\textbf{Main} (Depois)};
+    
+    \node[font=\tiny, text=black, text width=8cm, align=center] at (2.5, 0.7) {Resultado: Ponteiro "main" avança para C. NENHUM merge commit é criado.}; % Ajuste de posição e largura
+
+    % --- 2. 3-Way Merge (Merge Commit - Posição ajustada para ficar mais abaixo) ---
+    \node[font=\bfseries\small, anchor=west] at (-1.5, 0) {B) 3-Way Merge (Cria Merge Commit)}; % Ajuste de posição
+
+    \node[commit, fill=primary] (m1) at (0, -2.0) {X}; % Ponto Comum (Ancestor) (subiu 1cm)
+    \node[commit, fill=primary] (m2) at (1.5, -2.0) {Y}; % Linha Main (Commit novo)
+    
+    \node[commit, fill=gitfeat] (m3) at (1.5, -0.8) {Z}; % Linha Feature (Commit novo) (subiu 1cm)
+
+    \node[merge_commit] (m4) at (3.0, -1.25) {M}; % Novo Commit de Merge (subiu 1cm)
+
+    \draw[connection] (m1) -- (m2); % Main continua
+    \draw[connection] (m1) -- (m3); % Feature diverge
+    
+    \draw[connection] (m2) -- (m4); % Main converge no Merge Commit
+    \draw[connection] (m3) -- (m4); % Feature converge no Merge Commit
+
+    \draw[->, very thick, color=primary] (m4.east) -- ++(1, 0) node[right, font=\small, text=primary] {\textbf{Main} (Depois)};
+    
+    \node[font=\tiny, text=black, text width=8cm, align=center] at (2.5, -2.8) {Resultado: Novo Commit (M) criado. Histórico ramificado mantido.}; % Ajuste de posição e largura
+
+\end{tikzpicture}
+\caption{Representação das duas principais estratégias de fusão (Merge).}
+\label{fig:merge-strategies}
+\end{figure}
+\section{Realizando a Fusão (Merge)}
+Você sempre mescla \textbf{para} a branch onde o código final deve ir.
+
+\begin{lstlisting}[caption=Comandos para realizar o Merge]
+# 1. Mover para a branch de destino (ex: main)
+git switch main
+
+# 2. Executar o merge da feature na main
+git merge feature-login
+\end{lstlisting}

package/livro-com-template/capitulos/cap04-remoto.tex

@@ -0,0 +1,113 @@
+\chapter{Sincronização com Repositório Remoto (Remote)}
+\label{chap:remote-sync}
+
+\section{A Ponte para a Colaboração: Repositórios Remotos}
+Prezado aluno, até agora, todo o seu trabalho foi isolado no seu ambiente local, dentro da pasta `.git`. No entanto, o verdadeiro poder do Git é o seu caráter \textbf{distribuído}. Para colaborar com sua equipe e fazer o backup seguro de seu código, você precisa de um Repositório Remoto.
+
+\subsection{Definindo o Servidor Principal (\texttt{origin})}
+O Git permite que você tenha múltiplos remotos (servidores), mas por convenção, o principal, onde você baixa e envia o código, é chamado de **`origin`**.
+
+O primeiro passo é "ensinar" ao seu repositório local onde o servidor principal está localizado (ex: no GitHub). Isso é feito uma única vez.
+
+\begin{lstlisting}[caption=Adicionando o Repositório Remoto Principal]
+# Comando: git remote add <nome-do-servidor> <URL>
+git remote add origin https://github.com/usuario/repo.git
+\end{lstlisting}
+
+\begin{quote}
+    \textbf{Conceito Vital:} O comando \texttt{remote add origin} apenas cria um **apelido** (o nome \texttt{origin}) para a URL longa do seu projeto. Se você tivesse um servidor de backup, ele poderia se chamar \texttt{backup-server}.
+\end{quote}
+
+\section{Enviando Mudanças Locais: A Ação \texttt{push}}
+A ação de **`push`** (empurrar) é o processo de enviar todos os commits que estão na sua linha do tempo local (por exemplo, na branch \texttt{main}) para o Repositório Remoto (`origin`).
+
+\subsection{O Comando \texttt{git push} e o Rastreamento (-u)}
+O comando \texttt{push} necessita de três informações:
+1.  \textbf{O Destino Remoto:} Qual servidor? (Ex: `origin`)
+2.  \textbf{A Branch Local:} Qual branch estou enviando? (Ex: `main`)
+3.  \textbf{A Branch Remota:} Onde o Git deve salvar isso no servidor? (Ex: `main`)
+
+A primeira vez que você envia uma branch, você deve usar o parâmetro **`-u`** (ou `--set-upstream`).
+
+\begin{lstlisting}[caption=Enviando e Configurando o Rastreamento]
+# Envia a branch 'main' para 'origin' e configura
+# o rastreamento (upstream). Comando executado apenas na primeira vez.
+git push -u origin main
+\end{lstlisting}
+
+\begin{quote}
+    \textbf{Significado do -u:} O parâmetro `-u` diz ao Git local: "A partir de agora, se eu digitar apenas \texttt{git push} (sem argumentos), entenda que quero enviar minha branch local para a branch \texttt{main} no servidor \texttt{origin}". Ele estabelece a relação de rastreamento (\textit{tracking}).
+\end{quote}
+
+\section{Recebendo Mudanças Remotas: A Ação \texttt{pull}}
+A ação de **`pull`** (puxar) é o processo inverso. Ela é essencial para manter a sincronia, pois outros desenvolvedores podem ter enviado commits para o servidor (`origin`) enquanto você trabalhava.
+
+O comando \texttt{git pull} é, na verdade, uma combinação de dois comandos em sequência:
+
+\begin{enumerate}
+    \item \textbf{\texttt{git fetch}:} Baixa todos os dados e commits novos do remoto para uma área temporária local, mas \textbf{não altera} seu código de trabalho.
+    \item \textbf{\texttt{git merge}:} Mescla esses novos commits que foram baixados (do remoto) com o seu código local ativo.
+\end{enumerate}
+
+\begin{lstlisting}[caption=Atualizando o Repositório Local]
+# Baixa e mescla as alteracoes remotas automaticamente
+git pull origin main
+
+# Depois de usar -u, o comando se torna mais simples:
+git pull
+\end{lstlisting}
+
+\section{Revisão do Ciclo de Sincronização}
+Para o seu dia-a-dia, grave este fluxo:
+
+1.  \textbf{Comece o dia (Sincronize):} Use \texttt{git pull} para garantir que você esteja na versão mais recente do código remoto.
+2.  \textbf{Trabalhe:} Faça alterações, teste.
+3.  \textbf{Prepare o Histórico (Local):} Use \texttt{git add} e \texttt{git commit}. Repita o quanto for necessário (Commits Atômicos).
+4.  \textbf{Envie (Colabore):} Use \texttt{git push} para compartilhar seu histórico local com o repositório remoto.
+
+\begin{figure}[H]
+\centering
+\begin{tikzpicture}[
+    node distance=2.5cm,
+    block/.style={rectangle, draw=black!70, rounded corners, minimum height=1.5cm, minimum width=3.5cm, align=center, fill=white, thick},
+    server/.style={block, draw=gitmain, fill=primarycontainer, text=ongitmaincontainer, very thick, minimum width=4cm, minimum height=3.5cm},
+    local/.style={block, draw=gitdev, fill=secondarycontainer, text=onsecondarycontainer, very thick, minimum width=4cm, minimum height=3.5cm},
+    action/.style={rectangle, rounded corners=5pt, fill=mdneutralvariant95, draw=outline, align=center, inner sep=5pt, font=\ttfamily\small},
+    arrow/.style={->, >=Stealth, very thick, shorten >=2pt, shorten <=2pt},
+    dataflow/.style={->, >=Stealth, thick, dashed, color=outline}
+]
+
+    % --- Nodes de Repositório ---
+    \node[server] (remote) at (8, 0) {\textbf{REPOSITÓRIO REMOTO} \\ (Origin / GitHub) \\ \small \textcolor{black}{(Versão Definitiva)}};
+    
+    \node[local] (local) at (-2, 0) {\textbf{REPOSITÓRIO LOCAL} \\ (Sua Máquina) \\ \small \textcolor{black}{(Working Dir + Commit Locais)}};
+
+    % --- Ação 1: ENVIANDO MUDANÇAS (PUSH) ---
+    \node[action, fill=gitfeatcontainer, text=ongitfeatcontainer] (push) at (3, 2) {git push};
+    \draw[arrow, color=gitfeat] (local.north east) -- (push);
+    \draw[arrow, color=gitfeat] (push) -- (remote.north west);
+    \node[align=center, font=\small, text=gitfeat] at (3, 3) {\textbf{Enviar commits locais} \\(Atualiza o remoto)};
+
+    % --- Ação 2: RECEBENDO MUDANÇAS (PULL) ---
+    \node[action, fill=errorlight, text=errordark] (pull) at (3, -2) {git pull};
+    \node[align=center, font=\small, text=error] at (3, -3) {\textbf{Receber commits remotos} \\(Atualiza o local)};
+
+    % Detalhamento do PULL
+    \node[action, fill=mdneutralvariant90] (fetch) at (8, -5.0) {git fetch (1. Baixar dados)};
+    \node[action, fill=mdneutralvariant90] (merge) at (-2, -5.0) {git merge (2. Aplicar no local)};
+    
+    \draw[arrow, color=error] (remote.south west) -- (pull);
+    \draw[arrow, color=error] (pull) -- (local.south east);
+
+    % Linha de detalhe FETCH -> MERGE
+    \draw[dataflow, color=error] (remote.south) -- (fetch);
+    \draw[dataflow, color=error] (fetch) -- (merge);
+    \draw[dataflow, color=error] (merge) -- (local.south);
+
+    % Legendas
+    \node[font=\bfseries\small, text=black] at (3, -6) {Comando \texttt{git pull} = \texttt{git fetch} + \texttt{git merge}};
+
+\end{tikzpicture}
+\caption{O Ciclo de Vida da Sincronização Remota. O \texttt{push} envia seus commits; o \texttt{pull} garante que você receba o trabalho da equipe.}
+\label{fig:sync-cycle}
+\end{figure}

package/livro-com-template/capitulos/cap05-conflitos.tex

@@ -0,0 +1,80 @@
+\chapter{Resolução de Conflitos: O Momento da Decisão}
+
+\section{O Fenômeno do Conflito: Não Entre em Pânico}
+Em algum momento da sua carreira, você tentará mesclar seu código e o terminal retornará uma mensagem de erro. Muitos iniciantes congelam neste momento. Não seja um deles.
+
+Um \textbf{Conflito de Merge} não é um erro do sistema; é uma solicitação de arbitragem. O Git é inteligente, mas não possui contexto semântico. Quando dois desenvolvedores alteram a \textit{mesma linha} do \textit{mesmo arquivo} de maneiras diferentes, o Git entra em "estado de prudência". Ele se recusa a adivinhar qual versão deve prevalecer e delega a decisão final a você, o humano.
+
+Visualize a mecânica do conflito abaixo:
+
+\begin{figure}[H]
+\centering
+\begin{tikzpicture}[
+    node distance=1.5cm,
+    % CORREÇÃO AQUI: Troquei 'padding' por 'inner sep'
+    state/.style={rectangle, draw=gray, rounded corners, inner sep=5pt, minimum height=1cm, align=center},
+    arrow/.style={->, >=Stealth, thick}
+]
+
+    % Nós
+    \node[state, fill=primarycontainer, text=onprimarycontainer] (branchA) {\textbf{Sua Branch}\\ Modificou Linha 10};
+    \node[state, fill=tertiarycontainer, text=ontertiarycontainer, right=3cm of branchA] (branchB) {\textbf{Branch Remota}\\ Modificou Linha 10};
+    
+    \node[circle, draw=error, fill=errorcontainer, text=onerrorcontainer, font=\bfseries, thick, inner sep=2pt, minimum size=1.5cm, below right=1cm and 0.5cm of branchA] (conflict) {CONFLITO};
+    
+    \node[state, fill=secondarycontainer, text=onsecondarycontainer, below=1.5cm of conflict] (resolution) {\textbf{Intervenção Manual}\\ (Decisão Humana)};
+    
+    \node[state, dashed, draw=outline, fill=mdneutral95, text=onsurface, below=1cm of resolution] (final) {\textbf{Merge Commit}\\ (Histórico Unificado)};
+
+    % Setas
+    \draw[arrow, color=outline] (branchA) -- (conflict);
+    \draw[arrow, color=outline] (branchB) -- (conflict);
+    \draw[arrow, color=error, dashed] (conflict) -- (resolution) node[midway, right, font=\tiny] {Git Pausa o Processo};
+    \draw[arrow, color=outline] (resolution) -- (final);
+
+\end{tikzpicture}
+\caption{O Git pausa a operação automática para evitar perda de dados e solicita intervenção.}
+\end{figure}
+
+\section{Anatomia de um Arquivo em Conflito}
+Quando o Git avisa \texttt{CONFLICT (content)}, ele modifica fisicamente o arquivo problemático, inserindo marcadores visuais. Sua tarefa é abrir o editor de código (VS Code, Vim, etc.) e localizar esses marcadores.
+
+Entenda a estrutura que você encontrará:
+
+\begin{lstlisting}[caption=Estrutura interna de um conflito, language=HTML, escapechar=|]
+<<<<<<< HEAD
+console.log("Sistema Iniciado - Versao Local"); |\label{line:head}|
+=======
+console.log("System Started - Versao do Servidor"); |\label{line:remote}|
+>>>>>>> feature/internacionalizacao
+\end{lstlisting}
+
+\begin{description}
+    \item[\texttt{<<<<<<< HEAD}] Indica o início do código que **você** tinha na sua máquina (sua versão atual).
+    \item[\texttt{=======}] É a "fronteira" ou divisor de águas. Tudo acima é seu; tudo abaixo veio de fora.
+    \item[\texttt{>>>>>>> nome-da-branch}] Indica o fim do código que veio da outra branch (a versão concorrente).
+\end{description}
+
+\section{Protocolo Cirúrgico de Resolução}
+A resolução de conflitos é um procedimento destrutivo e construtivo. Você deve destruir os marcadores e construir a versão final coerente.
+
+\begin{enumerate}
+    \item \textbf{Análise Semântica:} Leia as duas versões. Pergunte-se: "Devemos manter a minha versão? A versão do colega? Ou uma combinação das duas?"
+    \item \textbf{Limpeza (O Passo Crucial):} Você deve apagar \textbf{todas} as linhas contendo os símbolos \texttt{<<<<<<<}, \texttt{=======} e \texttt{>>>>>>>}. Se você deixar um desses símbolos, o código não compilará.
+    \item \textbf{Edição:} Reescreva o trecho de código para que ele represente a verdade final.
+    \item \textbf{Confirmação ao Git:} O Git não sabe que você terminou de editar o arquivo até que você o avise explicitamente.
+\end{enumerate}
+
+\begin{lstlisting}[caption=Finalizando o processo de arbitragem]
+# 1. Apos salvar o arquivo no editor, adicione-o ao Index
+git add app.js
+
+# 2. Gere o commit de resolucao (sem isso, o merge fica pendente)
+git commit -m "fix: resolve conflito de merge em app.js mantendo padrao ingles"
+
+# 3. (Se estiver fazendo pull) Continue o processo se necessario, mas geralmente o commit encerra.
+\end{lstlisting}
+
+\begin{quote}
+    \textbf{Nota do Mentor:} Conflitos frequentes no mesmo arquivo indicam falha de arquitetura (acoplamento alto) ou falha de comunicação na equipe. Se isso acontecer, pare de digitar e converse com seu time.
+\end{quote}

package/livro-com-template/capitulos/cap06-gitflow.tex

@@ -0,0 +1,104 @@
+\chapter{Estratégias Avançadas: O Modelo Gitflow}
+\label{chap:gitflow}
+
+\section{A Essência do Gitflow: Disciplina e Segurança}
+Meu aluno, chegamos a um ponto de virada na sua formação. Aprender a usar \texttt{git commit} é a parte fácil; aprender a \textbf{colaborar} de forma eficaz e segura é a verdadeira marca de um engenheiro de software.
+
+O \textit{Gitflow}, modelo de ramificação proposto originalmente por Vincent Driessen \cite{driessen2010}, não é apenas um conjunto de comandos; é uma \textbf{convenção estrita de disciplina} adotada por equipes maduras. Ele impõe ordem ao caos, garantindo que o código em produção seja sempre sagrado e estável, enquanto o caos criativo do desenvolvimento ocorre em um ambiente isolado.
+
+\subsection{O Risco da Indisciplina: Por Que Seguir o Fluxo é Mandatório}
+Você deve tratar o fluxo Gitflow como a lei do projeto. Se você falhar em segui-lo rigorosamente, os seguintes problemas \textbf{certamente} ocorrerão, comprometendo o trabalho de toda a equipe:
+
+\begin{enumerate}
+    \item \textbf{Perda de Código (Reversão Não Intencional):} Ao mesclar branches de forma incorreta ou direta na \texttt{main} sem passar pela \texttt{develop}, você corre o risco gravíssimo de sobrescrever funcionalidades completas que seus colegas acabaram de integrar. O Git tenta ajudar, mas erros de fluxo sobrescrevem histórico.
+    \item \textbf{Deploy de Código Instável:} Se uma funcionalidade nova é enviada direto para a \texttt{main} sem passar por *Staging* ou *Release*, você está enviando bugs diretamente para o cliente final.
+    \item \textbf{Histórico "Espaguete":} A ausência de um padrão resulta em um grafo de branches ilegível. Ninguém conseguirá rastrear onde um bug começou ou o que foi lançado na versão 1.2, tornando a manutenção um pesadelo caro e lento.
+\end{enumerate}
+
+\subsection{O Padrão de Nomenclatura: Taxonomia de Branches}
+No Gitflow, o nome da branch define seu propósito e seu ciclo de vida. **Não invente nomes criativos.** Siga o padrão:
+
+\begin{description}
+    \item[\texttt{main}] \textbf{Produção.} Contém apenas código testado, aprovado e atualmente em uso pelos usuários. Ninguém "commita" direto aqui. Recebe apenas Merges de Releases ou Hotfixes.
+    \item[\texttt{develop}] \textbf{Integração.} A "próxima versão" do software. Todas as funcionalidades novas convergem para cá.
+    \item[\texttt{feature/<nome>}] \textbf{Desenvolvimento.} Onde você trabalha (Ex: \texttt{feature/login-google}). Nascem da \texttt{develop} e morrem ao voltar para a \texttt{develop}.
+    \item[\texttt{hotfix/<versao>}] \textbf{Emergência.} Usada apenas para corrigir erros críticos em produção (Ex: \texttt{hotfix/corrigir-banco}). Nascem da \texttt{main} e, atenção: devem ser mescladas de volta na \texttt{main} E na \texttt{develop}.
+    \item[\texttt{release/<versao>}] \textbf{Lançamento.} Congelamento de código para testes finais antes de ir para a \texttt{main}.
+\end{description}
+
+\section{O Diagrama do Fluxo (Timeline)}
+Observe o diagrama abaixo com extrema atenção. Ele representa as "raias" (swimlanes) onde o código trafega. Note que a \texttt{feature} (em verde) nunca toca a \texttt{main} (em azul) diretamente. Ela precisa passar pelo filtro da \texttt{develop} (laranja).
+
+\begin{figure}[H]
+\centering
+\resizebox{\textwidth}{!}{
+\begin{tikzpicture}[
+    node distance=1.5cm,
+    commit/.style={circle, draw=black!60, thick, minimum size=0.5cm, inner sep=0pt, drop shadow},
+    connection/.style={->, >=Stealth, thick, rounded corners=5pt, draw=black!70},
+    lane_label/.style={font=\bfseries\small, anchor=east}
+]
+
+    % Grid e Raias (Swimlanes)
+    \draw[outline, fill=primarycontainer] (0,3.5) rectangle (12,4.5); % Main Lane
+    \draw[outline, fill=errorcontainer] (0,4.6) rectangle (12,5.4);   % Hotfix Lane
+    \draw[outline, fill=secondarycontainer] (0,2.0) rectangle (12,3.0);   % Develop Lane
+    \draw[outline, fill=gitfeatcontainer] (0,0.5) rectangle (12,1.5);  % Feature Lane
+
+    % Labels das Raias
+    \node[lane_label, text=error] at (-0.2, 5.0) {Hotfixes};
+    \node[lane_label, text=primary] at (-0.2, 4.0) {Main (Prod)};
+    \node[lane_label, text=secondary] at (-0.2, 2.5) {Develop};
+    \node[lane_label, text=gitfeat] at (-0.2, 1.0) {Features};
+
+    % --- Main Line (Produção) ---
+    \node[commit, fill=primary] (m1) at (0.5, 4.0) {};
+    \node[above=0.1cm of m1, font=\tiny] {v1.0};
+    
+    % --- Develop Line (Integração) ---
+    \node[commit, fill=secondary] (d1) at (1.5, 2.5) {};
+    \draw[connection] (m1) -- (d1); % Init develop from main
+
+    % --- Feature Start (Início do trabalho) ---
+    \node[commit, fill=gitfeat] (f1) at (2.5, 1.0) {};
+    \draw[connection] (d1) -- (f1); % Feature branch off develop
+    
+    \node[commit, fill=gitfeat] (f2) at (4.0, 1.0) {};
+    \draw[connection] (f1) -- (f2); % Commit na feature
+    
+    % --- Hotfix Emergency (Algo quebrou na prod!) ---
+    \node[commit, fill=error] (h1) at (3.0, 5.0) {};
+    \draw[connection] (m1) -- (h1); % Hotfix sai da main
+    
+    \node[commit, fill=error] (h2) at (4.5, 5.0) {};
+    \draw[connection] (h1) -- (h2); % Fix
+    
+    % --- Hotfix Merge (Volta pra Main e Develop) ---
+    \node[commit, fill=primary] (m2) at (5.5, 4.0) {};
+    \node[above=0.1cm of m2, font=\tiny] {v1.0.1};
+    \draw[connection] (h2) -- (m2); % Merge hotfix -> main
+    
+    \node[commit, fill=secondary] (d2) at (5.5, 2.5) {};
+    \draw[connection] (h2) -- (d2); % Merge hotfix -> develop (CRUCIAL)
+    \draw[connection] (d1) -- (d2); % Continuidade develop
+
+    % --- Feature Finish ---
+    \node[commit, fill=secondary] (d3) at (7.0, 2.5) {};
+    \draw[connection] (f2) -- (d3); % Merge feature -> develop
+    \draw[connection] (d2) -- (d3);
+
+    % --- Release Preparation ---
+    \node[commit, fill=secondary] (d4) at (8.5, 2.5) {};
+    \draw[connection] (d3) -- (d4);
+    
+    % --- Final Release to Main ---
+    \node[commit, fill=primary] (m3) at (10.0, 4.0) {};
+    \node[above=0.1cm of m3, font=\tiny] {v1.1};
+    \draw[connection] (d4) -- (m3); % Merge develop -> main (simplificado sem release branch pra caber)
+
+\end{tikzpicture}
+}
+\caption{Diagrama de fluxo Gitflow. Note como o Hotfix (vermelho) deve atualizar tanto a Main quanto a Develop para evitar regressão.}
+\label{fig:gitflow-diagram}
+\end{figure}
+

package/livro-com-template/capitulos/cap07-boas-praticas.tex

@@ -0,0 +1,49 @@
+\chapter{Boas Práticas e Automação}
+
+\section{Mensagens de Commit: A Arte da Comunicação}
+Um commit não é apenas um backup de código; é uma mensagem para o seu "eu do futuro" e para seus colegas de equipe. Mensagens genéricas como \texttt{"fix"} ou \texttt{"update"} tornam o histórico do projeto inútil para depuração e auditoria.
+
+\subsection{Padrão Conventional Commits}
+Uma das convenções mais adotadas na indústria é o \textit{Conventional Commits}. Ele utiliza um prefixo para descrever a intenção da mudança:
+
+\begin{itemize}
+    \item \textbf{feat:} Uma nova funcionalidade para o usuário.
+    \item \textbf{fix:} Uma correção de bug.
+    \item \textbf{docs:} Alterações apenas na documentação.
+    \item \textbf{style:} Alterações que não afetam o significado do código (espaço em branco, formatação, falta de ponto e vírgula, etc).
+    \item \textbf{refactor:} Uma alteração de código que não corrige um bug nem adiciona uma funcionalidade.
+    \item \textbf{chore:} Atualização de tarefas de build, pacotes, etc; sem alteração no código de produção.
+\end{itemize}
+
+\begin{lstlisting}[caption=Exemplo de Commit Convencional]
+# Formato: <tipo>(escopo opcional): <descrição>
+git commit -m "feat(auth): adiciona validacao de senha forte"
+\end{lstlisting}
+
+\section{Git Hooks: Automação no Lado do Cliente}
+Os \textbf{Git Hooks} são scripts que o Git executa automaticamente quando certos eventos importantes ocorrem (antes de um commit, antes de um push, etc). Eles são fundamentais para garantir a qualidade do código antes mesmo dele sair da sua máquina.
+
+\subsection{O Hook \texttt{pre-commit}}
+O hook mais comum é o \texttt{pre-commit}. Ele pode ser configurado para rodar testes unitários ou ferramentas de \textit{linting} (formatação). Se o script falhar, o Git aborta o commit, impedindo que código "quebrado" ou mal formatado entre no histórico.
+
+\begin{lstlisting}[caption=Exemplo de script pre-commit simples, language=bash]
+#!/bin/sh
+# Local: .git/hooks/pre-commit
+
+echo "Executando testes antes do commit..."
+npm test
+
+if [ $? -ne 0 ]; then
+    echo "Erro: Testes falharam. Commit abortado."
+    exit 1
+fi
+\end{lstlisting}
+
+\section{Resumo das Boas Práticas}
+Para um fluxo de trabalho profissional, siga sempre estas diretrizes:
+\begin{enumerate}
+    \item \textbf{Faça commits atômicos:} Uma mudança lógica por commit.
+    \item \textbf{Nunca suba código quebrado:} Use hooks para validar seu trabalho.
+    \item \textbf{Escreva mensagens claras:} O histórico deve ser legível como um livro.
+    \item \textbf{Sincronize com frequência:} Faça \texttt{pull} e \texttt{push} diariamente para evitar conflitos gigantescos.
+\end{enumerate}

package/livro-com-template/capitulos/cap08-sobrevivencia.tex

@@ -0,0 +1,124 @@
+\chapter{Guia de Sobrevivência: Resolvendo Problemas Reais}
+\label{cap:sobrevivencia}
+
+No dia a dia do desenvolvimento, é inevitável que algo saia do planejado. Um comando executado por pressa, um conflito inesperado ou a exclusão acidental de um arquivo podem gerar momentos de pânico. Este capítulo é o seu guia de "primeiros socorros", focado em como usar o Git para reverter erros e recuperar o controle do projeto.
+
+\section{Cenário 1: "Socorro, apaguei o arquivo!"}
+
+Você estava limpando o projeto e, por engano, apagou um arquivo importante que ainda não tinha sido commitado, mas que já fazia parte do repositório.
+
+\subsection{A Solução: Restauração Simples}
+Se o arquivo já existia no último commit, o Git pode recuperá-lo instantaneamente:
+
+\begin{lstlisting}[style=mystyle, caption=Recuperando um arquivo deletado]
+# Se voce usa Git 2.23+ (recomendado)
+git restore nome-do-arquivo.txt
+
+# Em versoes mais antigas
+git checkout -- nome-do-arquivo.txt
+\end{lstlisting}
+
+Isso traz a versão do arquivo exatamente como ela estava no último commit (\texttt{HEAD}).
+
+\section{Cenário 2: "Fiz o commit, mas esqueci um detalhe"}
+
+Você acabou de fazer um commit, mas percebeu que esqueceu de adicionar um arquivo ou que escreveu a mensagem com um erro de digitação.
+
+\subsection{A Solução: O Comando Amend}
+O comando \texttt{--amend} permite que você "edite" o último commit sem criar um novo na história.
+
+\begin{lstlisting}[style=mystyle, caption=Corrigindo o ultimo commit]
+# Adicione o arquivo esquecido
+git add arquivo-esquecido.txt
+
+# "Emende" o commit anterior
+git commit --amend -m "Sua nova mensagem corrigida"
+\end{lstlisting}
+
+\begin{importantbox}{Atenção com o Amend}
+Use o \texttt{--amend} apenas em commits que ainda estão apenas na sua máquina local. Se você já fez o \texttt{push} do commit para um servidor compartilhado, evite alterá-lo, pois isso reescreverá a história para todos os outros desenvolvedores.
+\end{importantbox}
+
+\section{Cenário 3: "O Merge deu errado e quebrou tudo"}
+
+Durante um merge, você percebeu que os conflitos são complexos demais ou que você começou o merge na branch errada.
+
+\subsection{A Solução: Abortar e Recomeçar}
+Se você ainda está no meio do processo de resolução de conflitos, pode simplesmente desistir:
+
+\begin{lstlisting}[style=mystyle, caption=Abortando um merge]
+git merge --abort
+\end{lstlisting}
+
+O Git retornará o estado do repositório para exatamente como estava antes de você digitar \texttt{git merge}. Se você já finalizou o merge e quer voltar atrás, use:
+
+\begin{lstlisting}[style=mystyle, caption=Desfazendo um merge ja finalizado]
+# Retorna para o commit anterior ao merge (perigo: apaga mudancas locais!)
+git reset --hard HEAD~1
+\end{lstlisting}
+
+\section{Cenário 4: "Perdi um commit! Ele sumiu!"}
+
+Você fez um \texttt{git reset --hard} ou deletou uma branch e agora percebeu que precisava daquele código. No Git, quase nada é deletado permanentemente de imediato.
+
+\subsection{A Solução: A Máquina do Tempo (Reflog)}
+O \texttt{reflog} é um diário de tudo o que o \texttt{HEAD} fez no seu computador local.
+
+\begin{lstlisting}[style=mystyle, caption=Usando o Reflog para encontrar commits perdidos]
+git reflog
+\end{lstlisting}
+
+Ele mostrará uma lista como esta:
+\begin{lstlisting}[style=mystyle]
+ab12cd3 HEAD@{0}: reset: moving to HEAD~1
+ef45gh6 HEAD@{1}: commit: Adiciona funcionalidade X
+...
+\end{lstlisting}
+
+Para recuperar o commit perdido, basta dar um reset para o ID encontrado:
+\begin{lstlisting}[style=mystyle]
+git reset --hard ef45gh6
+\end{lstlisting}
+
+\section{Cenário 5: "Preciso mudar de branch, mas não terminei aqui"}
+
+Você está no meio de uma tarefa complexa, os arquivos estão todos modificados e seu chefe pede para você corrigir um bug urgente em outra branch. Você não quer fazer um commit "sujo" com código incompleto.
+
+\subsection{A Solução: O Guarda-Volumes (Stash)}
+O \texttt{stash} guarda suas alterações em uma área temporária e limpa seu diretório de trabalho.
+
+\begin{lstlisting}[style=mystyle, caption=Uso basico do Stash]
+# Guarda as mudancas atuais
+git stash
+
+# ... va para a outra branch, corrija o bug, volte para a original ...
+
+# Recupera suas mudancas e limpa o guarda-volumes
+git stash pop
+\end{lstlisting}
+
+\begin{center}
+\begin{tikzpicture}[node distance=2cm]
+    \node (work) [draw, fill=primarycontainer, text=onprimarycontainer, rounded corners, minimum width=3cm] {Working Directory};
+    \node (stash) [draw, fill=secondarycontainer, text=onsecondarycontainer, rounded corners, minimum width=3cm, right of=work, xshift=3cm] {Stash (Guarda-Volumes)};
+    
+    \draw [->, thick, primary] (work.east) -- node[above, font=\small] {git stash} (stash.west);
+    \draw [->, thick, secondary] (stash.south) -- ++(0,-0.5) -- ++(-5,0) -- node[below, font=\small] {git stash pop} (work.south);
+\end{tikzpicture}
+\end{center}
+
+\section{Resumo do Guia}
+
+\begin{table}[h]
+\centering
+\begin{tabular}{|l|l|}
+\hline
+\rowcolor{primarycontainer} \textbf{Problema} & \textbf{Comando de Resgate} \\ \hline
+Apaguei arquivo local & \texttt{git restore <arquivo>} \\ \hline
+Erro no último commit & \texttt{git commit --amend} \\ \hline
+Merge problemático & \texttt{git merge --abort} \\ \hline
+Perdi um commit local & \texttt{git reflog} \\ \hline
+Trocar de branch rápido & \texttt{git stash} \\ \hline
+\end{tabular}
+\caption{Referência rápida de recuperação}
+\end{table}

package/livro-com-template/capitulos/glossario-tecnico.tex

@@ -0,0 +1,18 @@
+\chapter{Glossário Técnico}
+\begin{description}
+    \item[Repository (Repo):] O banco de dados do seu projeto, onde o Git armazena o histórico e os metadados.
+    \item[Working Directory:] A pasta local onde você edita os arquivos do projeto.
+    \item[Staging Area (Index):] Zona intermediária onde você prepara as alterações que serão incluídas no próximo commit.
+    \item[Commit:] Um "instantâneo" (snapshot) do estado dos arquivos em um determinado momento.
+    \item[Branch:] Uma linha do tempo independente para o desenvolvimento de funcionalidades ou correções.
+    \item[HEAD:] Um ponteiro que indica a branch atual e o commit em que você está trabalhando.
+    \item[Remote:] Versão do repositório hospedada em um servidor (ex: GitHub).
+    \item[Origin:] O nome padrão dado ao servidor remoto principal de onde o projeto foi clonado.
+    \item[Clone:] O ato de baixar um repositório completo do servidor para sua máquina local.
+    \item[Pull:] Operação de baixar as atualizações do servidor e mesclá-las no seu código local.
+    \item[Push:] Operação de enviar seus commits locais para o servidor remoto.
+    \item[Merge:] A unificação de duas histórias de desenvolvimento (branches).
+    \item[Pull Request (PR):] Um mecanismo do GitHub para solicitar que suas alterações sejam revisadas e integradas ao projeto principal.
+    \item[Fork:] Uma cópia pessoal de um repositório de outro usuário, permitindo modificações sem afetar o original.
+    \item[Rebase:] Reaplica commits sobre outra base, criando um histórico linear.
+\end{description}