2.2 Git fundamentals and best practices

Git fundamentals and best practices are essential for effective version control. This section covers everything from setting up Git and managing repositories to performing basic operations like staging, committing, and pushing changes. It also dives into branching, merging, and resolving conflicts.

The best practices outlined here emphasize clear communication through commit messages, following branching conventions, and maintaining a stable main branch. These practices, along with effective collaboration techniques and repository organization, form the backbone of successful Git usage in development projects.

Git Setup and Configuration

Installing Git

Top images from around the web for Installing Git

• 

  How to install Git on Linux View original

  Is this image relevant?

• 

  Edward Thomson: Git Credential Manager with Windows Subsystem for Linux View original

  Is this image relevant?

• 

  Installing Git — Dev documentation View original

  Is this image relevant?

• 

  How to install Git on Linux View original

  Is this image relevant?

• 

  Edward Thomson: Git Credential Manager with Windows Subsystem for Linux View original

  Is this image relevant?

1 of 3

Top images from around the web for Installing Git

• 

  How to install Git on Linux View original

  Is this image relevant?

• 

  Edward Thomson: Git Credential Manager with Windows Subsystem for Linux View original

  Is this image relevant?

• 

  Installing Git — Dev documentation View original

  Is this image relevant?

• 

  How to install Git on Linux View original

  Is this image relevant?

• 

  Edward Thomson: Git Credential Manager with Windows Subsystem for Linux View original

  Is this image relevant?

1 of 3

• Git is a distributed version control system that allows tracking changes in files and coordinating work among multiple people
• Git can be installed on various operating systems, including Windows, macOS, and Linux, using platform-specific installers or package managers
• For Windows, Git can be installed using the official Git for Windows installer, which provides a command-line interface and optional GUI tools
• On macOS, Git can be installed using the Xcode Command Line Tools or via package managers like Homebrew (

  brew install git

  )
• Linux users can install Git using their distribution's package manager (e.g.,

  apt-get install git

  on Debian-based systems or

  yum install git

  on Red Hat-based systems)

Configuring Git Settings

• Configuring Git involves setting user information (name and email) and preferred text editor or merge tool, which can be done using the

  git config

  command
• User information is set using

  git config --global user.name "Your Name"

  and

  git config --global user.email "your@email.com"

• The preferred text editor can be set using

  git config --global core.editor "editor-name"

  (e.g.,

  vim

  ,

  nano

  ,

  code

  for Visual Studio Code)
• Other configuration options include setting aliases for frequently used commands, enabling color output, and configuring line endings
• Configuration settings can be stored at different levels: system-wide (

  --system

  ), user-level (

  --global

  ), or repository-specific (no flag)

Setting Up SSH Keys

• SSH keys can be generated and added to Git hosting platforms (e.g., GitHub, GitLab) for secure authentication when interacting with remote repositories
• Generating an SSH key pair involves running

  ssh-keygen -t rsa -b 4096 -C "your@email.com"

  , which creates a private key and a public key
• The public key (usually named

  id_rsa.pub

  ) should be added to the Git hosting platform's SSH key settings, while the private key remains on the local machine
• Using SSH keys allows for secure, password-less authentication when pushing or pulling changes to/from remote repositories

Git Repository Management

Creating and Initializing Repositories

