What you will achieve

You will keep a fork of an open-source repository up to date with its upstream, sync your branches cleanly, and avoid the common pitfall of letting your fork drift weeks behind.

Step 1: confirm the remote setup

git remote -v

You want two remotes: origin for your fork and upstream for the source.

What you will achieve

You will install Git LFS, configure it for a project that includes images, video, and design files, migrate any existing binaries already in history, and verify everything works for collaborators.

Step 1: install Git LFS

# macOS
brew install git-lfs

# Debian/Ubuntu
sudo apt install git-lfs

# Verify
git lfs version

Activate per user (run once):

What you will achieve

You will convert an SVN repository to Git, preserving authors, dates, branches, and tags, and push the result to a Git host. The conversion typically takes 30 minutes for medium repositories and a few hours for large ones.

Step 1: prepare

Audit the SVN repo:

svn info https://svn.example.com/repo
svn ls https://svn.example.com/repo
# Confirm: trunk, branches, tags layout?

Step 2: build authors mapping

SVN authors are usernames; Git wants Name <email>:

What you will achieve

You will configure pre-commit and pre-push hooks that lint, format, type-check, and test your code, sharing the configuration across your team via the repo. By the end, broken code will not even reach your remote.

Choose a framework

Three popular options:

What you will achieve

You will take a feature branch with messy work-in-progress commits ("wip", "more wip", "fix lint", "address feedback") and rewrite it into a clean, atomic commit series ready for review.

What you will achieve

You will use git bisect with an automated test script to identify the exact commit that introduced a regression. The technique scales from "the bug appeared sometime this month" to thousand-commit windows in minutes.

What you will achieve

You will configure a shared Git repository with branch protection, a clean default workflow, hooks for code quality, and CI integration. The result is a repo that scales from 3 to 50 contributors without rewrites.

Step 1: create the repository

On GitHub, GitLab, or Bitbucket, create a new repository. Initialise with a README and a .gitignore. Pick a licence if applicable.

What you will achieve

You will take a feature branch that has fallen behind main, rebase it cleanly onto the new tip, resolve any conflicts that arise, and push the rebased branch back to your remote. By the end, you will be comfortable with the most common rebase scenario.

What you will achieve

You will create a merge conflict deliberately, walk through the resolution, and learn the tools and patterns that make conflicts non-scary. Conflicts are not errors; they are Git asking you a question.

What you will achieve

By the end of this tutorial you will have forked an open-source repository, made a small change on a feature branch, opened a pull request, responded to feedback, and seen your work merged. The pattern works for any GitHub-hosted project; GitLab and Bitbucket are nearly identical.