Codinative

Git & GitHub

Every piece of code at Codinative lives in Git and is shared through GitHub. You don't need to be an expert - just comfortable enough to work day to day. This is the practical minimum to get there.

What they are

Git is a version-control system: it records snapshots of your project over time so you can review history, undo mistakes, and work on features in isolation. GitHub hosts Git repositories online and adds collaboration on top - pull requests, code review, and issues. In short: Git is the tool on your machine; GitHub is where the team’s code lives and gets reviewed.

One-time setup

Install Git, then tell it who you are (this stamps your commits):

git --version                       # check it's installed
git config --global user.name  "Your Name"
git config --global user.email "you@codinative.com"

Get a repo onto your machine by cloning it from GitHub:

git clone https://github.com/Codinative/<repo>.git

The everyday flow

Ninety percent of Git is one loop: edit files, stage what you want to keep, commit it as a snapshot, and push it to GitHub. Changes move through four places:

Working directory

your edited files

Staging area

git add

Local repo

git commit

GitHub

git push

How a change travels from your editor to GitHub
git status                    # what has changed?
git add index.html            # stage one file
git add .                     # stage everything changed
git commit -m "Fix header spacing on mobile"
git push                      # send your commits to GitHub
git pull                      # get teammates' commits
Commit small and often, with clear messages. A commit should be one logical change; the message should say what it does (e.g. Add sticky add-to-cart to product page), not “update”.

Branches & merging

A branch is an isolated line of work. You never build directly on main - you branch off, do your work, then merge it back once it’s reviewed. This keeps main stable and lets several people work at once.

git switch -c feat/sticky-atc     # create + switch to a new branch
# ...edit, add, commit as usual...
git push -u origin feat/sticky-atc  # publish the branch to GitHub

git switch main                   # switch back to main
git merge feat/sticky-atc         # merge the branch into main (locally)

In practice you rarely merge locally. Instead you push the branch and open a Pull Request (PR) on GitHub - a place for teammates to review the change and discuss it before it’s merged into main.

Name branches by intent: feat/… for features, fix/… for bug fixes, chore/… for maintenance.

Resolving conflicts

A merge conflict happens when two branches change the same lines and Git can’t decide which to keep. It pauses and marks the spot in the file:

<<<<<<< HEAD
color: red;        // the change already on your branch
=======
color: blue;       // the incoming change
>>>>>>> feat/new-theme
  1. Open each marked file and edit it to the correct final result.
  2. Delete the <<<<<<<, =======, and >>>>>>> marker lines.
  3. Stage the resolved files and finish: git add . then git commit (or git merge --continue / git rebase --continue).
Most editors (VS Code) show conflicts with “Accept Current / Incoming / Both” buttons - use those rather than editing markers by hand.

Stashing & rebasing

Stash shelves your uncommitted changes so you can switch tasks with a clean working directory, then bring them back later:

git stash            # shelve your current changes
git switch main      # do something else
git stash pop        # reapply the shelved changes

Rebase replays your branch’s commits on top of the latest main, giving a clean, linear history. It’s the tidy way to update a feature branch:

git switch feat/sticky-atc
git pull --rebase origin main    # replay your work on top of the latest main
Only rebase branches that are yours and not yet shared. Never rebase or force-push a branch other people are working on, and don’t rewrite main - on shared branches, prefer a normal merge.

How we use it here

TODO (Codinative): document our workflow - branch naming, who reviews PRs, the merge strategy (squash / merge / rebase), and any protected branches - so new devs match the team’s conventions.

Learn Git & GitHub

Pick the hands-on course to build the habit, and keep the reference docs handy; you’ll learn the rest by doing.