A comprehensive guide to version control and collaborative development.
git --version # Check if Git is installed and see its version
.gitignore
from the start. This file tells Git to ignore certain files or folders (like temporary files, system files, or sensitive information) that you don't want to track in your project. This keeps your repository clean and focused only on the important code.git config --global user.name "John Doe" # Your full name
git config --global user.email "john.doe@example.com" # Your email address
.git
folder that stores all the version control magic.
mkdir my_new_project # Create a new folder
cd my_new_project # Go into the folder
git init # Initialize Git in this folder
git clone https://github.com/user/project-name.git
git status # Always run this to see your current Git situation!
git add my_amazing_feature.js # Stage a specific file
git add . # Stage ALL changes in the current folder (be careful!)
git commit -m "Add header section to homepage"
# The -m stands for 'message'. Write a clear, short message!
git log # Full, detailed history
git log --oneline # Compact, one-line summary for each commit
git log --graph # Shows branches and merges visually (super helpful!)
.gitignore
file to tell Git to ignore things like compiled code, secret API keys, or temporary files.main
(or master
). When you create a new branch, you're making a copy of your project at that moment, so you can make changes without affecting the main version. This is great for:
git branch new-feature # Create a brand new branch named 'new-feature'
git branch # List all branches you have (the one with '*' is your current branch)
git branch -d old-branch # Delete a branch you've already merged (clean up!)
git branch -D old-branch # Force delete a branch (use with caution, even if not merged)
git checkout new-feature # Switch to the 'new-feature' branch
git checkout -b another-feature # Create a new branch AND switch to it in one go!
git checkout main # First, go to the branch you want to merge *into*
git merge new-feature # Now, merge changes from 'new-feature' into 'main'
If Git can't figure out how to combine changes automatically (e.g., you and a teammate changed the *exact same line* differently), you'll encounter a Merge Conflict. Don't panic! Git will tell you which files have conflicts, and you'll manually decide which changes to keep. We'll cover resolving these on the next slide!
# Not recommended for beginners on shared branches!
git checkout my-feature && git rebase main
feature/login-page
, bugfix/nav-bug
, hotfix/critical-error
). This makes it easy for everyone to understand the purpose of each branch.main
, the more changes accumulate, and the harder (and more painful!) merges can become. Merge often!git status
<<<<<<< HEAD
This is the content from my current branch (HEAD).
=======
This is the content from the branch I'm merging.
>>>>>>> feature/my-feature
* `<<<<<<< HEAD`: Marks the beginning of the changes from your current branch.
* `=======`: Separates your changes from the incoming changes.
* `>>>>>>> feature/my-feature`: Marks the end of the incoming changes from the other branch.
git add conflicted_file.txt
git commit -m "Merge branch 'feature/my-feature' into main (resolved conflicts)"
origin
, which usually points to the GitHub repository you cloned or linked.
git remote add origin https://github.com/your-username/your-repo.git # Link your local repo to GitHub
git remote -v # See which remotes you have linked
git push origin main # Push your local 'main' branch to the 'origin' remote
git fetch origin # Fetch all new commits from GitHub's 'origin'
git pull origin main # Pull changes from 'origin/main' into your current branch
It's good practice to git pull
before starting work each day to ensure you have the latest code.
README.md
file. This is the first thing people see when they visit your GitHub repository. It should explain what your project is, how to set it up, how to run it, and how others can contribute.LICENSE
file. This file tells others how they are allowed to use, modify, and distribute your code. It's important for protecting your work and for open-source collaboration.branch protection rules
on critical branches (like main
or develop
). These rules can require things like code reviews or automated tests to pass before new code can be added, ensuring high quality.draft PRs
(sometimes called "Work In Progress" or "WIP" PRs). This is a great way to open a PR even if your work isn't finished. It signals to your team that you're working on something and allows for early feedback, without implying it's ready for final review and merge.