Quinta-feira, dia 11 de Fevereiro, as 19h03min12s

Neste exato momento, Laura fez o commit e push da sua edição no arquivo de chamada. Ela, como foi instruída pelo professor, colocou seu nome na última colocação, e seu número era 14.

[20210212.002308, !1590]$ git show 941c4b2
commit 941c4b2f2af558188d0cd138e4c7af226ece40ef (refs/bisect/good-941c4b2f2af558188d0cd138e4c7af226ece40ef)
Author: Laura Kely Monteiro Da Silva <lauramonteiro>
Date:   Thu Feb 11 19:03:12 2021 -0300

logica: Laura Kely Monteiro Da Silva

diff --git a/logica/2020s1-01-logica.md b/logica/2020s1-01-logica.md
index 290bb24..8dab2f6 100644
--- a/logica/2020s1-01-logica.md
+++ b/logica/2020s1-01-logica.md
@@ -28,3 +28,4 @@
11 | Eduardo Cavalcanti Ferreira                                | @eduardocavalcantiferreira|
12 | Gabriel Antonio Caetano Farias                             | @gabrielfariaseng         |
13 | Marcos Andre Estrela Santos Junior                         | @estrelanony              |
+14 | Laura Kely Monteiro Da Silva                               | @LauraM358                |

Quinta-feira, dia 11 de Fevereiro, às 19h03min19s

Com apenas 7 segundos de diferença, Andressa não tinha em seu repositório as atualizações feitas por Laura. Para Andressa, o arquivo terminava em Marcos, número 13, e ela era a detentora do número 14 por direito. Ela fez sua edição, salvou o arquivo, fez o commit, e até aí tudo bem. Mas ela está prestes a ter uma surpresa durante o push.

 

$ git show 4b35269
commit 4b3526933b50a02242f750237a0247193515056e (refs/bisect/good-4b3526933b50a02242f750237a0247193515056e)
Author: Andressa Freitas De Arruda <andressa>
Date:   Thu Feb 11 19:03:19 2021 -0300

    logica: Andressa Freitas De Arruda

diff --git a/logica/2020s1-01-logica.md b/logica/2020s1-01-logica.md
index 290bb24..706e9de 100644
--- a/logica/2020s1-01-logica.md
+++ b/logica/2020s1-01-logica.md
@@ -28,3 +28,4 @@
 11 | Eduardo Cavalcanti Ferreira                                | @eduardocavalcantiferreira|
 12 | Gabriel Antonio Caetano Farias                             | @gabrielfariaseng         |
 13 | Marcos Andre Estrela Santos Junior                         | @estrelanony              |
+14 | Andressa Freitas De Arruda                                 | @andressa741              |

 

 

Quando tentou fazer o push, Andressa notou um conflito. Uma mensagem de erro voltou indicando a ela que era preciso resolvê-lo. Ao abrir novamente o arquivo de chamada, eis o que nele se encontrava:

 

$ cat logica/2020s1-01-logica.md 
# Lista de Chamada

* Disciplina: Logica Matematica
* Turma: LT
* Periodo: 2020s1
* Horario:
    - Qua, 13h50 - 15h30
    - Qui, 15h30 - 17h10
* Prof. Dr. Ruben Carlo Benante

# Semana: 01 


## Alunos presentes

 N | Nome Completo                                              | Usuario Github            |
---|------------------------------------------------------------|---------------------------|
01 | Arlon Nata Alves Granja Delmondes                          | @arlonnata1               |
02 | Iuri Nazareno De Franca Rossi                              | @iurirossi                |
03 | Joao Pedro Henderson Sarruf                                | @joaosarruf               |
04 | Breno Augusto De Brito Rangel                              | @brenorangel20            | 
05 | Jose Lucas Bessa De Oliveira                               | @JoseLucasBessa           |
06 | Gabriel De Mendonca Ramalho                                | @Gabs2002                 |
07 | Marcus Vinicius Barbosa Vilela Curvelo                     | @marc3105                 |
08 | Andre Wanderley De Melo                                    | @andr3m3l0                |
09 | Alex Bruno Seabra                                          | @aalexbrunno              |
10 | Eduardo Felipe Da Silva Braga                              | @eduubr                   |
11 | Eduardo Cavalcanti Ferreira                                | @eduardocavalcantiferreira|
12 | Gabriel Antonio Caetano Farias                             | @gabrielfariaseng         |
13 | Marcos Andre Estrela Santos Junior                         | @estrelanony              |
<<<<<<< HEAD
14 | Laura Kely Monteiro Da Silva                               | @LauraM358                |
=======
14 | Andressa Freitas De Arruda                                 | @andressa741              |
>>>>>>> 4b3526933b50a02242f750237a0247193515056e

 

