Version Control using Git/Github

git reset commit_SHA

Resets to a previous commit in your commit history.

git status

inspects the contents of the working directory and staging area

Creating a new branch

--> branch has a new name, i.e. not the master --> another named version of the repo; 100% of the original repo but with a different name & different track --> Branches are often used: ● moving code to a new version ● refactoring code --> When PR is completed and developer updates PR with changes, then branch is merged to master --> If say refactoring doesn't work, just delete the branch and the master is unchanged

simplified version of above

1. Create a new branch (called 'feedback') 2. Develop and commit to that branch 3. When finished, open a PR for that branch into master 4. @mention another developer in PR to review 5. Reviewer adds comments to the PR 6. Optionally: Developer does more commits (which updates the PR) 7. When finished, the developer then merges the branch in GitHub

When teams build software, they often use PR code reviews

1. Original developer creates a git branch with the issue number (e.g. EAG-123) of what they're working on 2. They commit to that branch, messages start with that issue number, e.g. "[EAG-123] add support for X" 3. When finished, they open a PR for that branch into master 4. Developer assigns the issue to another developer to review 5. Then the reviewer git fetches and checks out that branch, then tests and reviews it 6. Reviewer adds comments to the PR 7. Developer does more commits (which updates the PR) --> updates any issues in the code 8. When finished, the reviewer then merges the branch in GitHub

The basic Git workflow

1. User modifies files in the working directory 2. User stages the files by adding them to the staging area 3. User does a commit - takes the files as they are in the staging area and stores that snapshot permanently to the Git directory

git branch "branch name"

Creates a new branch.

git branch -d "branch name"

Deletes the branch specified

git checkout HEAD "filename"

Discards changes in the working directory.

What is Git?

Git is known as a "distributed" (rather than "centralized") version control system because you can run it locally and disconnected from the Internet, and then "push" your changes to a remote system (such as GitHub) whenever you like.

HEAD commit

In Git, the commit you are currently on is known as the HEAD commit. In many cases, the most recently made commit is the HEAD commit.

git branch

Lists all local branches in the current repository

Pull requests

Pull = server -> local ● If the server (GitHub) has a more recent version... to update your local copy of a project, pull changes from the server Command line: git pull - Fetch from and integrate with another repository or a local branch (assuming remote is setup already) PyCharm: VCS > Git > Pull

Push requests

Push = local -> server ● Git maintains a local copy of your project and its history ● To store this in GitHub or another remote, you push it Command line: git push (assuming remote is setup already) PyCharm: VCS > Git > Push or do it when you "Commit and Push

git reset HEAD "filename"

Unstages file changes in the staging area.

git merge "branch name"

Used to join file changes from one branch to another

git checkout "branch name"

Used to switch from one branch to another

git add "filename"

adds files from the working directory to the staging area

git commit -m "message"

adds files from the working directory to the staging area with a message in " ".

git init

creates a new Git repository

git commit

permanently stores file changes from the staging area in the repository

git log

shows a list of all previous commits

git diff

shows the difference between the working directory and the staging area

Life with version control = :)

● A Version Control System (VCS) records changes to a file or set of files over time so you can recall specific versions later. --> a backup plus history of changes ● It allows you to: - Revert files to previous state -Revert entire project back to previous state - Compare changes over time - See who modified what And more... ● It means if you break your code or lose files, you can easily recover earlier saved state(s) ● Collaboration with others on projects ● Version control facilitates code reviews

Code reviews improve software quality

● A code review is a systematic examination or peer review of code --> feedback on your code for improvement ● Goals: ● find and fix mistakes ● improve the overall quality of software ● improve the developers' skills ● Reviews are done in various forms: ● pair programming --> swapping reviewer and writer roles ● informal walkthroughs ==> programmer explains code to a group of other programmers ● formal inspections --> using GitHub ● and to a lesser extent, self-reviewing --> NOT a code review

Branches

