Git: The Distributed Revolution
Git changed the paradigm by being a distributed system. Unlike SVN, when you work with Git, you typically clone a remote repository to your own machine. This means you have a full local repository on your computer.
Because you have a local copy, you can perform most operations—like committing changes—without being connected to a network or a central server. You only need to connect to the remote repository when you want to synchronize your work with others.
The Git Workflow and Staging Areas
One of Git's most unique features is the staging area. Instead of saving every change you make immediately, Git allows you to "mark" specific files that you want to include in your next commit. This gives you granular control over your history.
The standard workflow follows these steps:
- Initialize or Clone: Use
git init to create a new local project or git clone to copy an existing remote repository.
- Modify Files: Create or edit your code in your working directory.
- Stage Files: Use
git add <filename> to move changes into the staging area.
- Commit: Use
git commit to save those staged changes to your local repository.
- Push: Use
git push to send your local commits to the remote repository (like GitHub).
Branching and Merging
In professional software engineering, you rarely want to experiment directly on the "main" or "master" branch, as this is the version of the code that is assumed to be functional. Instead, you use branching.
Branching allows you to create a separate line of development (a "side branch") to work on new features or bug fixes without damaging the main code. Once your work is complete and tested, you perform a merge to integrate those changes back into the main branch.
Handling Remote Conflicts
When working in a team, you will inevitably encounter situations where someone else has pushed changes to the remote repository while you were working locally. If you try to git push, Git will reject your update to prevent overwriting their work. To resolve this, you must:
- Fetch: Use
git fetch to download the latest changes from the remote repository into your local repository.
- Merge: Use
git merge to combine those remote changes into your current local branch.
Pro Tip: The command git pull is actually a shortcut that performs a git fetch followed immediately by a git merge.
Using GitHub and Interfaces
While Git is the underlying engine, GitHub is a popular web-based platform used to host Git repositories. It provides a central location for teams to collaborate, manage permissions, and view code through a web interface.
You can interact with Git in several ways:
- Command-Line Interface (CLI): Using tools like "Git Bash" to type commands directly. This is the most powerful method.
- Graphical User Interface (GUI): Using applications like GitHub Desktop or Git GUI to click buttons instead of typing commands.
Essential Git Commands Reference
To manage your project effectively, you should become familiar with these common commands:
| Command | Purpose |
|---|
git init | Creates a new local repository in the current directory. |
git clone <url> | Copies a remote repository to your local machine. |
git status | Shows which files have changed and which are staged. |
git log | Displays the history of all commits in the repository. |
git add <file> | Adds a file to the staging area. |
git commit -m "msg" | Saves staged changes to the local repository with a message. |
git push origin main | Sends local commits to the remote "origin" on the "main" branch. |
git pull | Fetches and merges changes from the remote repository. |
Managing Ignored Files
Sometimes, you don't want certain files (like large libraries, temporary build files, or sensitive credentials) to be tracked by Git. For this, you use a .gitignore file. This is a plain-text file in your root directory that tells Git which files or patterns to ignore.
Warning: Do not include large third-party libraries (like Unity3D) in your repository. Instead, include a README file explaining how others can download them.
Summary of Best Practices
Git is most effective when different developers work on different files or separate branches. While it is excellent for code, it is not as well-suited for multiple people collaborating on a single text document (like a Word doc) simultaneously. For collaborative writing, manual methods like "Track Changes" in MS Word are often more appropriate.