Resolvendo o conflito

Não tinha como não ficar estupefada pela descoberta de que haviam dois números 14! Ora como? Simples: ao fazer o push, o comando git tenta enviar os arquivos locais para o repositório remoto, e lá encontra a atualização feita pelo push imediatamente anterior, o push de Laura.

Normalmente o conflito se resolve sozinho, pois o comando git é capaz de interpolar linhas diferentes editadas por pessoas diferentes. Mas aqui seria necessário intervenção humana, pois a mesma linha indicava dois nomes, e o comando git não tem como saber qual seria a certa.

A marcação <<<<<<< HEAD marca o início do arquivo remoto (arquivo de Laura). A marcação ======= marca a separação entre o arquivo remoto (de Laura) e o arquivo local (de Andressa). E finalmente, a marcação >>>>>> HASH marca o final do conflito.

Andressa então tem que ajustar esse arquivo. Ela deve deixar o número 14 para Laura, que uma hora dessas já até desligou o seu computador totalmente alheia ao fato (pois para Laura, o push foi sem conflito). Andressa então deve recolocar seu nome com o número 15, e, muito importante, deve apagar as marcas <<<<<, ===== e >>>>> do conflito. O arquivo final da Andressa ficará assim:

 

$ cat logica/2020s1-01-logica.md 
# Lista de Chamada

* Disciplina: Logica Matematica
* Turma: LT
* Periodo: 2020s1
* Horario:
    - Qua, 13h50 - 15h30
    - Qui, 15h30 - 17h10
* Prof. Dr. Ruben Carlo Benante

# Semana: 01 


## Alunos presentes

 N | Nome Completo                                              | Usuario Github            |
---|------------------------------------------------------------|---------------------------|
01 | Arlon Nata Alves Granja Delmondes                          | @arlonnata1               |
02 | Iuri Nazareno De Franca Rossi                              | @iurirossi                |
03 | Joao Pedro Henderson Sarruf                                | @joaosarruf               |
04 | Breno Augusto De Brito Rangel                              | @brenorangel20            | 
05 | Jose Lucas Bessa De Oliveira                               | @JoseLucasBessa           |
06 | Gabriel De Mendonca Ramalho                                | @Gabs2002                 |
07 | Marcus Vinicius Barbosa Vilela Curvelo                     | @marc3105                 |
08 | Andre Wanderley De Melo                                    | @andr3m3l0                |
09 | Alex Bruno Seabra                                          | @aalexbrunno              |
10 | Eduardo Felipe Da Silva Braga                              | @eduubr                   |
11 | Eduardo Cavalcanti Ferreira                                | @eduardocavalcantiferreira|
12 | Gabriel Antonio Caetano Farias                             | @gabrielfariaseng         |
13 | Marcos Andre Estrela Santos Junior                         | @estrelanony              |
14 | Laura Kely Monteiro Da Silva                               | @LauraM358                |
15 | Andressa Freitas De Arruda                                 | @andressa741              |

 

E viveram felizes para sempre.

Arquivo de Log

Além dos comandos acima, é interessante conhecer o comando “git lo”, que mostra o log dos últimos commits.

No caso acima, podemos ver

* 50017ec DrBeco 2021-02-12 correcao de conflito em logica  (HEAD -> master, origin/master, origin/HEAD)
*  0dc7ca2 Laura 2021-02-11 logica: Laura Kely Monteiro Da silva
|\ 
| * 4b35269 14.Andressa 2021-02-11 logica: Andressa Freitas De Arruda 
* | 941c4b2 14.Laura 2021-02-11 logica: Laura Kely Monteiro Da Silva  
|/  
* f46cda4 13.Marcos 2021-02-11  logica: Marcos Andre Estrela Santos Junior 

 

