Folium LabsFolium Labs
ServicesPricingAboutBlogFAQ
ES/ENGet a quote
Folium LabsFolium Labs

Professional academic writing and technology development services for students in Honduras.

Services

  • Theses & Monographs
  • Software Development
  • Format Review
  • Data Analysis
  • All services

Company

  • About Us
  • Pricing
  • Blog
  • FAQ
  • Contact

Contact

  • contacto@folium-labs.com
  • WhatsApp
  • Honduras

2026 Folium Labs. All rights reserved.

PrivacyTerms
HomeBlogGit and GitHub guide for university students
Back to blog
softwaregittoolsengineering

Git and GitHub guide for university students

Folium Labs TeamMarch 31, 20266 min read
Git and GitHub guide for university students

If you are studying engineering or computer science in Honduras, you will use Git and GitHub in almost every software project. Yet many students reach their thesis without truly understanding version control. This guide covers the practical commands and workflows you actually need, without unnecessary theory.

What is Git and why should you care

Git is a version control system. It tracks every change you make to your code, lets you undo mistakes, and allows multiple people to work on the same project without overwriting each other's work.

Think of it as an unlimited undo history for your entire project, combined with a system that lets your teammates edit different files simultaneously and merge everything together.

What is GitHub

GitHub is a cloud platform that hosts Git repositories. It adds a web interface, collaboration tools, issue tracking, and project management features on top of Git. Your repository lives on GitHub's servers, so even if your laptop breaks, your code is safe.

Other alternatives exist (GitLab, Bitbucket), but GitHub is the industry standard and the platform most Honduran universities expect.

Setting up Git for the first time

Install Git from git-scm.com and configure your identity:

git config --global user.name "Your Name"
git config --global user.email "your.email@university.edu"

Create a free GitHub account at github.com and set up SSH keys for secure access. This avoids entering your password every time you push code.

The 10 commands you will use 90% of the time

1. git init

Creates a new Git repository in your current folder.

git init

2. git clone

Downloads an existing repository from GitHub to your machine.

git clone https://github.com/username/project-name.git

3. git status

Shows which files have changed since your last commit.

git status

4. git add

Stages files for your next commit. You are telling Git "include these changes."

git add filename.js        # stage one file
git add .                  # stage all changed files

5. git commit

Saves your staged changes with a descriptive message.

git commit -m "Add login form validation"

6. git push

Uploads your commits to GitHub.

git push origin main

7. git pull

Downloads the latest changes from GitHub and merges them into your local code.

git pull origin main

8. git branch

Creates or lists branches. Branches let you work on features independently.

git branch feature/login    # create a branch
git branch                  # list all branches

9. git checkout / git switch

Moves between branches.

git switch feature/login    # modern syntax
git checkout feature/login  # classic syntax (still works)

10. git merge

Combines changes from one branch into another.

git switch main
git merge feature/login

A practical workflow for team projects

This is the workflow that works for university teams of 2-5 people:

Step 1: One team member creates the repository on GitHub and adds everyone as collaborators.

Step 2: Each person clones the repository to their machine.

Step 3: Before starting any new feature, create a branch:

git switch -c feature/user-registration

Step 4: Write your code, commit frequently with clear messages:

git add .
git commit -m "Add user registration form with email validation"

Step 5: Push your branch to GitHub:

git push origin feature/user-registration

Step 6: On GitHub, create a Pull Request (PR) to merge your branch into main. Your teammates review the changes.

Step 7: After approval, merge the PR on GitHub. Everyone pulls the updated main branch.

This prevents the classic problem where four people edit the same file at the same time and lose each other's work.

Writing good commit messages

Your commit history tells the story of your project. Write messages that explain what changed and why:

Bad messages:

  • "fix"
  • "update"
  • "changes"
  • "asdf"

Good messages:

  • "Add password validation with minimum 8 characters"
  • "Fix database connection timeout on slow networks"
  • "Update dashboard layout to match wireframe v2"

A widely used convention is Conventional Commits:

feat: add user registration endpoint
fix: resolve null pointer in search results
docs: update installation guide for Windows
style: format code with Prettier

Handling merge conflicts

Merge conflicts happen when two people edit the same line in the same file. Git cannot decide which version to keep, so it asks you to resolve it manually.

When a conflict occurs, Git marks the file like this:

<<<<<<< HEAD
Your version of the code
=======
Your teammate's version of the code
>>>>>>> feature/other-branch

To resolve it: open the file, decide which version to keep (or combine both), remove the conflict markers, then commit the result.

Conflicts are normal. They are not errors. The more your team communicates about who is working on which files, the fewer conflicts you will encounter.

The .gitignore file

Not everything belongs in your repository. Create a .gitignore file to exclude:

node_modules/
.env
*.log
dist/
.DS_Store

Never commit node_modules (thousands of files your teammates can regenerate with npm install), .env files (contain passwords and API keys), or build output folders.

Common mistakes students make

Not committing frequently enough. Commit after each logical unit of work, not once at the end of the day. If something breaks, you can revert to a recent working state.

Committing directly to main. Always use branches. Even for small projects, branches protect the main branch from broken code.

Not pulling before pushing. If your teammate pushed changes and you try to push without pulling first, Git will reject your push. Always pull before you start working.

Sharing credentials in the repository. Never commit API keys, database passwords, or tokens. Use environment variables and .gitignore.

Struggling with Git in your software project? At Folium Labs we help engineering students set up proper workflows and deliver professional-quality repositories.

Need support with your thesis development? From version control to deployment, our team guides you through the entire software engineering process. See our services.

Need help with your project?

Our team can handle your thesis, research or technology project.

Get a quote

You might also like

MySQL vs PostgreSQL: which one for your project?
softwaredatabasesengineering

MySQL vs PostgreSQL: which one for your project?

Detailed comparison of MySQL and PostgreSQL for university projects. Features, performance, use cases and practical recommendations.

March 27, 20267 min read
Power BI for your thesis: data visualization step by step
softwaredata-analysistools

Power BI for your thesis: data visualization step by step

Learn to use Power BI for your thesis data visualization. Import data, create charts, build dashboards, and present findings professionally.

April 3, 20267 min read