Skip to content

Instantly share code, notes, and snippets.

@leonardovff
Forked from rolandoam/gist:2423749
Last active November 4, 2019 19:58
Show Gist options
  • Save leonardovff/4e53c90885bef1332184e7e44f3dafcb to your computer and use it in GitHub Desktop.
Save leonardovff/4e53c90885bef1332184e7e44f3dafcb to your computer and use it in GitHub Desktop.
git presentation

Agenda

  1. Visão geral do controle de verso e git (15 mins)
  2. A sample git work flow (5 mins)
  3. Successful projects and their characteristics (5 mins)
  4. Recomendaçes (5 mins)
  5. Discussão and Q&A (15 mins)
  6. Git flow?
  7. Referências

Throughout this document italics denote my opinion. All other information should be objective :)

Sobre mim

Resumo

  • Existe milhares de projetos utilizando Git e Github
  • https://github.com/explore
  • Use templates de projetos de código aberto
  • IMPORTANTE: Não reinvente a roda. Use estratégias já documentadas.

=== 1 ===

Visão geral do controle de versão e git

Controle de verso

  • Deve ser usado para toda programação
  • Mas por quê?

Uso

  • Fonte de código distribuido para programadores
  • Entre de código fonte
  • Gerenciamento de entregas

Importante uso

  • Compartilhamento de código fonte!
    • revisar mudanças
    • reverter mudanças
    • gerenciar múltiplos programadores
    • usando a mesma base de código
  • Melhora da produtividade
    • A alternativa é trabalhar sozinho

Também para a organização!

  • Trabalhar em uma unica base de código...
    • múltiplos trabalhos simultâneos
    • revisar e reverter

Git

http://www.git-scm.com

Desenvolvido inicialmente by Linus Torvalds. O primeiro cliente foi o projeto do kernel do Linux.

  • Controle de versão distribuído
  • Todo repositório Git tem o histórico completo de todos os arquivos no projeto.

Git (contd.)

  • Informaço de seguraça: Todo commit pode ser identificado por um hash

GitHub

GitHub é uma grande plataforma de hospedagem de code construido com Git. http://www.github.com

  • Organizaçes
  • Repositórios
  • Navegador de histórico na web
  • Gerenciador de code merges ("pull requests")

GitHub (contd.)

  • Used by many, many, many actively developed projects
  • Cocos2D, Ruby on Rails, nodejs, XBMC, Android, CyanogenMod,
  • FacebookSDK, AmazonSDK, Git, etc.

=== 2 ===

Um simples workflow com Git

Trabalhando com Git

> git init .                   ### Inicializa o repósitório
> touch <filenames>            ### cria arquivos, repositório git ainda vazio
> git add <filenames>          ### adiciona na staging area, repositório git ainda vazio
> git commit -m "Message text" ### committed! repósitório agora possui uma versão.

Trabalhando com Git (contd.)

  • Um repósitorio contém: arquivos locais, area de staging, árvore de versões
  • Cada versão é identificado por um HASH

Branches

  • Levando em consideração "AlgumSDK"
  • Assume que você tem quer trabalhar na adição de "facebook support"
  • Você tem duas escolhas:

Branches (contd.)

Escolha 1 : Faça uma de "AlgumSDK" em seus arquivos locais

    > cp -rf AlgumSDK AlgumSDK-facebook-support  ### Copia o repósitorio inteiro
    > cd AlgumSDK-facebook-support               ### Novo repósitorio tem o historico completo
    > touch supportfacebook.cpp                  ### Faça mudanças
    > git add supportfacebook.cpp
    > git commit -m "Add facebook support"       ### Commit para o repósitorio

Branches (contd.)

Choice 2 : Faça uma branch chamada "facebook-support"

    > cd SomeSDK
    > git checkout -b "facebook-support"         ### Nova branch, somente como uma cópia dos diretórios
    > touch supportfacebook.cpp                  ### Faça mudanças
    > git add supportfacebook.cpp
    > git commit -m "Add facebook support"       ### Commit para o repósitorio, em uma branch chamada "facebook-support"

Remotes

  • Cada repósitorio Git tem o histórico completo (Git é distribuídos)
  • Pode conter referências a outros repositórios ("remotes")
  • Referenciado por um nome "semelhante ao sistema de arquivos"
    • "remotes/origin"

Remotes (contd.)

  • As branchs nos controles remotos também são referenciadas por um nome "semelhante ao sistema de arquivos"
    • "remotes/origin/master"
    • "remotes/origin/async-file-io"

Compartilhando mudanças com Git

> ### Desenvolvimento ...
> git checkout -b <name of feature> ### Cria uma nova branch
> touch <filenames>                 ### Faz uma mudança - criando um arquivo
> git add <filenames>               ### Adicionar na area de staging
> git commit -m "A change"          ### commits mudanças
> git format-patch HEAD~..HEAD      ### Makes a patch of the most recent commit
> mail <0001-A-Change>              ### ... Email patch to committer

Compartilhando código com Git (contd.)

> ### Committer ...
> git am <patch files>              ### Applies patch to repository

Compartilhando código com Git (contd.)