Perceba que no commit 941c4b2, Laura já adicionou seu número 14, que veio do arquivo de Marcos, número 13. Note uma bifurcação nos caminhos (as barras verticais), e o commit 4b35269 tem o mesmo “pai” do commit de Laura, que é Marcos.

Depois de ambas realizarem o seu commit e push, a linha volta a ficar única no commit 0dc7ca2. Porém, como não resolveram o conflito, o arquivo ficou incorreto, mostrando as marcas de conflito (<<<<<, =====, >>>>>) e dois nomes com número 14.

Então, no commit 50017ec, o professor interveio e resolveu desta vez, para poder ensinar e escrever este post.

Cuidado: se o professor tiver que resolver novamente, a pessoa que entrar errado com número duplicado e não resolver o conflito, será eliminada e ficará com falta. Então, após o push, sempre olhe se o arquivo ficou correto.

Na dúvida, se deu erro para você, lembre-se: você é o número seguinte. Pois para a primeira pessoa, você ainda não tinha entrado, e o conflito só aparece para a segunda pessoa.

Bom estudo!

Série: Contribuindo

Faça uma boa mensagem de commit

  • Se é um pequeno commit tudo bem abreviar a mensagem com apenas um título com o comando git commit -am "uma descricao do que este commit faz em ate 50 caracteres"
  • Mas se é um commit que vai influenciar muito o código de outros ramos ou que vai ser usado para pull request então é importante escrever uma boa mensagem. Neste caso, não use o comando abreviado. Use os comandos:
    • git add arquivo : se necessário adicionar algum arquivo
    • git commit : sem abreviação e sem mensagem. Este comando vai abrir o vi (ou seu editor preferido) para você digitar uma mensagem de commit maior.
      • Na primeira linha, escreva um título do commit com até 50 caracteres, como você já está acostumado.
      • Pule uma linha.
      • Da terceira linha para baixo, descreva com mais detalhes tudo o que você fez, o que este commit inclui, o que muda, qual funcionalidade é acrescentada ou bug é resolvido.
      • Saia com :x (no vi) para salvar e fazer o commit
      • Saia com :q! (no vi) para abortar a edição e não fazer o commit
      • Linhas iniciadas com # são ignoradas pelo git como sendo comentários e não são escritas no commit.
  • Exemplo de uma boa mensagem de commit:
Faz um exemplo para demonstrar a clareza do commit

Sem este commit a explicação sobre mensagens de commit ficaria 
falha, sem um exemplo concreto. Este é um problema, porque assim 
fica apenas na imaginação o que seria um bom commit.Este commit 
corrige este problema ao fazer aqui um exemplo concreto e imperativo.

A primeira linha é um título imperativo descritivo do essencial. 
Os dois parágrafos seguintes, o de cima e este, são explicações mais 
aprofundadas. É importante descrever:

(1) _o que ocorria_ antes do commit, 
(2) _qual_ é o problema que este commit resolve, 
(3) _porque_ este comportamento é problemático, e 
(4) _como_ este commit corrige este problema.

Também é possível usar enumerações para clarificar algumas mudanças 
em pontos específicos, como:

* mudafunc() : agora não retorna mais void e sim o código do cliente
* funcoutra() : criada para cumprir outra finalidade que faltava
* divideaqui() : criada para cumprir uma finalidade tal e tal que 
antes estava sendo feita na função mudafunc() de modo a ficar mais 
clara a divisão do que cada função faz.

Lembre que a primeira linha é importante para ver o log e acompanhar a evolução do programa.

Série: Contribuindo

Importância, peculiaridades e diferenças

Sua contribuição aos códigos disponíveis no github é essencial para tornar estes programas cada vez melhores. Além disso, é difícil para apenas um desenvolvedor testar a imensa quantidade de plataformas e a miríade de configurações existentes. Este guia está aqui para tornar mais simples sua contribuição e aumentar as chances dela ser aceita. Há apenas algumas regras que precisamos para que consigamos manter a organização e o controle do código, então basta seguir este pequeno guia de ‘Como contribuir’.

