Git

Git is a version control tool commonly used in software and hardware engineering.

The key idea is that we have local copies (for each person working on the project) and a global repository. When people are ready to push or pull changes from the repository, they can. The idea is that we work on our own copy — and change, build, and test on our local copy before syncing with the global repository.

We can also control when others’ changes are visible. Then we immediately re-build and re-test right after we pull. This allows us to fix any integration errors or bus right away. It’s easier to commit/push and pull frequently — many small integrations are easier to debug than one huge one.

Commands

All commands are prefixed with git. Sync commands:

• add to stage changes for committing later.
  • . to stage everything, add a period after the command.
  • file-name to add a specific file.
• commit to commit changes to the repository.
  • -m "commit message" should always be specified. Make these messages meaningful!
  • --amend to modify the most recent commit by combining staged changes with it.
• fetch downloads the remote content without merging to your local repo.
• pull to sync all remote changes and merge (by default) to your local copy.
  • Immediately build and test after a git pull. This fixes bugs right away. It’s always better to commit/push/pull frequently, since many small integrations are easier to debug than one huge one.
  • -r will sync remote changes and rebase.
• push -u to push staged/committed changes to the repository. Best to push after committing.
• rm to remove files. By default this removes from both the remote repository and the local filesystem.
  • --cached only removes from the remote repository.
  • -r specifies removing an entire directory. Pair with above if necessary.

Branch and revision commands:

• checkout to switch to a different version of the repository. This will change the head to the commit we’re working with.
  • branch-name to switch to a different branch.
  • revision-id to checkout an old revision.
  • master to the last commit. This will change head.
• revert revision-id to unto a certain revision commit.
  • We also have to push after this.
• log to see a list of files modified by every commit and a message for each commit.
  • --oneline to condense each commit to a single line.
  • -n num to limit the displayed number of commits.
  • --author="string" to display commits from a given author. This can be a regular expression.
  • -p to display the full diff of each commit.
  • file-name to display changes to a given file.
• diff to show the difference between the last commit and what you have currently.
  • r1 r2 to show the difference between two commits. They don’t have to be one after the other!
  • --cached shows what exactly is going into the commit.
• show revision-id to see everything changed by the given revision.
• branch for branch options:
  • branch-name to create a new branch without checking out the new branch.
    • Prefix this with -d to delete the specified branch only if it doesn’t have unmerged changes.
    • -D for a force delete.
  • -m new-name to rename the branch.
  • -a to list all remote branches.
• stash to save uncommitted changes
  • push to restore changes previously stashed

Other useful commands:

• clone to clone an existing repository and set-up for the first-time on our local machine.
  • url to clone from a repository accessible from a URL.
• status to show information about the current state of the repo.
  • Only talks about the local repository, not the remote repo.
• config to change configuration options.
• clean removes untracked files from the working directory.
• reset removes tracked files from the working directory.
  • --hard to reset back to the last pulled revision.
• init initialises a new repo.

Addendums

Whenever you forget to specify a message when you commit changes, Git will spit out something like the below. Once you type in a commit message, you can hit the ESC key and type in :wq.

Please enter the commit message for your changes. Lines starting with ’#’ will be ignored…

Git doesn’t take a lot of space! That’s because it only stores the differences rather than the entire files.

What happens when we have conflicting edits? We should build and test. What if we modified the same file? It’s fine if we modify different lines, but if there’s a real conflict, then Git will tell us what lines are conflicting.

Git is divided into remote/local repositories.

https://www.freecodecamp.org/news/git-push-local-branch-to-remote-how-to-publish-a-new-branch-in-git/

We can specify files for Git to automatically ignore in a gitignore file.

Resources

• Pro Git, by Scott Chacon and Ben Straub