Git Version Control¶

git is a version control system that allows you to track changes in a code base, referred to as a repository. With git, collaboration/coding becomes infintely times smoother.

git lexicon¶

• track

  • files git is tracking

• staged

  • files you want to commit that have been updated since last commit

• commit

  • when you want to save a version of a file(s) you would have to commit them. Here are the steps
    • specify file(s) you want to track changes of (track files)
    • specify file(s) you want to commit changes you made to (stage a file)
    • commit files(s)

Once you commit a file then you can always go back to it if you should want to do so!

• SHA
  • every commit is given a SHA/ a unique hashing string that will be able to identify each commit

Common commands¶

Some common arguments one would add to git when using the command line is as follows:

Configurating Git Settings¶

• git config --global user.name "name"
  • change user.name to name
  • same with
    • user.email // to present in git log
    • core.editor // for writing commit messages
  • to view name/email/editor
    • git config user.name ...etc

Initiating Repo¶

• git init
  • initiates repository to track changes to in specified files/subdirectories in current folder

Information about commits¶

• git log
  • list in descending order of all commits you've made in repository
  • each commit is given unique SHA identifier
  • git log --graph
    • show visual of branches
    • git log --graph --oneline branch1 branch2
      • Show a visual representation of the commit history within different branches

Staging Files, info about staged files¶

• git status
  • gives the user information about:
    • current branch
    • tracked/untracked files
    • staged/unstaged files
• git add file
  • track file(s), then stage if not previously staged
  • stage file(s) if already tracked
• git reset HEAD file
  • unstage file(s)
• git reset
  • whole repository is unstaged
• git rm --cached file
  • untrack file(s)

Commiting files¶

• git commit
  • commit staged files
  • git commit -m
    • write commit message in command line
  • git commit --amend
    • commit amends to previous commit
• git config --global core.editor "path to text editor"
  • sets text editor to be used for commiting files

Branches¶

• git checkout -b branch
  • create news branch
• git checkout branch
  • switch to existing branch
• git branch
  • list branches
• git branch -d branch
  • delete branch
• git push origin :remote branch
  • delete remote branch in origin
• HEAD
  • shortcut for current branch

merging branches¶

• git merge branch
  • merges branch we want merged into curr branch
  • needs to be in main branch?
• git merge branch1 branch2
  • Merge two branches, branch2 get merged into branch1
• git merge local branch remote_name/remote branch
  • example:
    • git merge master origin/master
  • merge local branch with remote branch

Cloning a public repository¶

• git clone url of repo directory to clone to

Viewing differences in a file¶

• git diff
  • shows differences between last commit and unstaged files
  • git diff file
    • specific file
  • git diff SHA1 SHA2
    • shows differences between two commits
• git diff --staged
  • shows differences between pre/post staged files
• git show commitId
  • Show the changes made in this commit compared to the previous version.

Adding a remote repository¶

• git remote add name url of repo
  • adds repo and gives it the name name
• git remove -v
  • lists remote repos

Pulling code from a remote repo¶

• git pull name branch
  • pulls specified branch of remote repo named name
  • merges to local branch
• git fetch name
  • fetches repo without merging
  • In the simplest terms, git pull does a git fetch followed by a git merge. You can do a git fetch at any time to update your remote-tracking branches under refs/remotes/remote/. This operation never changes any of your own local branches under refs/heads, and is safe to do without changing your working copy.

Pushing code into a remote repo¶

• git push -u name branch
  • pushes specified branch into remote repo named name

Undoing changes¶

• Undo "local" changes

  • git checkout SHA file
    • returns to previous commit of file
    • git checkout SHA
      • returns to previous commit of all files
  • git checkout -- file
    • git checkout alters files in the working directory to a state previously known to Git. You could provide a branch name or specific SHA you want to go back to or, by default, Git will assume you want to checkout HEAD, the last commit on the currently-checked-out branch.
    • Keep in mind: any changes you "undo" this way are really gone. They were never committed, so Git can't help us recover them later. Be sure you know what you're throwing away here! (Maybe use git diff to confirm.)

• Reset "local" changes

  • git reset last good SHA
    • rewinds your repository's history all the way back to the specified SHA. It's as if those commits never happened. By default, git reset preserves the working directory. The commits are gone, but the contents are still on disk.
  • git reset --hard last good SHA
    • "undo" the commits and the changes in one move

Forking a repo (github)¶

When working in github, you can copy a repository to your suite of repos by 'forking the repo'

Pull Request (github)¶

submitting a pull request to a user means to ask the user to merge changes you made into his repo

When you want to help with the code you would generally do the following:

• fork repo (github)
• clone repo to local disk
• create new branch
• make changes you want
• commit changes
• push to your forked repo
• submit pull request to user with new branch (github)

Best practices¶

Commits¶

• one commit per logical change
• first line
  • present imperative short (<= 50 chars), followed by a new line (leave a line blank)
• rest
  • paragraph explaining more deeply

Adding new features¶

• make a new branch
• push up to github (if that is the repo hosting service your team is using)
• team members will review code
• if it looks good, merge to development branch (dev branch)

Software development¶

• generally three branches:
  • stable
  • dev
  • features (f1,f2,f3...)

Questions¶

1. When would you want to use a remote repository rather than keeping all your work local?

   There are many reasons for this, among the most common I've found to be are:

   • colloboration with others
   • to show case your work
   • To share your code with others to use

2. Why might you want to always pull changes manually rather than having Git automatically stay up-to-date with your remote repository?

   You might want to make conflicting changes to code.

3. Describe the differences between forks, clones, and branches. When would you use one instead of another?

   • forks: copying repo from github repo to github repo
   • clones: cloning repo from github repo to local disk repo
   • branches: When you want to create new features without compromising stable code.

4. What happens when you initialize a repository? Why do you need to do it?

   Tells git to track files/subdirectories in that directory

5. How is the staging area different from the working directory and the repository? What value do you think it offers?

   Gives you a chance to confirm files you want to commit to repository.

6. How can you use the staging area to make sure you have one commit per logical change?

   Commit one file at a time, with unique commit message for each update

7. What are some situations when branches would be helpful in keeping your history organized? How would branches help?

   Branches give you the freedom to experiment with new features for your code. Once you test a feauture effectively you can merge it to main branch with no 'garbage' commits.

8. How do the diagrams help you visualize the branch structure?

   The diagrams tells you what are 'unreachable' commits ie. which commit belongs to a different branch entirely.

9. What are the pros and cons of Git’s automatic merging vs. always doing merges manually?

   Git will prevent future commits if there is an unresolved merge conflict. This ensures less mistakes.

10. How did viewing a diff between two versions of a file help you see the bug that was introduced?

    Git diff shows the changes made, similar to unix's diff but much more powerful. If previous commit was stable you can see all the changes you made to spot the error.

11. How could having easy access to the entire history of a file make you a more efficient programmer in the long term?

    Good for debugging, going back to previous working versions of code. Git encourages creating new features with these safety features.

12. What do you think are the pros and cons of manually choosing when to create a commit, like you do in Git, vs having versions automatically saved, like Google docs does?

    • pros
      • more choice of what to comit
      • a lot more commits than might be necessary
      • shows logical progression of code
    • cons
      • if you forget to commit you can lose versions of code
      • subject to human mistakes (garbage commits etc)

13. Why do you think some version control systems, like Git, allow saving multiple files in one commit, while others, like Google Docs, treat each file separately?

    Git is created to track changes for bigger projects.

14. How can you use the commands git log and git diff to view the history of files?

    • git log to see history of commits
    • git diff to see differences b/n two commits