Git is the most popular Version Control System (VCS) for software development. It is used to keep track of changes to files and projects over time. It can be used just locally in the terminal or, in conjunction with GitHub, it can be used for remote collaboration.
Git starts off with a project repository. A repo is a folder with Git tracking turned on which means it will allow tracking of all the files and folders in and under that main repo folder. Because Git is focused on managing the changes, it is often used to allow multiple contributors to work on files at the same time. When changes are saved, a snapshot is taken of the entire project as a commit which will also have a commit message as an annotation of what changes are taking place with that commit. This gives the ability to search through the project history and undo any problematic bugs or remove unwanted features.
- Initializing Git
git initcommand must be ran from inside the repository folder to begin the tracking process- Cannot initialize an empty repository
git status- to see commits, untracked files, and files in the staging area
starperfect~/best_animals[master]$ git status
On branch master
Your branch is up to date with \'origin/master\'.
nothing to commit, working tree clean
git add <filename>- add to the staging area to be tracked
git commit -m 'Commit message'- Takes a snapshot of the repo along with a message clearly describing the changes
gif diff <filename>- After make changes to a file and re-adding it to the staging area, git diff will display the differences between the last commit and the new version of the file in the staging area
starperfect~/best_animals[master !]$ git diff reptiles.txt
diff --git a/reptiles.txt b/reptiles.txt
index e69de29..3d9b440 100644
--- a/reptiles.txt
+++ b/reptiles.txt
@@ -0,0 +1 @@
+Chinese Water Dragon
GitHub was developed in 2008 as a web application that is built on top of Git. Here are some highlights on GitHub:
- Git was difficult to use with a steep learning curve, GitHub is much more user friendly
- Added a bunch of collaboration and exploration tools such as
- Pull Requests allowing Code Review
- Issues to track bugs, enhancements, or other requests
- Increased productivity
- Allowed multiple users to access code through various remote computers
- Create the Master Repository
- Always remember one rule: anything in the master branch is always deployable
- Create a Branch
- This is for trying out new ideas or working on features
- Give your branch a very descriptive name so others can see what is being worked on
- Add Commits
- Anytime you add, edit, or delete a file, you're making a commit to keep track of your progress
- Commit messages are important as they allow for a transparent history of changes and to let others proide feedback
- Open a Pull Request
- Initiates discussion about your commits
- Use @username to get feedback from particular users
- If using a Fork & Pull model, pull requests provide a way to notify the project ownders about the potential features or changes you'd like them to implement
- If using a Shared Repository Model, pull requests help start code review and conversation about proposed changes before they are merged into the master branch
- Discuss & Review Code
- Receive feedback, make any necessary changes, again creating a commit message history of any changes
- Deploy
- As a final test, you can deploy from your branch before fully merging back into the Master
- If any issues arise in production, you can roll back to the Master
- Merge
- If branch deploy doesn't cause any issues in production and everything is working as it's supposed to, then you can merge the branch into the Master branch
- If your Pull Request is to fix Issues, you can write
Closes #11and Issue #11 would then be closed in the repository