Add and commit files

• Try to add files every now and then. If anything bad happens (e.g. accidentally deleted file), you will have a local saved copy in your local Git.
• Avoid adding files (git add) that: are not important / not useful to push to master, are dynamically generated, contain private information (e.g. a secret key), or don’t belong in the repo.
• Commit after you reach a good checkpoint, e.g. any subfeature of your feature. Try to commit often (but meaningfully) — this will help you take advantage of version control and use it effectively. Avoid committing broken code, but having stubs is okay as long as you fill them out in later commits before merging your PR.

# Check before adding and committing
$ gislt branch  # make sure you’re on the right branch
$ git status  # view which files were changed
$ git diff  # view the changes

# Add and commit your code
$ git add <changed files you want to add> 
$ git commit <files you want to commit> -m “Commit message here”

In the last command, git commit -m, the -m flag allows for an in-line message that directly follows. This is really convenient and much faster!

If you don’t want to use the -m flag in that last command for whatever reason, you can alternatively do: $ git commit <files you want to commit> This will open vim, a text editor.

• Press i to enter “Insert mode” — this will allow you to type text like you would expect.
• Type in your commit message
• Hit esc key on your keyboard
• Type :w to write (save), then :q to quit. Alternatively,:wq and :x are both commands to write and quit at once.

Other vim basics:

• When not in “Insert mode”, you can navigate by using j and k to scroll up and down, and h and l for left and right.
• When in doubt, hit esc!

Yay, you’ve committed your code! Let’s check we added and committed everything we meant to, with $ git status.

Merging master branch into your current branch and resolving merge conflicts

• Always do this before you start developing your feature. Try to do this before pushing up your branch. Must do this before opening a PR.
• Do this occasionally throughout working on your feature if it’s been a while since you’ve pulled. Other people may have pushed changes that involve the same files you have worked on. I advise you to do this often and keep your local branches up-to-date — can save you from running into merge conflicts later from building off of outdated code. I usually do this at the start of every work session.