Imagem de mapa, para colorir um pouco

[alexandre-mbm]

Já inclui o PR #24.
Não é grande coisa, mas julgo melhor do que o que estava. "Um pouco de cores..."
Também há algumas correções.

Imagens de tela

Na página inicial, o mapa aparece no centro:

Em todas as outras demais páginas, que são de conteúdo, o cabeçalho é que dá o toque:

A largura das imagens foi corrigida para uma exibição uniforme inclusive em telas pequenas:

[alexandre-mbm]

A imagem foi feita branqueada, invés de se usar opacidade em CSS, para que o tamanho do arquivo diminuísse e a compressão JPEG pudesse ser usada sem perdas de qualidade relevantes.

[jgpacker]

Bem legal a imagem de fundo.
Vou deixar para comentar as outras alterações no #24

[alexandre-mbm]

Sugiro que somente seja aceito após o #24. A screenshot acima não corresponde mais, devido a dizeres terem sido alterados.

[jgpacker]

Oi, acho que esse PR só precisa de um rebase a partir do #24, e daí já dá pra fazer merge.

[alexandre-mbm]

Desculpem-me, eu não tinha percebido que ele jazia sem sincronia, com regressão, sem atualização. Vou olhar isso hoje e comunicarei aqui quando tudo estiver atual e nisso pronto para o merge.

[alexandre-mbm]

Pronto! Pode aceitá-lo. Não foi feito um rebase. Eu até testei, mas foi feito um merge recursivo. O git fez isso automaticamente, pelo git merge master. Acho mais seguro. Update 1: é... podia ser rebase, ficaria mais limpo. Eu só não quis forçar o push.

---

Update 2: parece que eu fiz besteira ao preferir mesclar o master dentro do branch de feature.

As a rule of thumb, fork master should always be in sync with upstream master (ie. only do fast forward merges/pulls), only having the commits that are in upstream already. Also, you should never have to merge master (local or remote) into a feature branch. If you need to update an existing feature branch, rebase it rather than merging into int.

Vou empurrar o rebase agora, então.

Update 3: eu pude ver que as duas estratégias funcionariam. Mas o aspecto do histórico depois do rebase talvez seja mesmo mais simples, ainda que traga para a frente commits que foram de uma passado mais distante. Enfim, o branch de feature vem com um commit a menos e, sendo só em parte já um "branch público", sim, a boa prática muito provavelmente é o rebase.

No diagrama acima, as datas dos commits com novos identificadores parecem mudadas. Porém, na verdade, se inspecionamos o histórico com git log, vemos que as datas estão inalteradas.