Version control (sometimes called source control) keeps track of changes to files over time. Multiple users can edit the same projects. Some platforms that support version control are GitHub, GitLab, BitBucket, and Google Drive.

Git

Git is an open source tool, but platforms like GitHub and GitLab integrate with git by hosting the repositories (project folders). Repositories can also be self-hosted and use git for management through other services. This post is structured GitHub, a popular platform for many developers. Keep in mind that other repository storage platforms have nuanced differences (e.g. GitHub UI drag and dropping existing files will track code changes, whereas GitLab UI drag and dropping existing files will assume the file is overwriting everything–history included).

Words to Know (in order of importance)

Repository (aka repo) - a project folder that tracks changes in the subdirectories and files, a collection of files Commit - sometimes considered snapshots of edits made complete with time, a hash reference, message, and the edits themselves Pull - a command to retrieve the latest edits from the repository Push - a command to push the latest edits (packaged in a commit) to the repository README.md - a file that describes how to use the project, FAQ, and/or explains what the repository is about Branch - a development path, all paths branch from main Clone - a copy of a repository often including a link to the original repo (remote) and past commits .gitignore - a file that filters what files end up on GitHub (files like .c, .java, .md, etc.) and what don’t (e.g. compiled object files, secret keys, binary files) Merge Conflict - when edits are made at the same place (and time) and a conflict occurs Fork - a clone, but set up in a user’s profile linking back to the original repo Rebase - the process of combining (“replaying”) commit(s) into a new commit (often used when resolving merge conflicts) Stage - the action of preparing file(s) to be committed

Common commands

• git status get an update of what files have been changed or are untracked
• git add <filename, ., *> add changed files to stage a commit
• git commit -m “Commit message here” add a message to a commit
• git push push a staged commit to the central repository
• git pull retrieve the latest changes from the central repository
• git reset --hard HEAD reset all files to the last commit
• git checkout branchName / git switch branchName switch to a different development path
• git checkout -b newBranchName switch to a new development path (git branch newBranchName + git checkout newBranchName)

A Normal Git Workflow (GitFlow)

1. Clone or fork a repo ```git clone `
2. Create a development branch ```git branch `
3. Switch to the development branch ```git checkout `
4. Edit file(s)
5. Add file(s) to stage them for a commit ```git add `
6. Write a message to explain the commit (aka commit message) ```git commit -m “put a short descriptive message about the changes here”`
7. Push the commit (message + prepared file(s)) to the development branch ```git push`
8. Switch to main branch ```git checkout main`
9. Pull recent changes to ensure the local branch instance is up to date ```git pull`
10. Make a Pull Request to merge the development branch into the main branch ```Go to GitHub to make a New Pull Request`
11. Confirm the pull request ```Click merge pull request`
12. If multiple users on a single repository, pull from the main branch into the development branch often git merge main to reduce merge conflicts
13. Repeat from step 3.

Pitfalls

StackOverflow is great for fixing git things. However, git is an extremely powerful tool, and it is easy to wipe the entire edit history or cause irreversible change. With great power comes great responsibility. Never automatically follow instructions on fixing things in git without understanding what each command does. Edit history can be rewritten in git, but it may not be the rewrite needed. If comamnds are confusing, spend the time to figure it out, ask another git user, or try to find another way. Just don’t do everything the internet says and lose the whole project and be unable to get it back, that defeats the whole point of version control.

Push to the development branch often/commit regularly. Not only to save changes but to ensure if others are on the branch they can pull each other’s changes and everyone can reduce their merge conflicts.

Resources

Git Documentation