Allows you (and your team) to do 2 powerful things
Create anything with other people, from academic papers to entire websites and apps.
See the changes that have been made
Go "back in time" to a past version
No, really this time.
1990s -- CVS (Concurrent Version Systems)
2000s -- SVN (Apache Subversion)
2005 -- Git (well, Git)
Examples: CVS, SVN
One central server, each client (person) checks out and merges changes to main server
Examples: Git, Mercurial
Each client (person) has a local repository, which they can then reconcile with the main server.
Here are some of the most basic ones.
A repository is usually used to organize a single project. Repositories can contain folders and files, images, videos, spreadsheets, and data sets – anything your project needs. We recommend including a README, or a file with information about your project.
While a README isn't a required part of a GitHub repository, it is a very good idea to have one. READMEs are a great place to describe your project or add some documentation such as how to install or use your project. You might want to include contact information - if your project becomes popular people will want to help you out.
Whenever you add, edit, or delete a file, you're making a commit, and adding them to your branch.
Each commit has an associated commit message, helpful for others to understand your code.
Each commit is a separate unit of change, letting you roll back changes.
git init git status
Create a new hello_world.txt file in your new folder
Check repo status
Tell Git to track our new file
git add hello_world.txt git status
File is now tracked by Git
Open hello_world.txt and add some more text
Stage and commit the change
git add hello_world.txt git commit -m "First commit. Added hello world to repository."
Create a new branch
Create a new branch called trucs-slides
git checkout -b trucs-slides
Add new lines to hello_world.txt
git add hello_world.txt git commit -m "Adding changes to trucs-slides
See all branches. Branch with * is active
Switch to master and look at hello_world.txt
git checkout master
Switch to version2 and look at hello_world.txt
git checkout version2
Knowledge Test: When you
commit, will the chnages you make show up online?
Commits are local, so they don't appear in your host environment until you
Deploy your changes to verify them in production.
If your branch causes issues, you can roll it back by deploying the existing master into production.
cd ../ git clone https://github.com/username/FORKED-REPO-NAME.git cd FORKED-REPO-NAME git remote add upstream https://github.com/original-username/FORKED-REPO-NAME.git # Assigns the original repository to a remote called "upstream" git fetch upstream # Pulls in changes not present in your local repository, without modifying your files
Pull Requests initiate discussion about your commits.
You can open a Pull Request at any point during the development process.
clonea repository all pushed changes will go to your fork
If you are the owner of repo, you will review and decide whether to merge in the pull requests you receive.Learn more at Github Collaboration Tutorials
Pull Requests are designed to encourage and capture discussion to make your code great.
If someone comments that there is a bug, you can fix it in your branch and push up the change.
GitHub will show your new commits and any additional feedback.
Merge your code with the master branch!
Once merged, Pull Requests preserve a record of the historical changes to your code.