Skip to content

Version Control

To ensure smooth collaboration and avoid issues in our version control process for the NepWalk frontend team, we use Git with GitHub, merging into a TEST branch instead of main for initial testing before production. Below are the first four steps of our standard approach, tailored to this workflow, written in a concise and human-friendly tone.

1. Set Up a Clear Git Workflow

We use a simplified GitHub Flow with a TEST branch for pre-production validation:

Main Branch: Production-ready, stable code.

TEST Branch: Staging area for testing features before merging to main.

Feature Branches: Created for each task (e.g., feature/search-bar).

Steps:

  1. Create a feature branch from main (e.g., git checkout -b feature/search-bar).
  2. Develop and commit changes.
  3. Push to GitHub (git push origin feature/search-bar).
  4. Open a Pull Request (PR) to merge into TEST for review and testing.
  5. After passing tests in TEST, merge into main via another PR.
  6. Why: Merging into TEST first ensures features are validated in a staging environment, reducing risks to main.

2. Use Meaningful Commit Messages

We write clear commit messages to track changes easily:

Format: [Type]: Description (e.g., feat: add search bar UI [NPW-456], fix: adjust search input alignment).

Types: feat (new feature), fix (bug fix), docs (docs), style (formatting), test (tests), chore (maintenance).

Tip: Keep messages short (50-72 characters) and include ticket numbers (e.g., NPW-456) for traceability.

3. Branch Naming Conventions

We use consistent branch names for clarity:

Feature: feature/<description> (e.g., feature/search-bar).

Bug Fix: fix/<description> (e.g., fix/search-error).

Hotfix: hotfix/<description> (e.g., hotfix/search-crash).

Why: Clear naming helps us quickly understand each branch’s purpose.

4. Pull Requests and Code Reviews

We use PRs to merge feature branches into TEST:

  • Open a PR to TEST, describing changes and linking to tickets (e.g., NPW-456).
  • Request reviews from at least one teammate to ensure quality.
  • Use GitHub’s review tools for feedback and suggestions.
  • Ensure PRs pass Continuous Integration (CI) checks (e.g., ESLint, Jest) before merging to TEST.
  • After testing in TEST (e.g., QA validation), create a follow-up PR from TEST to main.
  • Tip: Respond to review feedback quickly and discuss changes openly to resolve issues.

Tips to Avoid Problems

  • Pull from main Regularly: Run git pull origin main in your feature branch to stay updated and avoid conflicts.
  • Test Before Merging to TEST: Run local tests to catch issues early.
  • Communicate: Share what you’re working on in stand-ups or Slack to avoid overlapping changes.
  • Small Commits: Keep changes focused to simplify reviews and reduce conflicts.

Example Workflow

  1. Create branch: git checkout -b feature/add-search-bar.
  2. Commit: git commit -m "feat: add search bar UI [NPW-456]".
  3. Push: git push origin feature/add-search-bar.
  4. Open a PR to TEST, get reviews, pass CI, and merge after QA validation.

Here’s a concise naming convention for the NepWalk frontend project using Next.js, App Router, and TypeScript, tailored to our feature-based folder structure. This keeps our codebase consistent, readable, and portable, especially when tracking external components or shifting features to another project.