Cada código, claro, terá suas peculiaridades. Confira no repositório escolhido para entender os detalhes e para você se adaptar ao padrão estabelecido. Deste modo, este texto é mais um guia para que você possa adaptá-lo e inserir no seu próprio repositório.

O local ideal para colocar este texto é numa pasta escondida chamada .github, com nome de arquivo CONTRIBUTING.md. Desta forma, este texto terá um link automático na página de criação de novos issues como por exemplo em:

Please review the guidelines for contributing to this repository.

Iniciando

Tenha certeza de que sua conta está devidamente configurada. Cheque os seguintes itens:

  • Cadastre-se no GitHub 🙂
  • Nas configurações do git em sua máquina local confira se seu nome e email são os mesmos que cadastrou no GitHub.
  • Siga o código de conduta do bom programador BecoSystems
  • Faça um fork, implemente e teste o programa.
  • Para um pull request (PR) ser aceito é essencial que as alterações sejam em doses bem pequenas (homeopáticas), mudando apenas um bloco lógico consistente em cada requisição.
  • Organize a seu PR em ramos. Se preferir fazer pequenas alterações, crie novos ramos a partir do master.
  • Faça testes à vontade no ramo develop ou outro qualquer. Mas se possível tente manter o ramo master fiel ao upstream, e evite conflitos no PR fazendo antes um git pull e merge das últimas modificações.

Arquivos no repositório

  • AUTHORS: lista os autores do programa (em grupo ou individual)
  • LICENSE: TODO a licença do programa (prefira GNU GPL v2, MIT ou BSD-3)
  • VERSION: contém o número da versão atual (modificado automaticamente pelo make)
  • makefile: o script rodado pelo comando make
  • README.md: em sintaxe de Markdown, contém a "capa" que aparece no GitHub.
  • Índice ctags
  • .gitignore : faz o git ignorar certos arquivos
  • .gitattributes : permite configurar atributos por arquivo (veja abaixo)

Formatação

O estilo de indentação

Linguagem C

  • A indentação é feita de acordo com o estilo A1 descrito pelo astyle, também conhecido por –style=allman, –style=bsd ou –style=break.

O estilo Allman é um entre mais de 15 estilos e variantes disponíveis e encontradas em vários tipos de código. Não misture os estilos. Este estilo utiliza a seguinte sintaxe, chamada de broken brackets (ou chaves quebradas). Atente para os espaços entre operadores e mudanças de linhas no exemplo abaixo:

/**
 * @ingroup Modulo
 * @brief Breve descricao
 * @details Descricao detalhada
 * que pode estar em multiplas linhas
 *
 * @param[in] is_bar indice de entrada
 * @param[out] x indice recalculado de saida 
 * @param[in,out] z Entra com um valor blablabla e devolve blebleble
 *
 * @return Descricao do que a funcao retorna
 * @author Ruben Carlo Benante
 * @date 2016-06-05
 */
int foonc(int is_bar[MAX], int x, char *z)
{
    int p; /* a really though condition */

    p = !(is_bar[0] || isBar[1]);

    /* check if it's beer number 2 and not in some thugh condition */
    if(is_bar[x] == 2 && !p)
    {
        z[bar(p + 1)] = 'b';
        return 1;
    }
    else
        return 0;
}

Conheça todos os estilos na página de documentação do astyle.

  • Para aplicar o estilo no seu código, pode-se rodar o programa $astyle -A1 ex11.c

Dicas para um bom código fonte:

Comentários

  • Use comentários / estilo C /
  • Coloque um espaço após o / e um antes do /
  • Faça comentários em linha nas declarações de variável. int i; /* indice geral */
  • Evite comentários em linha em outros locais
  • Na medida do possível e do seu conhecimento, escreva tudo em inglês, desde nomes de variáveis até comentários. Se for importante usar português, então escreva as variáveis em inglês e os comentários nas duas línguas. Caso não seja possível, tudo bem usar apenas português.
  • Coloque os comentários na linha anterior ao bloco ou comando a comentar
  • Não use acentos (nem c-cedilhas) no código ou comentários
  • Use as palavras nos comentários:
    • / TODO: alguma tarefa / : para indicar algo que falta fazer
    • / BUG: esta errado assim e assado / : para indicar um bug conhecido que precisa ser corrigido no futuro.

