Light

2.2 Git fundamentals and best practices

9 min read•august 14, 2024

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 , following branching conventions, and maintaining a stable main . These practices, along with effective collaboration techniques and 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 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., , ) 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 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 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 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

Key Terms to Review (20)

Branch: In version control systems like Git, a branch is essentially a pointer to a specific commit, allowing for the development of features or fixes in isolation from the main codebase. This capability enables multiple developers to work simultaneously on different tasks without interfering with each other's progress, facilitating parallel development and easier management of changes. Branching also simplifies the process of merging these changes back into the main project when they are ready.

Clone: In the context of version control systems, a clone refers to creating a complete copy of a repository, including all its history and branches. This allows users to work on their local copy of the codebase independently, while still being able to synchronize changes with the original repository. Cloning is a fundamental feature of Git and other VCS, enabling collaboration and version tracking among multiple developers.

Code review: Code review is a systematic examination of source code intended to identify mistakes and improve the overall quality of the code. It fosters collaboration among developers, enhances code reliability, and helps in maintaining coding standards. This practice is essential within version control systems, as it allows multiple contributors to examine changes, provides opportunities for learning and knowledge sharing, and reduces the risk of introducing bugs into the codebase.

Commit: A commit is a fundamental concept in version control systems, representing a snapshot of changes made to the codebase at a specific point in time. It allows developers to record modifications, including additions, deletions, and edits, along with a message that describes the purpose of those changes. This creates a historical record that facilitates tracking, reverting, and collaborating on software development projects.

Commit messages: Commit messages are concise descriptions that accompany changes made in a version control system, like Git. They serve to document what changes were made, why they were made, and help in tracking the evolution of a project over time. Clear and informative commit messages are crucial for collaboration, allowing team members to understand the history of modifications and the rationale behind them.

Conflict Resolution: Conflict resolution refers to the methods and processes aimed at facilitating the peaceful ending of conflicts and disputes. In the context of version control systems, especially when collaborating on code, it becomes essential to resolve discrepancies between different versions or branches. By effectively managing these conflicts, teams can ensure a smoother workflow, maintain code integrity, and promote collaboration among developers working on shared projects.

Feature Branching: Feature branching is a version control practice where individual features or tasks are developed in separate branches of a repository, isolating work until it's ready to be merged into the main codebase. This approach helps manage multiple features in parallel without interfering with each other, facilitating cleaner and more organized development workflows. It also enhances collaboration by allowing team members to work on different features simultaneously without disrupting each other’s progress.

Git flow: Git flow is a branching model for Git that helps manage feature development, releases, and hotfixes in a structured way. It provides a clear process for developers to follow, allowing for parallel development and easier collaboration among team members. By using specific branches for different purposes, such as 'feature,' 'develop,' 'release,' and 'hotfix,' git flow ensures that code changes are organized, reducing the risk of conflicts and making it easier to track progress.

GitHub: GitHub is a web-based platform that uses Git for version control and facilitates collaborative software development. It provides tools for managing repositories, tracking changes, and fostering teamwork among developers, making it a vital resource in modern software development practices.

GitLab: GitLab is a web-based DevOps lifecycle tool that provides a Git repository manager, enabling teams to collaborate on code development, automate workflows, and enhance software delivery. It integrates version control with continuous integration/continuous deployment (CI/CD) capabilities, making it a powerful platform for managing the entire software development lifecycle while emphasizing collaboration and efficiency.

History: In the context of Git, history refers to the chronological record of changes made to a repository, including commits, branches, merges, and tags. This record is essential for tracking the evolution of a project, allowing developers to understand how code has changed over time and to identify when specific changes were introduced. Understanding history enables effective collaboration and debugging, as it provides insights into past decisions and the rationale behind them.

Log: In the context of version control systems like Git, a log is a record of all the changes made to a repository. It provides a detailed history of commits, including information about each change, such as the author, date, and a description of the modifications. The log is crucial for tracking progress, understanding project evolution, and facilitating collaboration among team members.

Merge: In version control systems, a merge is the process of integrating changes from one branch into another. This operation combines the development histories of both branches, allowing developers to consolidate their work and collaborate effectively. Merging can introduce new changes, resolve conflicts, and ensure that the codebase remains up-to-date with the latest contributions from all team members.

Pull Request: A pull request is a method used in version control systems, particularly in Git, to propose changes to a codebase and initiate discussions about those changes before merging them into the main branch. It serves as a collaborative tool that allows developers to review each other's work, provide feedback, and ensure code quality, thereby fostering teamwork and improving the overall integrity of the project.

Push: In version control systems, 'push' refers to the action of uploading local changes to a remote repository. This operation is crucial for collaboration among developers, as it ensures that updates made in a local environment are shared with others, keeping the remote repository synchronized with the latest code. It typically involves sending commits that represent changes made locally to files, branches, or the overall project, which can then be accessed by others working on the same project.

Rebase: Rebase is a Git command that allows you to move or combine a sequence of commits to a new base commit, essentially changing the commit history. This technique helps keep a cleaner project history by integrating changes from one branch into another, allowing for linear project history and reducing merge conflicts. By rebasing, developers can streamline their workflows and ensure their changes are built on the latest codebase before merging.

Repository: A repository is a central location where data, files, and code are stored, managed, and tracked. It serves as a crucial component in version control systems, enabling users to save different versions of their work, collaborate effectively, and maintain the integrity of their projects. Repositories provide features like branching, merging, and history tracking, which are essential for effective collaboration and code management.

Squash commits: Squash commits is a Git feature that allows developers to combine multiple commit entries into a single, cohesive commit. This practice helps in maintaining a clean project history by reducing clutter and making it easier to understand the evolution of the codebase. By squashing commits, developers can present their changes in a more organized manner, which is particularly useful before merging branches into the main codebase.

Trunk-based development: Trunk-based development is a software development practice where all developers work in a single branch, called the trunk, instead of using multiple long-lived branches. This approach encourages frequent integration of code changes, minimizing merge conflicts and ensuring that the codebase remains in a deployable state. By focusing on short-lived feature branches that are merged back into the trunk quickly, teams can maintain a continuous flow of updates and foster collaboration among developers.

Versioning: Versioning is the process of assigning unique identifiers to different iterations of a product or codebase, enabling developers to track changes, maintain control over releases, and facilitate collaboration. It plays a crucial role in managing the lifecycle of software development, ensuring that updates and modifications are systematic and organized. Through effective versioning, teams can communicate about changes, revert to previous states if necessary, and manage dependencies across projects.

AP® and SAT® are trademarks registered by the College Board, which is not affiliated with, and does not endorse this website.

Back

Practice QuizGlossary

Practice Quiz Glossary

2.2 Git fundamentals and best practices

Git Setup and Configuration

Installing Git

Top images from around the web for Installing Git

Top images from around the web for Installing Git

Configuring Git Settings

Setting Up SSH Keys

Git Repository Management

Creating and Initializing Repositories

Understanding Repository Structure

Interacting with Remote Repositories

Basic Git Operations

Staging and Committing Changes

Pushing and Pulling Changes

Viewing Repository History

Git Branching and Merging

Creating and Managing Branches

Switching Between Branches

Merging Branches

Resolving Merge Conflicts

Git Best Practices

Writing Effective Commit Messages

Following Branching Conventions

Keeping the Main Branch Stable

Collaborating with Others

Organizing Repositories

Key Terms to Review (20)

© 2024 Fiveable Inc. All rights reserved.

AP® and SAT® are trademarks registered by the College Board, which is not affiliated with, and does not endorse this website.

Back

Next guide