● Different versions are handled by commit history - or use branches ● Do NOT make new folders in your project for different versions (e.g. if you're trying a new idea) ● Just commit, make changes, commit again... - You can always checkout an earlier version ● Use branches to work on something new in a project and keep it separate (a branch is a full copy) ● You can merge branches together later on Command line: git branch name_of_branch git merge - Join two or more development histories together git fetch - Download objects and refs from another repository

Create a repository (repo) for each project

● Don't store everything in one Git repository ● Use one repo per project ● Command line: git init - Create an empty Git repository or reinitialize an existing one git clone - Clone a repository into a new directory git remote - Manage set of tracked repositories

Commit messages

● Each commit is accompanied by a 'commit message' ● Descriptive commit messages are one of the best things you can do for others who use the repository... including you! ● It lets people quickly understand changes without having to read code.

Commit regularly...

● Every time you reach a small milestone ● Each commit (check-in) saves your work (to the history) ● Git only takes responsibility for data you've committed ● Don't wait too long between commits, e.g. - Every time a new feature is completed, passes a test - When you finish work in the lab for the day and need to change computers Command line: git commit # Commits all the changed files with "Commit Message" or git commit -a # Adds/Removes and Commits in a single command PyCharm: VCS > Commit Changes...

Why Git?

● Everything is local (full history tree available offline) ● Everything is fast ● It is distributed - Git gives each developer a local copy of the entire development history: ● Not centralised (no single point of failure or bottleneck/slowness) ● There are other version control systems (you may need to use these some day): SVN (Subversion), CVS, Mercurial

Add files from your working directory to your Git project

● Files in your project directory don't automatically get added to your Git repository ● Command line: git add . (add all files) git add filename (add one file) PyCharm: Select files in left pane and right-click, or: VCS > Git > Add

Fork & Pull

● Fork & Pull is used for editing another person's repository: 1. Fork an existing GitHub repo - This is just a clone (copy), but GitHub tracks it 2. Modify the code in your new repo 3. Commit your changes 4. Send a pull request to the original repo --> PR is the end result of forking, modifying & committing changes; PR is sent to the owner of the repo 5. The owner of the original checks to see differences and can merge the pull request into the original repo --> the owner of the repo makes the final decision to merge any changes - They could use all or only some parts of the pull request 6. (optionally, delete cloned repo) Example: https://github.com/ninjasphere/go.wemo/pull/1

Git states

● Git has three states your files can be in: 1. Working directory 2. Staging area 3. Repository ( .git directory)

Full Snapshots

● Git stores full snapshots, not diffs (differences between versions) ● Git only makes a new file when a file in the working directory changes

GitHub

● GitHub is a Web hosting service for projects that use Git ● Git and GitHub are different things: - You can use Git without using GitHub ● Store your work on GitHub and you can access it anywhere ● GitHub has become one of the most important parts of a developer's CV (e.g. http://www.cnet.com/news/forget-linkedin-companies-turn-to-github-to-find-tech-talent/)

Version control helps with code reviews

● Major benefit of version control --> the ability to share code and collaborate --> GitHub ● One of the best ways to do a code review is with a Pull Request (PR) on GitHub ● https://help.github.com/articles/using-pull-requests ● This can be done in a separate copy of the repository, called a fork, or in a branch --> make a side project

Life without version control = :(

● The dog ate my files ● I don't have my USB drive with me ● It used to work and I don't know what I've changed ● Oops I deleted the wrong file ● Who changed the files? ● Jimmy broke something... ● Backup? What backup?

Git Learning...

● There's a lot more to Git and GitHub: - Forks, Pull Requests, Tags, Releases, Organisations, Collaborators, viewing status and logs... ● Don't try and learn everything to start with ● Just start using it and it will all make sense ● You'll wonder how you ever survived without it!

Code reviews often find common mistakes

● Use common mistakes/checklists to learn what to avoid --> syntax & docstring errors ● Try and write code that doesn't make the usual mistakes

Use descriptive commit messages

● Use the imperative voice for commit messages ● Messages should read as the completion of the statement, "if applied, this commit will..." (but start with a capital) - If applied, this commit will... Refactor subsystem X for readability - If applied, this commit will... Update getting started documentation - If applied, this commit will... Merge pull request #123 from user/branch - If applied, this commit will... Release version 1.0.0 Websites on commit messages: http://chris.beams.io/posts/git-commit/#imperative https://github.com/spring-projects/spring-boot/commits/master

Version Control Summary

● Version control is extremely important and very helpful ● Use Git and GitHub to store your code and keep track of revisions ● Use good commit messages for all commits ● Learn and use Git gradually, building up industry-relevant expertise

Use automated testing tools

● Why bother a real person (time == $) to find basic problems when a machine can do it better? ● Various tools can check for errors and compare your code against standards like PEP8 (style guide) and PEP257 (docstrings) ● Similar to what PyCharm does ● tox, pylint and flake8 are Python modules ● install with pip ● tox.readthedocs.io , pylint.org , flake8.pycqa.org