Web_Dev_Grad

GitHub is like a social media platform for code. It's a place where developers can share projects, collaborate, and keep track of changes. But the real engine powering all that version control is Git, a tool that tracks every edit you make to your files and lets you roll back changes if something goes wrong. This is essentially a timeline of your project and consists of snapshots (commits) of the development journey. GitHub builds on Git by giving it a clean, user-friendly interface and making it easier to work with others online. Think of Git as your toolbox and GitHub as the shared workshop where everyone brings their tools to build something together. When you're working on a project in something like Visual Studio Code, that's your local repository and it's stored on your own computer. You can track your changes there, then move them to a staging area, and finally commit them to your remote repository on GitHub. This process is especially helpful in team environments, where a project lead can review and approve changes before they're merged into the main codebase. This helps ensure everything continues to works, sticks to best practices, and keeps bugs to a minimum which makes Git and GitHub essential for modern development.

Here I will go through some basics and common uses of Git and GitHub, but for further information, the documentation of GitHub is really well written and can be accessed here.

Head on over to GitHub and follow the signup process to create your free GitHub account. If you are using this for networking rather than purely storage of code and projects, it is a good idea to create a profile README.md. This acts as an "about me" section that is visible to those who view your profile and would be a great place to state your interests, experience and openness to collaboration. A detailed description of this process is outlined here.

A repository (or "repo" for short) is a folder for your project hosted on GitHub. It holds all your files, tracks every change you make, and lets you collaborate with others. On GitHub, creating a new repository is straightforward.

• Once you're logged in, just click the "+" icon in the top right corner and select "New repository".
• You'll be asked to give it a name so give it something clear and descriptive so that you (and others) know what it is at a glance. That name also becomes part of the URL if you use GitHub Pages later.
• You can also choose whether to make the repo public or private.
• There's an option to pick a template, which gives you a head start with some boilerplate files, but in my experience, I usually skip this step and build from scratch.
• You will also get the option to add a .gitignore file (this tells Git which files to ignore — like system junk or virtual environments) and a README file, which is the key piece of documentation for your project.
• Once you've got your settings how you like them, hit “Create repository”, and you're good to go.

The full, in depth process is described excellently in the GitHub documentation here.

With a repository created, you are probably eager to start writing your code. You can find a link on your GitHub repository page. Click on the green "<> Code" button, then copy the link which will be in the form of https://link. You can clone this repository in your local IDE. I use Visual Studio Code, you can follow my guide to setting it up here.

After you make changes to your code, you can save your files. These are now saved on your local repository (your PC) and will differ from those on your GitHub repository. Add them to the staging area using git add filepath/filename.ext or git add . which adds all changed files. You can check your staging area using git status. This will list files you've added in green under “Changes to be committed:”. Commit these using git commit to commit these changes from your staging area to your remote repository hosted on GitHub. This is the basic process for solo developer projects. For larger projects, you may need to create forks and merge requests which are covered in the Collaborating with GitHub section.

We saw above some git commands that are executed in the terminal of your IDE such as git add and git status. There are many more you can find in the GitHub documentation but I find the following list pretty comprehensive for my learning journey.

        
            git init
        
    

This command initializes a new Git repository in your current project folder. It sets up the .git directory that Git uses to track versions of your project. You typically use this once per project, but only if you're starting a project from scratch locally. If you're working with a project that you have cloned from GitHub using git clone, then git init is not necessary because the cloned repo already comes with Git initialized and configured to track the remote repository.

        
            git status
        
    

This shows the current state of your working directory and staging area telling you which files have been modified, added or are in the staging area ready to be committed.

        
            git diff filename.ext
        
    

This shows the line-by-line differences between your working file and the last committed version so is great for double-checking changes before staging them or finding bugs if you've accidently caused some damage to functionality.

        
            git add
        
    

git add filepath/filename.ext adds the currently saved version of the file to the staging area ready to be included with the next commit. Multiple files can be added to the staging area sequentially and then uploaded in one commit. git add . adds all updated files at once.

        
            git commit -m "Your message here"
        
    

This commits the files in your staging area to the remote repository including a short message to describe what has been changed or added. Clear, meaningful messages are best for this and explored below in the Git Commits section.

        
            git remote -v
        
    

When working on a shared repository, this will list all of the remote repositories connected to your project and their URLs. This is used to check where your code is coming from or going to.

        
            git push
        
    

When working on a shared repository, this will upload your commits to the remote repository, used when you are ready to share your updates.

        
            git pull
        
    

When working on a shared repository, this will update your local repository to the current main branch of the remote repository. For instance if multiple developers are working on the same project, you would want to do this before making changes so that you are working on the most up to date code.

        
            git log
        
    

Shows a list of all commits made to the repository with the most recent being at the top. This is good for reviewing what has been don, by who, and when, or to find a specific commit if you need to revert changes by using the commit SHA.

        
            git reset --hard first_6_digits_of_commit_SHA
        
    

Used to completely reset your project to that specific snapshot. THIS WILL ERASE ALL CHANGES MADE AFTER THAT COMMIT, so be sure that you want to do this before committing yourself.

When creating a commit, I like to start the message with a keyword followed by a colon to clearly identify what was worked on or added. Full details on how to customise commit messages can be found in the documentation online. Again the keywords listed here are just my personal preference, not following a set convention.

GitHub also provides you access to GitHub Projects, which is a great tool to help structure your development and keep tabs on what is being done and by whom. To get started, head to your repository, and click on the Projects tab. From there, you can create a new project, and I recommend starting with the "Basic Kanban" template, as it's a simple way to set up a board layout where you can easily move tasks around. The Kanban board has columns like "To Do," "In Progress," and "Done," which makes it easy to track what you're working on. You can add extra columns for specific features or tasks if you require. You can add individual tasks as cards and click and drag cards between columns as you make progress.