• A Git repository is a virtual storage of a project, which can be initialized locally using the

  git init

  command or cloned from a remote repository using

  git [clone](https://www.fiveableKeyTerm:Clone)

• Initializing a new repository in an existing directory is done by navigating to the directory and running

  git init

  , which creates a hidden

  .git

  directory containing the repository's metadata
• Cloning an existing remote repository is done using

  git clone <repository-url>

  , which creates a new directory with the repository's name and copies the entire commit history and files

Understanding Repository Structure

• Local repositories consist of three main components: the working directory, staging area (index), and commit history
• The working directory is where the actual files and directories of the project reside, and changes are made to these files during development
• The staging area (also known as the index) is an intermediate area where changes are prepared before being committed to the repository's history
• The commit history is a chronological record of all the commits made in the repository, each containing a snapshot of the project's state at a particular point in time

Interacting with Remote Repositories

• Remote repositories, hosted on platforms like GitHub or GitLab, enable collaboration and serve as a central point for sharing and managing project code
• The

  git remote

  command is used to manage connections to remote repositories, allowing developers to add, remove, or modify remote URLs
• Adding a new remote is done using

  git remote add <name> <url>

  , where

  <name>

  is a shorthand name for the remote (e.g.,

  origin

  ) and

  <url>

  is the remote repository's URL
• Fetching changes from a remote repository is done using

  git fetch <remote>

  , which downloads the latest changes without merging them into the local branch
• Pulling changes from a remote repository is done using

  git pull <remote> <branch>

  , which fetches the latest changes and merges them into the specified local branch

Basic Git Operations

Staging and Committing Changes

• Staging changes using

  git add

  moves modified files from the working directory to the staging area, preparing them for committing
• Files can be staged individually using

  git add <file>

  or all modified files can be staged at once using

  git add .

• Committing changes using

  git commit

  records a snapshot of the staged changes in the local repository's commit history, along with a commit message describing the changes
• A commit message is provided using the

  -m

  flag, as in

  git commit -m "Commit message here"

• The

  git status

  command provides an overview of the current state of the repository, showing modified, staged, and untracked files

Pushing and Pulling Changes

• Pushing changes using

  git [push](https://www.fiveableKeyTerm:push)

  uploads the committed changes from the local repository to a remote repository, making them available to other collaborators
• The basic syntax for pushing changes is

  git push <remote> <branch>

  , where

  <remote>

  is the name of the remote repository (e.g.,

  origin

  ) and

  <branch>

  is the name of the branch being pushed
• Pulling changes using

  git pull

  fetches the latest changes from a remote repository and merges them into the current branch of the local repository
• The syntax for pulling changes is similar to pushing:

  git pull <remote> <branch>

• Before pushing or pulling changes, it's important to ensure that the local repository is in sync with the remote repository to avoid conflicts

Viewing Repository History

• The

  git [log](https://www.fiveableKeyTerm:Log)

  command is used to view the commit history of a repository, displaying information such as the commit hash, author, date, and commit message
• By default,

  git log

  displays the commits in reverse chronological order, with the most recent commit appearing first
• Various flags can be used with

  git log

  to customize the output, such as

  --oneline

  for a condensed view,

  --graph

  for a visual representation of the branch structure, and

  --decorate

  for showing branch and tag names
• The

  git show <commit>

  command can be used to view the details of a specific commit, including the changes made in that commit

Git Branching and Merging

Creating and Managing Branches

• Git branches are lightweight, movable pointers to commits that allow developers to work on different features or bug fixes independently without affecting the main codebase
• The

  git branch

  command is used to create, list, rename, and delete branches
• Creating a new branch is done using

  git branch <branch-name>

  , where

  <branch-name>

  is the desired name for the new branch
• Listing existing branches is done using

  git branch

  or

  git branch --list

  , which displays all local branches and highlights the current branch with an asterisk
• Renaming a branch is done using

  git branch -m <old-name> <new-name>

  , while deleting a branch is done using

  git branch -d <branch-name>

Switching Between Branches

• Switching between branches is done using the

  git checkout

  command, which updates the working directory to match the selected branch
• To switch to an existing branch, use

  git checkout <branch-name>

  , where

  <branch-name>

  is the name of the branch you want to switch to
• To create a new branch and switch to it in a single command, use

  git checkout -b <branch-name>

  , which creates the new branch and immediately switches to it
• When switching branches, it's important to ensure that any uncommitted changes are either committed, stashed, or discarded to avoid conflicts

Merging Branches

• Merging is the process of integrating changes from one branch into another, which can be done using the

  git merge

  command
• To merge changes from a source branch into the current branch, use

  git merge <source-branch>

  , where

  <source-branch>

  is the name of the branch containing the changes to be merged
• Fast-forward merges occur when there is a linear history between the branches, and the current branch pointer is simply moved forward to the latest commit of the source branch
• Three-way merges create a new merge commit when divergent changes need to be combined, preserving the history of both branches
• Merge conflicts arise when conflicting changes are made to the same file in different branches, requiring manual resolution by the developer before completing the merge

Resolving Merge Conflicts

• When a merge conflict occurs, Git marks the conflicting changes in the affected files using conflict markers (

  <<<<<<<

  ,

  =======

  , and

  >>>>>>>

  )
• To resolve a merge conflict, open the conflicting file(s) in a text editor and manually edit the code to decide which changes to keep or how to combine the conflicting changes
• After resolving the conflicts, stage the modified files using

  git add

  and create a new commit to complete the merge using

  git commit

• Tools like

  git mergetool

  can be used to launch a graphical merge conflict resolution tool, which can help visualize and resolve conflicts more easily

Git Best Practices

Writing Effective Commit Messages

• Writing clear, concise, and descriptive commit messages helps other developers understand the purpose and context of the changes made in each commit
• A good commit message should be short (ideally 50 characters or less) and provide a summary of the changes in the imperative mood (e.g., "Add feature X" instead of "Added feature X")
• If more detail is needed, a blank line can be added after the summary, followed by a more detailed description of the changes, wrapped at 72 characters per line
• Including relevant issue numbers, bug report IDs, or feature request references in commit messages can help provide additional context and improve traceability

Following Branching Conventions

• Adopting branching conventions, such as using feature branches for new features, hotfix branches for critical bug fixes, and release branches for preparing stable releases, helps maintain a clean and organized repository structure
• A common branching model is the Gitflow workflow, which defines a strict branching model with long-running branches (e.g.,

  main

  and

  develop

  ) and short-lived branches for features (

  feature/

  ), releases (

  release/

  ), and hotfixes (

  hotfix/

  )
• Other popular branching models include the GitHub Flow, which emphasizes a simpler approach with a single

  main

  branch and short-lived feature branches, and the GitLab Flow, which introduces environment branches (e.g.,

  production

  ,

  staging

  ) for deployment
• Regardless of the chosen branching model, it's important to document and consistently follow the conventions within the team or organization to ensure a clean and maintainable repository

Keeping the Main Branch Stable

• Keeping the main (or master) branch stable and production-ready by enforcing code reviews and merging only thoroughly tested changes is a common best practice
• Before merging changes into the main branch, it's important to ensure that the changes have been reviewed by other team members, pass all relevant tests, and meet the project's quality standards
• Continuous Integration (CI) and Continuous Deployment (CD) pipelines can be set up to automatically build, test, and deploy changes from feature branches or pull requests, providing an additional layer of quality control
• Protecting the main branch with branch protection rules, such as requiring pull request reviews or status checks before merging, can help enforce these best practices and maintain a stable codebase

Collaborating with Others

• Regularly pushing commits to remote repositories ensures that changes are backed up and allows for easier collaboration with other team members
• When collaborating on a project, it's important to communicate effectively with other team members, informing them about the changes being made and any potential conflicts or dependencies
• Using pull requests (or merge requests) to propose and discuss changes before merging them into the main branch is a common collaboration practice, allowing for code reviews, feedback, and ensuring that changes meet the project's standards
• Keeping feature branches short-lived and regularly merging them into the main branch helps minimize the risk of conflicts and divergence, making it easier to integrate changes and collaborate effectively

Organizing Repositories

• Using meaningful and descriptive names for branches, tags, and repositories helps maintain clarity and organization within the project
• Branches should be named according to their purpose, such as

  feature/user-authentication

  for a feature branch or

  hotfix/login-bug

  for a hotfix branch
• Tags should be used to mark specific points in the repository's history, such as releases or important milestones, using a consistent naming convention (e.g.,

  v1.0.0

  ,

  release-2021-03-15

  )
• Repositories should be organized in a logical manner, with a clear separation between different projects, components, or microservices, each having its own repository when appropriate
• Providing a clear and concise README file in each repository, outlining the project's purpose, setup instructions, and contribution guidelines, can help new team members or contributors quickly understand and navigate the codebase