Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à Git Acquainted
Similaire à Git Acquainted (20)
Dernier
Dernier (20)
Git Acquainted
- 1. Git Acquainted An introduction to version control with Git
- 2. Tyler Hunt @tylerhunt
- 4. −−− git +++
- 7. History
- 10. Repository
- 11. Branch
- 12. History
- 13. RCS & CVS Mid 80s
- 14. Subversion Early Aughts
- 15. Git Mid Aughts
- 16. Open Source
- 17. Distributed
- 18. Redundant
- 19. Non-linear
- 20. Basics
- 21. > mkdir project > cd project > git init Initialized empty Git repository in /project/.git/
- 22. > touch README > git status # On branch master # # Initial commit # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # README nothing added to commit but untracked files present (use "git add" to track)
- 23. > git add README > git status # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached <file>..." to unstage) # # new file: README #
- 24. > git commit -m ‘Added file for documentation.’ [master (root-commit) 63b94ad] Added file for documentation. 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 README > git status # On branch master nothing to commit (working directory clean)
- 25. > echo ‘Documentation’ > README > git status # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: README # no changes added to commit (use "git add" and/or "git commit -a") > git diff README diff --git a/README b/README index e69de29..c3f01bd 100644 --- a/README +++ b/README @@ -0,0 +1 @@ +Documentation > git commit -m 'Updated documentation.' [master a382e49] Updated documentation. 1 files changed, 1 insertions(+), 0 deletions(-)
- 26. Branching
- 27. > git branch * master > git checkout -b documentation Switched to a new branch "documentation" > git branch * documentation master > git checkout master Switched to branch "master" > git branch documentation * master
- 28. > git checkout documentation Switched to branch "documentation" > echo ‘More Documentation’ >> README > git commit README -m ‘Wrote more documentation.’ [documentation fbe3fdd] Wrote more documentation. 1 files changed, 1 insertions(+), 0 deletions(-) > git checkout master Switched to branch "master" > git merge documentation Updating a382e49..fbe3fdd Fast forward README | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
- 29. > git log commit fbe3fdd6c09f2de540866108348bb33b7ee6b620 Author: Tyler Hunt <tyler@tylerhunt.com> Date: Wed Dec 2 23:30:32 2009 -0500 Wrote more documentation. commit a382e49c9dadaff6b65a948a7736367391a0c625 Author: Tyler Hunt <tyler@tylerhunt.com> Date: Wed Dec 2 23:29:17 2009 -0500 Updated documentation. commit 63b94ad5c0c035d915370b5101af22bc1270b5a9 Author: Tyler Hunt <tyler@tylerhunt.com> Date: Wed Dec 2 00:23:20 2009 -0500 Added file for documentation.
- 30. > cat README | sed -e 's/More/Less/' > README > git commit README -m ‘Less is more.’ [master 80e7a3b] Less is more. 1 files changed, 1 insertions(+), 1 deletions(-) > git checkout documentation Switched to branch "documentation" > cat README | sed -e 's/More/More and More/' > README > git commit README -m ‘More is more.’ [documentation ed8b839] More is more. 1 files changed, 1 insertions(+), 1 deletions(-) > git checkout master Switched to branch "master" > git merge documentation Auto-merging README CONFLICT (content): Merge conflict in README Automatic merge failed; fix conflicts and then commit the result.
- 31. > git stat README: needs merge # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # unmerged: README # no changes added to commit (use "git add" and/or "git commit -a") > cat README Documentation <<<<<<< HEAD:README Less Documentation ======= More and More Documentation >>>>>>> documentation:README > vi README
- 32. > git add README > git commit [master 29c758b] Merge branch 'documentation'
- 33. > git log commit 29c758b5e64b5a7c4a8ecc1776e1a124236c6257 Merge: 80e7a3b ed8b839 Author: Tyler Hunt <tyler@tylerhunt.com> Date: Wed Dec 2 23:46:08 2009 -0500 Merge branch 'documentation' Conflicts: README commit ed8b83965b9b089c6a354c40883c602d288a6e4a Author: Tyler Hunt <tyler@tylerhunt.com> Date: Wed Dec 2 23:42:56 2009 -0500 More is more. commit 80e7a3b3ccc3e0714e8ab9108e3d3ac3a1e175bb Author: Tyler Hunt <tyler@tylerhunt.com> Date: Wed Dec 2 23:42:01 2009 -0500 Less is more.
- 34. Collaborating
- 37. > git remote add origin git@github.com:tylerhunt/project.git > git push origin master Counting objects: 18, done. Delta compression using 2 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (18/18), 1.38 KiB, done. Total 18 (delta 1), reused 0 (delta 0) To git@github.com:tylerhunt/project.git * [new branch] master -> master
- 38. > git clone git://github.com/tylerhunt/relax.git Initialized empty Git repository in /project/.git/ remote: Counting objects: 18, done. remote: Compressing objects: 100% (6/6), done. remote: Total 18 (delta 1), reused 0 (delta 0) Receiving objects: 100% (18/18), done. Resolving deltas: 100% (1/1), done.
- 40. Tips
- 41. ~/.gitconfig
- 42. .gitignore
- 43. Tags
- 44. Questions
Notes de l'éditeur
- My hope tonight is to give you an introduction to version control with Git.
- I&#x2019;m Tyler Hunt, and @tylerhunt on Twitter.
- I have a little blog and software company called Devoh.
- Before we jump into talking about git, I want to first take a step back.
- I want to start off talking a bit about version control. Why is it important? Why should you use it?
- So you don&#x2019;t have to have files like this lying around.
- It keeps a history of all of the changes ever made to your files. If you need to revert back to an old version, or figure out why something was changed, the history is always there for you.
- And if you&#x2019;re working in a team, even if it&#x2019;s just two people, version control is a must. It&#x2019;s the best way to synchronize your development efforts. It&#x2019;s also a great way to keep an audit trail of who made which changes.
- A repository is a complete collection of all of the files in a project and their full version history.
- A branch is a way to duplicate the resources in a repository to allow parallel modifications to be made. This lets you start on a feature, and then switch branches to work on something else. Also, used to maintain separate development and production branches.
- RCS, Revision Control System, was an early attempt at version control that only worked with individual files. CVS, Concurrent Versions System, was originally devised as a set of scripts on top of RCS to allow multiple files to be managed.
- Subversion was designed as a mostly-compatible replacement for CVS. It fixed some of the limitations of CVS, like it&#x2019;s lack of knowledge about directories.
- Git was created by Linus Torvalds as a replacement for BitKeeper, which was the version control software used for the Linux kernel at the time.
- The reason Linus even thought about creating a new version control system was over a licensing change with BitKeeper that meant it was no longer free for kernel developers to use. An open source solution prevents this from happening.
- Git&#x2019;s biggest advantages over Subversion is its distributed nature. With Git, there&#x2019;s no longer a single master repository, but all repositories are equal.
- Without a centralized repository, there&#x2019;s an implicit layer of redundancy. If the repository on the server is corrupted, you can simple copy up your local repository.
- Git was designed to be fast for non-linear development styles. It makes it trivial to create and change branches.
- Let&#x2019;s jump in now and show how its used. I&#x2019;m not going to cover installation since it varies depending on your platform.
- First, we&#x2019;ll make a new directory for our project. Then we&#x2019;ll switch to that directory and initialize a new repository there. This creates a .git directory inside our project where all of the metadata will be stored.
- Here we create a new file, and then check the status of our repository. The output of `git status` shows that there&#x2019;s one &#x201C;untracked&#x201D; file. It also tells us how we can start tracking that file.
- Here, we&#x2019;ve added the file to the repository, and then checked its status again. The file has been added to what&#x2019;s called the &#x201C;index.&#x201D; This is like a staging area for commits. Now that the file has been added, we can do the actual commit.
- Here we commit the contents of the index using a command line argument for the commit message. Leave off the message will open an editor where you can write your message. Now our working directory is clean, meaning all of our changes have been committed.
- We we make changes, git will let us know which files have been modified. Doing a `git diff` shows the modifications that have been made since the last commit. It&#x2019;s a good idea to review your changes before adding and committing.
- Now let&#x2019;s take a look at branching and merging. Branches are a way to isolate the changes you&#x2019;re making from the rest of the project. It&#x2019;s a good practice to create a branch for each new task.
- `git branch` show us all of the local branches in our repository. `git checkout -b` will create a new branch and switch to it. `git checkout` will switch branches.
- Now let&#x2019;s switch back to our documentation branch and write some more documentation. Then we&#x2019;ll commit our changes. Next, we&#x2019;ll switch back to master and merge them in. Normally you wouldn&#x2019;t do the merge until the code is complete, tested, and ready to deploy.
- `git log` will show us the history of all of our commits on the current branch. As you can see here, the commit from our documentation branch is now on master. Merging is like copying all of the new commits from one branch into another.
- GitHub is a social network for coding. It&#x2019;s a web service providing hosted git repositories, with a focus on ease of collaboration.
- We&#x2019;re going to use GitHub to create a new repository for our project. You can create as many public repositories as you like for free.
- Once the repository has been created, you&#x2019;ll get a screenful of instructions. Here are the steps they give for pushing your local repository up for the first time. Remotes are simply non-local repositories. Pushing to a remote syncs it up with your local.
- Once you&#x2019;ve pushed the code up to GitHub, it&#x2019;s easy for anyone else to work with it. `git clone` is used to make a local copy of a remote repository. Here, we&#x2019;re cloning our newly created GitHub repository using it&#x2019;s public clone URL.
- The social power of GitHub is really manifested in the fork feature. This creates a clone of someone else&#x2019;s repository under your own account. You can then work on it, push up your changes, and then submit a &#x201C;pull request.&#x201D;
- This is where you&#x2019;ll set up the name and email address that identifies you as a comitter. GitHub will also use this to identify match up your commits with your GitHub account. You can also create aliases here for git commands, like &#x201C;stat&#x201D; for &#x201C;status.&#x201D; Helpful for SVN.
- Each repository can have a .gitignore file in its root. This file specifies paths and file names that you want to leave out of the repository. Temporary files and configuration files containing authentication credentials.
- You can also tag specific commits in your repository. This is useful for marking a commit as a release of a new version of your application. It might also be used to mark when your repository was last deployed.