- Visão geral do controle de verso e git (15 mins)
- A sample git work flow (5 mins)
- Successful projects and their characteristics (5 mins)
- Recomendaçes (5 mins)
- Discussão and Q&A (15 mins)
- Git flow?
- Referências
Throughout this document italics denote my opinion. All other information should be objective :)
- https://github.com/leonardovff
- Eu usei dois sistemas de controle de verses
- um distribuído e o outro centralizado
- SVN, GIT
- Usando git desde 2015
- 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.
- Deve ser usado para toda programação
- Mas por quê?
- Fonte de código distribuido para programadores
- Entre de código fonte
- Gerenciamento de entregas
- 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
- Trabalhar em uma unica base de código...
- múltiplos trabalhos simultâneos
- revisar e reverter
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.
- Informaço de seguraça: Todo commit pode ser identificado por um hash
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")
- Used by many, many, many actively developed projects
- Cocos2D, Ruby on Rails, nodejs, XBMC, Android, CyanogenMod,
- FacebookSDK, AmazonSDK, Git, etc.
> 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.
- Um repósitorio contém: arquivos locais, area de staging, árvore de versões
- Cada versão é identificado por um HASH
- Levando em consideração "AlgumSDK"
- Assume que você tem quer trabalhar na adição de "facebook support"
- Você tem duas escolhas:
> 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
> 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"
- 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"
- 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"
> ### 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
> ### Committer ...
> git am <patch files> ### Applies patch to repository
> ### 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"
- 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"
- 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.
- Login como desenvolvedor
- Crie um projeto chamado TesteProject on GitHub
- Use a interface web
- Crie um repositório chamado TesteProject
- https://github.com/@your_account/testeproject
- Clone esse repositório sua máquina local
> 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"
> 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"
- Então, usando o github.com tem dois repositórios
- Up to the developer to keep them in sync
- GitHub provides each Developer with an account
- Committer has a similar account
- Committer has a project named SomeProject
- Developer can fork SomeProject
- Now there is a copy of the SomeProject repo at
- Work on this by cloning to your local machine
- Make changes
- Commit these changes in your local machine's repo
- Push these changes to https://github.com/developer/Someproject
- Now, changes are visible to the world!!!
- 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.)
- 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
- 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
- Discussion
- 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!)
- 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
- What is not a good example?
- ... A webpage with a lot of statements about Git usage, but no proof.
- http://nvie.com/posts/a-successful-git-branching-model/
- Git
- Linux
- Ruby on Rails
- nodejs
- cocos2d
- Cairo
Note : These characteristics are less about Git and more about successful code
- Freedom to fork
- Code is always stable
- Easy to build
- Well defined commit criteria
- One committer or small committer team
- Committer reviews and integrates changes
- Easy to understand commit tree, few branches
- 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 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?
- Create repos for your project
- https://github.com/
- .../SpeedRacer/UnrealEngine
- .../SpeedRacer/ZDK-Android
- .../SpeedRacer/ZDK-iOS
- .../SpeedRacer/FacebookSDK
- https://github.com/
- Individual developers should clone the projects they work on
- For example :
- https://github.com/
- .../xxxx/UnrealEngine
- .../yyyy/ZDK-iOS
- https://github.com/
- Discussed in "3 : A sample git work flow"
- Use GitHub pull requests
- OR
- Use the example of a successful project :
- http://www.cocos2d-iphone.org/wiki/doku.php/faq
- 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
- http://www.cocos2d-iphone.org/wiki/doku.php/faq
- https://github.com/gitster/git/blob/master/Documentation/SubmittingPatches
- 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
- Please use fast-forwarding
- It keeps history clean
- It makes the committer's job easy
- The top Google hit for "git branching model" is
- DONT trust Google Search for your project :-)
- DO ask for objective measurements
- 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