Comentários DOXYGEN

Antes de cada função, coloque comentários na sintaxe DOXYGEN. O mínimo necessário para bem explicar uma função é detalhar:

  • Grupo do módulo: @ingroup
  • Resumo: @brief
  • Detalhes: @details
  • Opcional, pré-condições: @pre
  • Parâmetros de entrada: @param[in]
  • Parâmetros de saída: @param[out]
  • Parâmetros de entrada e saída: @param[in, out]
  • Valor de retorno: @return ou @retval (ou ambos)
  • Opcional, um aviso: @warning
  • Opcional, se a função está depreciada: @deprecated
  • Opcional, indicar funções semelhantes: @see
  • Opcional, indicar bugs: @bug
  • Opcional, indicar to do: @todo
  • Opcional, escrever uma nota: @note
  • Autor: @author
  • Opcional, colocar versão: @version
  • Data que foi escrita/modificada: @date (formato YYYY-MM-DD, ano, mes, dia)
  • Opcional, caso diferente do resto do código, colocar a licença de copyright: @copyright

O exemplo acima mostra somente os campos obrigatórios, e descreve hipotéticas variáveis como parâmetros.

No meio do código

  • Apague espaços sobrando ao final da linha (trailing spaces)
  • Não inclua espaços após (, [, { ou antes de }, ] e )
  • Use espaços após vírgulas e ponto-e-vírgulas
  • Use espaços em volta de operadores (exceto os unários como !)
  • Não cometa erros de grafia (não use acentos!)
  • Não alinhe tokens verticalmente em linhas consecutivas
  • Use indentação de 4 espaços (não use TABS)
  • Se quebrar uma linha, indente-a 4 espaços
  • Use uma linha em branco entre métodos, funções ou blocos lógicos importantes
  • Use final de linha de um byte (n) estilo Unix (*)
  • Deixe uma linha em branco ao final do arquivo conforme padrão POSIX

Variáveis

  • Variáveis com letras maiúsculas somente se:
    • São PROLOG, claro 😉
    • São MACROS (logo não são variáveis) em C (exemplo: #define CINCO 1)
    • São MUIIIITO importantes e precisam de algum destaque. Não tente usar assim, pois você provavelmente não vai convencer ninguém. 😉
  • Use nomes claros para as variáveis
  • O nome da variável deve indicar sua intenção, i.é., o dado que ela carrega.
  • Prefira nomes que demonstrem o conceito geral do domínio, ao invés dos padrões que eles implementam.
  • Não faça nomes gigantes. Um tamanho máximo que já não fica tão bom é até 15 caracteres. Tente nomes menores, até 10 no pior caso.
  • Use sublinhados para sufixos apenas se for criar variáveis que tenham alguma característica em comum. Exemplo: salario_antes e salario_depois. Se existirem muitas características em comum em um tipo de dados, considere agrupar com struct
  • Não coloque o tipo no nome da variável. Exemplo: vetor_de_alunos.
  • Coloque t_ no início de typedef. Exemplo: typedef int t_meuint;
  • Coloque st_ no início de structs. Exemplo: struct st_concreto { ... };
  • Coloque s no início de variáveis string. Exemplo: char snome[MAX];
  • Coloque p no início de ponteiros. Exemplo: t_carro *pcarro; ou char *pnome;.
  • Nomeie uma enum (enumeração) pelo substantivo comum do objeto que ela enumera.

Organização

A ordem que o esqueleto do programa deve ter é como segue:

Em linguagem C

  • Comentário com copyright, descrição do programa, autor, contato e data
  • Comentários com uma introdução à leitura do código, explicações gerais, compilação, etc.
  • O(s) #include <...>
  • O(s) #include "..."
  • Se o programa não tem uma biblioteca própria, seguem:
    • Os defines
    • Os TAD’s (tipos abstratos de dados): struct, enum, typedef, etc.
    • Os tipos globais
    • Os protótipos das funções
  • Se o programa tem biblioteca própria, estes ficam no .h
  • A função int main(void) ou int main(int argc, char *argv[])
  • As outras funções, de preferência em uma ordem que faça um mínimo de sentido com o próprio fluxo do programa

Ciclo de trabalho

  • Ligou o computador, primeira vez neste repositório
    • Tudo configurado no GitHub e na sua máquina local?
    • Repositório criado no GitHub com fork
    • Faça o clone na sua máquina
    • Crie seu ramo feature-nome ou vá para develop
    • Siga a partir do passo (1)
  • Ligou o computador para trabalhar do segundo dia em diante
    • Atualize todos os ramos remotos (master e develop)
    • Resolva conflitos se houver
    • Vá para seu ramo de trabalho feature-nome ou develop
    • (1) Edite o arquivo fonte no vi
    • (2) Compile (gcc ou make, ou teste no swipl)
    • (3) Erros: volte para passo (1)
    • (4) Compilou sem erros: faça commit
    • (5) Vai trabalhar mais, volte para o passo (1)
    • (6) Fim do dia de trabalho:
      • Vá para o develop e atualize-o
      • Faça merge do feature-nome com o develop
      • Resolva conflitos se houver
      • Teste o programa muitas vezes e corrija se necessário
      • Faça o push do develop para o GitHub
      • Ou, se usou apenas o develop, faça o push
    • (7) Dia de finalizar o master e pedir um pull request
      • Vá para o master e atualize-o
      • Faça merge do develop com o master
      • Resolva conflitos se houver
      • Teste o programa muitas vezes e corrija se necessário
      • Faça o push do master para o GitHub
      • Tudo pronto, faça o pull request e torça para ser aceito

Teste

  • Não tenha pressa de fazer push! O push é irreversível, manda para o GitHub. Enquanto estiver só na sua máquina você pode corrigir quaisquer bugs
  • Compile. Use todas as chaves de aviso que o gcc pode oferecer. O gcc é seu amigo!
  • Crie páginas com mensagens de erro com o comando sprunge para discutir nos issues se necessário
  • Use makefile para compilar seus testes
    • Não deixe de conhecer as opções do gcc para compilação. Este é um comando fundamental em vários sistemas operacionais, inclusive embarcados (arduino, pic, raspberry pi, etc.)
  • Teste! Rode o programa, faça entrada de dados, veja se o que acabou de programar realmente faz o que você deseja, e se não quebrou nada em outra função do programa.
  • Tudo ok? Então faça o push!
  • Faça suas modificações chegarem até o master e então faça o pull request do seu master (origin) para o master do upstream.
  • No pull request coloque um título descritivo.

Faça uma boa mensagem de commit

  • Se é um pequeno commit tudo bem abreviar a mensagem com apenas um título com o comando git commit -am "uma descricao do que este commit faz em ate 50 caracteres"
  • Mas se é um commit que vai influenciar muito o código de outros ramos ou que vai ser usado para pull request então é importante escrever uma boa mensagem. Neste caso, não use o comando abreviado. Use os comandos:
    • git add arquivo : se necessário adicionar algum arquivo
    • git commit : sem abreviação e sem mensagem. Este comando vai abrir o vi (ou seu editor preferido) para você digitar uma mensagem de commit maior.
      • Na primeira linha, escreva um título do commit com até 50 caracteres, como você já está acostumado.
      • Pule uma linha.
      • Da terceira linha para baixo, descreva com mais detalhes tudo o que você fez, o que este commit inclui, o que muda, qual funcionalidade é acrescentada ou bug é resolvido.
      • Saia com :x (no vi) para salvar e fazer o commit
      • Saia com :q! (no vi) para abortar a edição e não fazer o commit
      • Linhas iniciadas com # são ignoradas pelo git como sendo comentários e não são escritas no commit.
  • Exemplo de uma boa mensagem de commit:
Faz um exemplo para demonstrar a clareza do commit

Sem este commit a explicação sobre mensagens de commit ficaria 
falha, sem um exemplo concreto. Este é um problema, porque assim 
fica apenas na imaginação o que seria um bom commit.Este commit 
corrige este problema ao fazer aqui um exemplo concreto e imperativo.

A primeira linha é um título imperativo descritivo do essencial. 
Os dois parágrafos seguintes, o de cima e este, são explicações mais 
aprofundadas. É importante descrever:

(1) _o que ocorria_ antes do commit, 
(2) _qual_ é o problema que este commit resolve, 
(3) _porque_ este comportamento é problemático, e 
(4) _como_ este commit corrige este problema.

Também é possível usar enumerações para clarificar algumas mudanças 
em pontos específicos, como:

* mudafunc() : agora não retorna mais void e sim o código do cliente
* funcoutra() : criada para cumprir outra finalidade que faltava
* divideaqui() : criada para cumprir uma finalidade tal e tal que 
antes estava sendo feita na função mudafunc() de modo a ficar mais 
clara a divisão do que cada função faz.

Lembre que a primeira linha é importante para ver o log e acompanhar a evolução do programa.

Dicas de configuração

Final de linha estilo Unix (n)

  • Para o final de linha n, use em suas configurações
    • Linux, Mac ou Unix: git configure --global core.autocrlf input
    • Windows: git configure --global core.autocrlf true
  • Outra opção para configurar n é por repositório. Inclua um novo arquivo .gitattributes com os comandos:
# Arquivo .gitattributes

* text=auto
*.c text
*.h text
*.txt text
*.ini text
*.eng text
*.x binary
*.jpg binary
*.png binary

Obrigado!

Agora é com você! Divirta-se programando!

Atenciosamente,

Prof. Dr. Ruben Carlo Benante <rcb@beco.cc>

Autor do brainforce

Formato para nomes dos posts: YYY-MM-DD-titulo-do-post.md

Codigo em linha com acentos graves, e tantas outras facilidades da linguagem Markdown.

Jekyll também oferece suporte para código fonte:

Exemplo com código em C:

int main(int argc, char **argv)
{
    int d;

    d=getchar();
    putchar(d);

    return EXIT_SUCCESS;
}

Exemplo com código em Ruby:

def print_hi(name)
  puts "Hi, #{name}"
end
print_hi('Beco')

Veja Jekyll docs para mais informacoes. Faça fork do repositório do Jekyll para iniciar seu site.

Plan Your Content

laptop

If you’re considering adding a blog to your site, you’ll want to have a plan beforehand. Planning your blog will help your subject matter remain consistent over time. It’ll also help you determine whether or not there’s enough material to maintain a steady stream of posts.

One pitfall many new bloggers run into is starting a blog that isn’t posted to frequently enough. A shortage of recent posts can give your visitors a bad impression of your business. One may think “I wonder if they’re still in business” or “they may want to hire a writer.”

A blog, like any other customer facing aspect of your business, communicates your brand. If it isn’t maintained and given proper attention, people will notice. Post regularly and keep your content fresh. Give your audience a reason to visit often.

Read more >

Categories and Tags

desktop

If you write about a variety of subjects, categories can help your readers find the posts that are most relevant to them. For instance, if you run a consulting business, you may want some of your posts to reflect work you’ve done with previous clients, while having other posts act as informational resources. In this particular case, you can set up 2 categories: one labeled Projects and another labeled Resources. You’d then place your posts in their respective categories.

Read more >

Pages vs. Posts

clock

If you’re new to WordPress you may be wondering what’s the big deal behind Pages and Posts. At first glance they appear to be one and the same: if you were to create either a new page or a new post you’d be presented with nearly identical interfaces and in many cases the public appearance of pages and posts will look the same.

Don’t let this fool you. There’s a very fundamental difference between the two and that difference is what makes CMSs, like WordPress, great platforms for integrating blogs with traditional websites.

Pages

Think about the kind of pages that make up a typical website. Most often you’ll see pages like “Home”, “About Us”, “Services”, “Contact Us”, etc. Within WordPress these are often treated as Pages; documents that have no particular regard for the time they were posted.

For example, when you visit the “About Us” page of your favorite company’s website you don’t expect the content to be very different from what was available there a week ago.

Read more >