I like to add an extra field to my projects; the MoSCoW system to highlight whether the action is essential (Must), non-essential but very much wanted (Should), non-essential and fine to miss out if there time runs out (Could) or things to include in future (Would). To do this, from your project page click the three dots (…) towards the top right and go to “Settings”. On the left hand side you should see “Custom fields”. Go ahead and click “+ New Field” and name it MoSCoW. Now clicking on this, you can add new options so add Must, Should, Could, and Would. Then click the three dots to the right of each option to edit them with a colour that makes sense to you and a description such as “Things that must be completed / included” for “Must”.

Now when you add a new task (using the “+ Add Item” at the bottom of a column) you can customise it fully:

• Type out the task title
• Click on the task to open it
• Edit the body of the text using the three dots (…) and “Edit”
• On the right hand side, assign someone to the task
• Click “Convert to issue” to link it the correct repository
• Add a label to indicate the type of task
• Select which of the MoSCoW categories it fits under

When you're working and making changes, you can keep everything synced up by linking issues to commits. All you have to do is reference the issue number preceded by a # in your commit message with something like git commit -m "Fix: correct search functionality. Issue: #4" and GitHub will automatically link the commit to that issue. It's a neat way to stay on top of things.

You can host front-end websites built with HTML, CSS, and JavaScript for free through GitHub Pages. This is great for portfolio pieces, a project demo, or just something fun you've been working on.

Head to your repository on GitHub and go to Settings (on the far right of the bar at the top that has <>Code, Issues, Pull Requests etc. in). From there, scroll down the side menu to Code and automation, then Pages (or just search "Pages" in the settings search bar). Under the Deployment section, look for the "Source" dropdown and make sure it's set to your main branch, not "None" and click “Save”.

Your live website will end up at a URL that looks something like: https://your-username.github.io/your-repo-name. If you're just using it for a personal site or portfolio, you might even have it set up at https://your-username.github.io. There's also a Theme Chooser right in the GitHub Pages section. If you're in a rush or just want a clean layout, you can pick a theme to give your site a simple look without having to write any extra CSS.

Getting started with collaboration on GitHub might seem a little intimidating, but once you understand how the different aspects of collaboration work, such as inviting teammates, making forks, creating pull requests, and handling merge conflicts, it all starts to click. Collaboration on GitHub is basically all about communicating clearly and being kind to your future self (and teammates) with clean commits and clear pull requests. Once you get into the rhythm, it becomes second nature.

Adding Collaborators

If you're working on a small project with a few people you trust, the easiest way to collaborate is to add them directly to your repository. Here's how:

• Go to your repo on GitHub.
• Click Settings > Collaborators.
• Under the “Manage access” section of the page, hit “Add people” and enter their GitHub username, full name, or email.

Once they accept, they'll have permission to push changes directly to the repo.

For safety, especially on bigger projects, you can protect your main branch so no one accidentally breaks anything:

• Go to Settings > Branches > Add branch ruleset

Select your main branch and check options like Require pull request reviews before merging. This ensures that all changes go through a review process first. For more examples see the pages for rulesets and protected branches in the GitHub documentation.

Forking a Repository

If you don't want to give someone direct access, or if you're contributing to someone else's project, forking is the way to go. Forking creates a copy of the upstream repository under your GitHub account, so you can work on it without affecting the original project. For full information, see the forks section of the documentation. Outlined here is my general experience with them.

• Click the grey “Fork” button on the top right of the repository page and select “+ Create a new fork”. This makes a copy of the repository on your GitHub profile.
• Clone this forked repository (from your GitHub profile) onto your IDE in the usual way.
• Create a branch for your changes using
  • git checkout -b your-branch-name
• Make your changes and push them
  • git push origin your-branch-name
• To keep your fork updated, make sure to add the original repo as a remote.
  • git remote add upstream https://github.com/original-owner/repo.git git pull upstream main

Pull Requests

Once you've pushed a branch with your changes, GitHub usually shows a "Compare & Pull Request" button. This is where the real collaboration begins.

In a pull request you can:

• Describe what you changed and why
• Explain how you tested it
• Link to any issues it solves (just type #issue-number from the associated Project)
• Assign reviewers, so your teammates know to take a look

There are a couple of ways the code can be merged once it's approved:

• Merge Commit: Keeps the history and shows all the commits.
• Squash and Merge: Combines your commits into one clean entry (great for tidy repos).

If a reviewer requests changes, just make your edits locally and push again — GitHub will automatically update the pull request. Once your pull request is merged, don't forget to sync your main branch again wit git checkout main and git pull origin main.

Merge Conflicts

Merge conflicts occur when two or more developers try to merge changes they have made from their forked repository to the upstream main repository but having made different changes. For instance if one developer changes Functionality A and merges it, but another developer is working on another aspect of Functionality A from the original repository, when they come to merge the same file, it will not include all the changes to Functionality A that the first developer made.

It can also occur if two developers make changes to the same line of code.

In the first case the second developer can:

Sync your main branch:

git checkout main
git pull origin main

Switch back to your working branch:

git checkout your-branch

Rebase your changes:

git rebase main

Git will point out the conflict. Open the file, look for the <<<<<<< HEAD markers, and manually resolve the conflict.

Once resolved:

git add .
git rebase --continue
git push origin your-branch -force

In the second case (the same line of code is changed by 2 developers) you try to pull changes, but Git can't merge them automatically. Here's how to deal with it:

Look at the commit history:

git log
git log origin/main

If your local branch is out of sync, reset it:

git reset --hard HEAD^1
git pull origin main