Daily Git Usage and Extensions

Common Git Commands and Workflows Introduction Git is a distributed version control system that allows you to track changes to your code, collaborate with others, and maintain a complete history of your project. This guide covers the essential commands and workflows you need to understand Git's fundamental operations. Core Commands Starting a Repository When you begin a new project with Git, you have two primary options. If you're starting from scratch, git init creates a new Git repository in your current directory. This initializes the necessary Git data structures and creates your first branch (typically named master or main). When working with an existing project, git clone <URL> downloads a complete copy of that repository. This includes all the project history, branches, and files, giving you a fully functional local copy to work with. The Commit Workflow Git's core workflow revolves around staging and committing changes. Think of this as a two-step process: Staging prepares your changes for commit using git add <file>. When you modify files, Git doesn't automatically track those changes—you explicitly tell Git which files you want to include in your next commit by adding them to the staging area. This gives you fine-grained control over what goes into each commit. Committing permanently records staged changes using git commit -m <message>. Your commit message should clearly describe what changed and why. The commit becomes part of your permanent project history. Managing Files to Ignore Not everything in your project directory should be tracked by Git. Configuration files, dependency folders, build outputs, and system files should be excluded. You specify what Git should ignore by creating a file named .gitignore in your repository root. This plain-text file uses patterns to match filenames and directories that Git should skip. For example, a .gitignore file might contain: nodemodules/ .log .env pycache/ This tells Git to ignore the nodemodules directory, all .log files, the .env file, and Python's pycache directory. Understanding Git Branches and Remote Repositories Default Branch Names When you initialize a repository with git init, Git creates an initial branch. Historically, this branch was named master, but the Git community has moved toward main as the default name. Many hosting services like GitHub now use main by default. Both names refer to the same concept—your primary development branch—so you'll encounter both in practice. Remote Repositories A remote is a reference to another Git repository, typically hosted on a server. When you clone a repository, Git automatically creates a remote named origin, which points back to the original repository you cloned from. This is a convention: "origin" is simply the standard name for the default upstream repository. Collaborative Workflows Pull Requests A pull request (also called a merge request on some platforms) is a formalized way to propose merging changes from one branch into another. Rather than directly merging branches yourself, you create a pull request that allows others to review your changes, discuss them, and approve the merge. This is enforced by hosting platforms like GitHub and GitLab—it's not a Git command itself, but rather a feature built on top of Git's branching system. Pull requests are essential for team development because they enable code review and prevent untested or problematic code from entering your main branches. Handling Committed Changes A key principle in Git workflow is: once you've pushed commits to a shared repository, you generally don't rewrite them. Instead, if you need to undo changes, you create a new commit that reverses the earlier changes. This preserves the historical record and prevents conflicts with other developers who may have based their work on the pushed commits. Branch Naming Conventions When working on a project with multiple developers, consistent branch naming helps everyone understand what each branch is for: Feature branches are typically prefixed with feature/ (for example, feature/user-authentication) and contain new functionality under development. The develop branch serves as the integration point for features being developed. It contains unstable, in-progress code and is shared among developers. The main branch (or master in older projects) holds only production-ready code. Releases come from this branch, ensuring that what users see is stable and tested. <extrainfo> Hotfix branches are used for emergency patches to released products. When a critical bug is discovered in production, a hotfix branch allows you to make and test the fix quickly while keeping the develop branch unaffected. </extrainfo> <extrainfo> Advanced Topics Renaming the Default Branch Existing repositories can change their default branch name using git branch -m master main followed by updating remote configuration. This is a useful administrative task when adopting the newer naming convention, though it doesn't affect Git's underlying data structures. However, teams using continuous-integration systems or automated deployment may need to update scripts and documentation accordingly. Git Extensions Git Large File Storage (Git LFS) is an extension for projects that need to version-control large files (such as videos, datasets, or binaries). Rather than storing these large files directly in your repository, Git LFS stores lightweight pointers to them while the actual files are kept outside the regular repository. This keeps your repository slim and fast. git-flow is another extension that provides high-level commands implementing a specific branching model (Vincent Driessen's model). Instead of manually managing branches, git-flow automates branch creation and merging following a standardized workflow. This is particularly useful for teams with formal release cycles. </extrainfo>