Complete guide to Git & SCM • Step-by-step instructions
Version control (also known as source control or revision control) is a system that manages changes to files over time. It tracks modifications, maintains history, and allows multiple people to collaborate on the same project without conflicts. Version control systems record snapshots of files, enabling developers to understand what changed, when, and who made the changes. Modern version control systems support branching and merging, allowing parallel development of features.
Key principles of version control:
Version control is essential for any software development project, from individual work to large teams.
Version control is a system that manages changes to files over time. It tracks modifications, maintains history, and allows multiple people to collaborate on the same project without conflicts. Version control systems record snapshots of files, enabling developers to understand what changed, when, and who made the changes. Modern version control systems support branching and merging, allowing parallel development of features. This is essential for software development, documentation management, and any project involving multiple contributors.
Version control follows a snapshot-based model:
Where:
Leading version control systems with their characteristics:
Repository, commit, branch, merge, diff, stash, pull request, merge conflict, distributed vs centralized.
VC Success = (Collaboration × History Accuracy × Recovery Capability) / (Complexity + Conflict Rate)
Where Collaboration = Team coordination effectiveness, History Accuracy = Complete change tracking, Recovery Capability = Rollback functionality.
Software development, documentation management, configuration management, content management, collaborative writing.
What does the "git add" command do?
The "git add" command stages changes from the working directory to the staging area (index). This prepares the changes to be committed in the next "git commit" command. The staging area acts as a buffer between the working directory and the repository, allowing you to selectively choose which changes to include in the next commit.
The answer is B) Stages changes for commit.
Git's three-area model (working directory, staging area, repository) is fundamental to understanding version control. The staging area allows for atomic commits by letting you group related changes together. This model provides flexibility in how changes are grouped and recorded, unlike centralized systems that commit directly to the repository.
Working Directory: Files you're currently editing
Staging Area: Changes prepared for commit
Repository: Committed snapshots of project
• Review changes before staging
• Use git status frequently
• Stage related changes together
• Use git add -p for partial file staging
• Use git diff to preview changes
• Use .gitignore for unwanted files
• Forgetting to stage changes before committing
• Staging unrelated changes together
• Accidentally adding sensitive files
Explain the Git Flow branching model and when it's appropriate to use.
Git Flow Components: Master branch for production releases, Develop branch for integration, Feature branches for development, Release branches for preparation, Hotfix branches for urgent fixes.
Workflow: Feature branches created from Develop, merged back to Develop after completion. When ready, Release branch created from Develop, tested, then merged to Master and Develop. Hotfix branches created from Master for urgent fixes.
When to Use: Suitable for projects with scheduled releases, multiple parallel developments, and clear separation between development and production. Not ideal for continuous deployment or very small teams.
This model provides structure for complex development processes.
Branching strategies provide conventions for managing code evolution. Git Flow formalizes the branching process with specific branch types and merge patterns. The model prevents direct commits to master and provides clear paths for feature development, release preparation, and hotfixes. Alternative strategies like GitHub Flow or Trunk-Based Development may be more suitable for different project types.
Master Branch: Production-ready code
Develop Branch: Integration branch
Feature Branch: Individual feature development
• Never commit directly to master
• Merge with proper PR/Review
• Keep feature branches short-lived
• Use branch naming conventions
• Delete feature branches after merging
• Use automated testing on PRs
• Long-running feature branches
Two developers made changes to the same function in a codebase, and when one tried to push their changes, they received a merge conflict. Explain the cause and resolution process.
Cause: Both developers modified the same lines of code in the same file, creating conflicting changes that Git cannot automatically resolve.
Resolution Process: 1) Pull latest changes from remote, 2) Git will mark conflict areas in the file, 3) Manually edit the conflicted sections to incorporate both changes, 4) Stage the resolved file, 5) Commit the merge, 6) Push the resolved changes.
Prevention: Regular communication between developers, frequent pulls, feature branching, and code reviews can minimize conflicts.
Understanding conflict resolution is crucial for collaborative development.
Merge conflicts occur when Git cannot automatically determine how to combine changes. The conflict markers (<<<<<<<, =======, >>>>>>>) indicate the different versions that need to be reconciled. Conflict resolution requires understanding both sets of changes and creating a combined version that incorporates the intent of both. Prevention strategies include good communication and development practices.
Conflict Markers: <<<<<<<, =======, >>>>>>>
Three-Way Merge: Comparing base, ours, and theirs
Rebasing: Rewriting history to incorporate changes
• Always pull before pushing
• Communicate about shared files
• Test after resolving conflicts
• Use merge tools for complex conflicts
• Keep changes small and focused
• Use feature flags to isolate changes
• Not understanding the conflict context
• Losing one developer's changes
• Not testing after resolution
A developer accidentally committed and pushed a change that broke the main application. How can version control be used to recover from this situation?
Immediate Actions: 1) Identify the problematic commit using git log, 2) Create a backup branch from current state, 3) Revert the bad commit using "git revert", 4) Push the fix to master.
Alternative Approaches: Use "git reset --hard" to go back to a good state (if no one else has pulled), or create a hotfix branch to implement the correction.
Recovery Options: Soft reset (preserve changes), mixed reset (preserve files), hard reset (discard everything).
Prevention: Implement CI/CD with automated testing, require code reviews, and use feature flags for risky changes.
Version control provides multiple recovery strategies for different scenarios.
Version control's primary benefit is the ability to recover from mistakes. The "git revert" command creates a new commit that undoes the changes, preserving history. The "git reset" command rewrites history and should be used cautiously. The choice of recovery method depends on whether others have already pulled the changes and the urgency of the fix.
Revert: Creates inverse commit, preserves history
Reset: Rewrites history, removes commits
Soft Reset: Moves HEAD but preserves changes
• Always backup before resetting
• Use revert for shared branches
• Avoid force pushing when possible
• Use git reflog to find lost commits
• Implement pre-commit hooks
• Use protected branches
• Force pushing without coordination
• Not backing up before major resets
• Ignoring the impact on other developers
Which of the following is the most important security practice when using version control?
Never committing sensitive data (passwords, API keys, private keys) is the most critical security practice. Once sensitive information is committed to a repository, it remains in the history even if deleted in later commits. This can lead to credential exposure and security breaches. Using .gitignore and environment variables for sensitive data is essential.
The answer is B) Never committing sensitive data.
Version control history is persistent and can be accessed even after removal. Security breaches from committed credentials are common and can have severe consequences. Prevention is easier than remediation - use environment variables, secret management tools, and pre-commit hooks to prevent sensitive data from entering the repository.
Git History: Persistent record of all changes
Pre-commit Hook: Script run before each commit
Secret Management: Secure storage of credentials
• Never commit secrets to repository
• Use .gitignore for sensitive files
• Implement security scanning
• Use tools like GitGuardian or Snyk
• Implement pre-commit hooks
• Use secret management services
• Committing API keys or passwords
• Not using .gitignore properly
• Exposing environment files
Q: What's the difference between Git and GitHub?
A: Git is a distributed version control system that runs locally on your computer, while GitHub is a web-based hosting platform for Git repositories. Git provides the core functionality (tracking changes, branching, merging), while GitHub provides additional features like collaboration tools, issue tracking, pull requests, and web interface. You can use Git without GitHub (local repositories or other hosting), but GitHub requires Git for version control functionality.
Q: How much does it cost to implement version control for a team?
A: Git itself is free and open source. For hosting: GitHub Free (up to 3 collaborators), GitHub Pro (~$4/month), GitHub Enterprise (~$21/month). GitLab offers free tier with unlimited private repos. Self-hosted solutions like GitLab CE or Gitea are free but require infrastructure. Total cost depends on team size and features needed. For small teams, free tiers often suffice. For enterprise, expect $10-50 per user per month for hosted solutions.
Q: How do I handle merge conflicts in a large team?
A: For large teams: 1) Implement feature branching to isolate work, 2) Use small, frequent commits to reduce conflict scope, 3) Establish code review processes, 4) Use automated testing to verify merges, 5) Communicate about shared components, 6) Consider trunk-based development for simpler merges. Use merge tools like VS Code's merge editor or command-line tools like git mergetool. Establish team conventions for conflict resolution.