> ### Developer ...
> git branch -d <name of feature>   ### Change accepted! Delete branch.
> git checkout master               ### Switch to master branch
> git fetch origin                  ### Get the changes from committer
> git rebase origin/master master   ### Re-applies master on top of origin/master 
                                    ### Developer now has committer's changes!
                                    ### Including Developer's previous change titled "A change"

Trabalhando com GitHub

  • GitHub disponibiliza uma conta de desenvolvedo
  • Cada conta pode ter vários repositórios
  • Cada repositórios pode ter várias branches
  • Pense no sua conta GitHub como uma "pasta compartilhada de repositórios"

Trabalhando com o GitHub (contd.)

  • Existe multiplos usuários com suas contas GitHub
  • Também organizações:
    • Uma organização é como um user que contém repositórios
    • Uma organizaço pode ter vários membros também.

Trabalhando com o GitHub (contd.)

Trabalhando com GitHub (contd.)

> cd $HOME
> git clone https://github.com/@your_account/testeproject.git ### Cria um repositório chamado "testeproject" na sua $HOME
> cd testeproject
> git remote -v                     ### Irá listar todos os remotes
                                    ### Atualmente "origin" irá apontar para o endereço de onde você clonou o repositório" https://github.com/@your_account/testeproject.git"
> git branch -a                     ### Lista todas as branches visíveis
                                    ### "master" and "remotes/origin/master"

Trabalhando com GitHub (contd.)

> touch <filenames>                 ### Faz mudanças
> git add <filenames>               ### Adicionar na area staging 
> git commit -m "A change"          ### commits mudanças
> git push origin master            ### sobre as mudanças para o remote chamado origin
                                    ### O qual é o seu repositório "[email protected]:developer/testproject.git"

Working with GitHub (contd.)

  • Então, usando o github.com tem dois repositórios
  • Up to the developer to keep them in sync

Sharing changes with GitHub

Sharing changes with GitHub (contd.)

Sharing changes with GitHub (contd.)

Sharing changes with GitHub (contd.)

  • Now, tell the committer that developer forked from
  • Open a github pull request
  • If Committer likes the changes, they will pull changes into their repository
  • OR, submit patches using git style (described earlier.)

Syncing Repos

  • This seems to be confusing
  • To RECAP : GitHub hosts git repos, Developer make clones of these repos
    • on local machines
  • These are two entirely separate Git repos
  • Connected only by a "git remote" entry

Syncing Repos (contd.)

  • Repos may go out of sync
    • Developer makes changes in local machine
    • Commits are added in GitHub repo
  • Also, Committer's repo and Developer's GitHub and Developer's repos
    • may go out of sync!
    • They are still separate Git repos
    • connected only by a "git remote" entry

Syncing Repos (contd.)

  • Discussion

=== 3 Successful projects and their characteristics ===

Example Git projects

  • A Git project with frequent contributions
  • Many developers. Let's say at least 10.
  • Developed in the open so we can learn from it.
  • With credible committers (hello... Linus Torvalds!)

Example Git projects (contd.)

  • Their developers have motivation to learn tool use
    • To get their commits/patches into the project
    • And therefore their contributions get credited!
  • Committers and developers have dealt with Git and GitHub issues

Example Git projects (contd.)

Example Git projects (contd.)

Example Git projects (contd.)

Example Git projects (contd.)

Characteristics

Note : These characteristics are less about Git and more about successful code

  1. Freedom to fork
  2. Code is always stable
  3. Easy to build
  4. Well defined commit criteria
  5. One committer or small committer team
  6. Committer reviews and integrates changes
  7. Easy to understand commit tree, few branches

=== 4 Recommendations ===

GitHub Teams and organizations

  • Create a GitHub organization for your project
  • If it is a game, use the name of the game
  • If it is a product, use the name of the product

GitHub Teams and organizations (contd.)

  • GitHub creates an "Owners" team
  • Create a "Developers" team
  • Add all developers to the "Developers" team
  • Minimize the Owners team

I suggest adding a non-programmer as an Owner to avoid accidental deletion. Maybe a QA engineer?

Project repos

  • Create repos for your project
    • https://github.com/
      • .../SpeedRacer/UnrealEngine
      • .../SpeedRacer/ZDK-Android
      • .../SpeedRacer/ZDK-iOS
      • .../SpeedRacer/FacebookSDK

Cloning

  • Individual developers should clone the projects they work on
  • For example :

Individual workflow

  • Discussed in "3 : A sample git work flow"

Contributing patches

Reviewing and committing

  • One owner per repository
  • Responsible for committing all changes
  • Maybe a small team for large repos
  • Too many committers causes chaos
  • ... and project loses direction

Reviewing and committing (contd.)

Feature branches

  • I suggest using feature branches in individual repos
  • Many developers find it painful
  • Highly recommended for larger changesets
  • You can generate GitHub pull requests from any-branch-to-any-branch
    • so can generate pull requests from a feature branch to a master

Fast forwarding

  • Please use fast-forwarding
  • It keeps history clean
  • It makes the committer's job easy

A note on branching

A note on branching (contd.)

  • This branching model is flawed :
    • previous released branches cannot be hot-fixed cleanly
    • Individual developers cannot rebase
    • fast-forward merges are impossible
  • It's basically Subversion in a Git repository.
  • Don't use it for a team

It's fine for individual developers

=== 5 Discussion and Q&A ===

=== 6 References ===

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment