Setting up a new repository

  1. Install Git Bash
  2. Login to Github.com and create a new remote repository
  3. location to create new remote repo
  4. In the new repo's setup page copy the link
  5. location of repo URL
  6. Open up Git Bash and navigate to the whichever directory you want your project to be in. You can get to different drives by using /c or /d
  7. Initialize the current directory as a local git repository with git init -b main. The -b option allows you to specify the branch name ('main' in this case). If you don't use any options, by default it is set to 'master'.
  8. Add the files that you'd like to keep track of to the staging area with git add <filename>. Instead of a filename you can also just use a . to tell Git to add all changes in the current directory.
  9. Commit the changes to local repo with git commit -a -m "summary". The commit message should be written in the present tense, be clear and single-line. For multiple line messages, leave out the -m option. The default code editor assigned to git will open up and you can type in your message from there. Closing the message file opened by the code editor will complete the commit.
  10. Connect the local repo to the remote repo with git remote add origin remote repo url.
  11. Push the changes to the remote repo with git push

Workflow

  1. Pull any changes from remote repo
  2. Use git status to keep track of any changes you've made so far
  3. Use git diff to view all the changes that were made to tracked files in the working directory compared to the staging area.
  4. Use git add filename to add any new changes or files to the staging area. It's important to keep commits atomic so only stage changes that you want to be included in a single commit.
  5. Use git diff --staged to view all the changes between files in staging and the local repository. Useful as a final check before committing.
  6. Use git commit -a -m "summary" to send changes to local repository
  7. Use git push to add changes to remote repo.
  8. Use git log to review all the commits to the project, including their codes. There are handy options like sorting by author or by date or by regular expression.
  9. Use git show <commit code> to view the commit in detail.
  10. Use git diff <older_commit_code>..<newer_commit_code> to view the difference between two commits

Deleting files

  1. If the file is not tracked, then just delete it manually.
  2. If the file has been committed to repository, use git rm <filename> to remove it. This will delete the file, as well as add the deletion to the staging area

Moving and Renaming Files

  1. Use git mv <filename> <new_filename> to rename tracked files. Git will immediately rename the file and send the change to the staging area.
  2. Use git mv <filename> <new_path> to move tracked files. Git will immediately move the file and send the change to the staging area.

Undoing Changes in Working Directory

Suppose you made some changes in a tracked file, saved it locally, but decided you want to undo the change. If you've closed the file, you can't just press 'undo' anymore in your code-editor. We can restore our file to its last state with Git. Only works for changes you've made in the working directory.

git checkout -- <filename>

Undoing Changes in the Stage Directory

Use git reset HEAD <filename> to remove any files you've staged.

Fixing Commits Already in the Repository

It is difficult to make changes to older commits. For each commit, Git generates a SHA value that is based on the previous commit for data integrity purposes. Changing an old commit would break the SHA chain for any commits that come after it. The only feasible commit to change is the most recent one. If you want to make amendments to the most recent commit (ex. you forgot a change that should really have been part of that commit package), you can do so via:

  1. Make the changes you want to add/remove in the working directory
  2. Stage the changes
  3. Use git commit --amend -m "summary" to replace the last commit with a new one.

On the other hand, if there's an old commit (doesn't have to be the most recent one) that you want to 'nullify', i.e. reverse all the changes its made, you can do so by:

  1. Use git revert <git_code> . This will trigger the code editor to open up.
  2. Use editor to write summary message. Closing the summary message file completes the commit, which is a commit that does the exact opposite of the specified commit.

Dealing with Untracked Files

Over the course of the project, new files may find their way into the project folder that we don't want to keep a track of. We can remove them manually and Git won't complain (because they're untracked). We can also have Git remove them for us all at once.

  1. Use git clean -n to go through a dry-run of the cleaning process and see what files would be removed.
  2. If you're okay with the list of changes, proceed with the cleaning by using git clean -f.

On the other hand, you can use a .gitignore file that will tell Git to ignore any untracked files that match the regex rules in the .gitignore.

Untracking Tracked Files

If you no longer want to keep track of a file, its not as simple as putting the file name inside a .gitignore file. You need to remove it from the staging directory:

git rm --cached <filename>

The Git status will show it as the file being deleted but its not! It is just being removed from the staging area. Now when you put the filename into a .gitignore file, the file will no longer be tracked