Previous: 01-02-LinuxBash.html
For example, in a day’s work you may produce:
~> ls
draft.py
final.py
final_real.py
final_real_real.py
actually_done.py
actually_done_v1.py
actually_done_v2.py
actually_done_v2.1.py
actually_done_v2.1-2019-12-10.py
...Ok, I guess I should use Git…
Sub-problem:
You had a working version of your code at the beginning of the
day,
but at the end of the days work, it’s broken.
For example:
* How to write code between 1000’s of people while everyone wants to
work at once.
* How to re-write or draft a document (e.g., a constitutional amendment)
at once with lots of people.
In case of fire:
git commit, git push, leave the building!
Version control is the Git…
Git is one byte short of a four-letter word.
https://git-scm.com/
https://en.wikipedia.org/wiki/Git
* Git is software. It exists locally on your machine and other
developer’s machines.
* Github, Gitlab, and BitBucket are websites (servers), that
interface with end-users’ git software.
* They host their own versions of Git-compatible server software that
hosts Git repositories and talks to local Git processes.
* Quite ironically, unlike GitHub (now a Microsoft product), Gitlab’s
server-side software is actually
https://en.wikipedia.org/wiki/Open_source, so anyone can host their own
Gitlab website/server.
* Gitlab itself also has a rich positive development community.
* MST IT hosts two installations of Gitlab server-side software, on two
different servers residing on campus (cool!!):
* https://git.mst.edu (permanent code, like lab code or personal
projects)
* https://git-classes.mst.edu (class code, which gets deleted ever
now-and-then)
* This is actually a good approach for now, if you break your “repo” but
still have your code…
* Later, you will want to learn branching and conflict handling
better.
#!/bin/bash
# Make a repository at https://git-classes.mst.edu
# Show the gitlab view of it
git clone
vim README.md
vim hello_world.py
# write, save, quit
git add .
git commit -m "my first repo!"
git push -u origin master
# show web interface
# edit a file locally
git push #?
git pull #?
# edit something in web, then, what happens?
git pullCheck out some real repositories
* https://github.com/explore
* For example:
* https://github.com/nasa
* https://github.com/LLNL
* https://gitlab.com/explore
* For example:
* https://gitlab.com/cryptsetup/cryptsetup
* https://gitlab.com/inkscape/inkscape
Distributed version control
Snapshots (commits) include all files
Three places where edits exist
Pre-use configuration: these are just for meta-data, not login,
etc.
* $ git config --global user.name "<YOUR NAME>"
* $ git config --global user.email <EMAIL>
* $ git config --global core.editor vim
* or your choice of text editor
$ git init Makes a new empty git repository out of your
current working directory and its sub-directories.$ git add <FILENAME> Adds FILENAME
or changes to FILENAME to the next commit. Addable thing
can be a wildcard, like . or *$ git commit -m "some message" Takes a snapshot
(commit) with any staged (added) changes.
THESE SHOULD BE YOUR CONSTANT GO-TO:
* $ git status Shows the status of the repository.
* $ git diff Shows the diff of anything you have done from
your last snapshot
* $ git diff fileofinterest.py
* $ git log --all --graph Shows a nice history
$ echo hey >>README.md
$ git add README.md
$ git commit -m "a message"
$ echo hey >>README.md
$ git commit -am "b message"
$ echo hey >>README.md
$ git commit -am "c message"
$ git log -p --all --graph++++++++++++++++++++++++++++
Cahoot-02c.1
May the forks be with you!
$ git branch new-branch
$ git checkout new-branch$ git checkout -b new-branch$ git log -p --all --graph
$ echo hey >>README.md
$ git commit -am "d message"
$ git log -p --all --graph
$ git checkout master
$ git log -p --all --graph
$ git checkout -b another
$ git log -p --all --graph
$ echo hey >>README.md
$ git commit -am "e message"
$ git log -p --all --graph$ git diff branch1..branch2
Incorporates changes from the named commits (since the time their
histories diverged from the current branch) into the current
branch.
$ git merge new-branch
$ git log -p --all --graph
$ git checkout master
$ git merge another
$ git log -p --all --graph
CONFLICT (content): Merge conflict in the-file.txt
Automatic merge failed; fix conflicts and then commit the result.
In the-file.txt:
`<<<<<<< HEAD `
`The current branch's contents `
`=======`
`Stuff from the branch you're merging `
`>>>>>>> new-branch `$ git add the-file.txt
$ git commit -m "message"
++++++++++++++++++++++++++++
Cahoot-02c.2
$ git status shows summary data
$ git log Show a log of commits
--graph Neat ASCII graph
--all Shows all branches
-p Show what changed in each commit
$ git show firstfourofhashofcommit
$ git diff Show un-added, un-committed changes for all
files
$ git diff firstfourofhashofcommit
$ git diff --cached shows diff with added but not committed
changes
$ git diff branch1..branch2
Now, how to clean up a mess?
$ git checkout file.py
$ git revert help
To delete all local changes in the branch that have not been added to
the staging area, and leave un-staged files/folders, type:
$ git checkout .
To undo the most recently added, but not committed, changes to
files/folders:
$ git reset .
$ git clone <REPO_URL>
* makes a copy of a repository.
git push
$ git push
* Pushes changes from your current branch to the remote branch it
tracks. (You may need to run
$ git config --global push.default simple.)
For example, to push your local commits to the master branch of the
origin remote:
$ git push origin master
git pull
$ git pull
* Pulls changes from the remote branch and merges them into your current
branch
$ git remote -v
* To view your remote repositories
$ git remote add <REMOTE_NAME> <REPO_URL>
* adds a remote to an existing repository.
For projects you work on:
a ‘git pull’ a day, keeps the conflicts away
If there may be remote changes,
then commit before pull!
$ git commit -am "always commit before pull
$ git pull++++++++++++++++++++++++++++
Cahoot-02c.3
$ git clone https://git.company.com/project.git$ git checkout -b dougs-branch
$ git add <FILENAME> to stage them,
and
$ git commit when they are in a working state.$ git checkout master and$ git merge dougs-branchmaster
branch (but not on the company’s repo).HEAD now pointing to?$ git pull to fetch and merge their changes$ git add <FILENAME> to stage, and$ git commit when in a working state$ git pushWhen you need a scapegoat for that critical mistake in your
code-base…
$ git blame help
A tip for version control, not for relationships…
++++++++++++++++++++++++++++
Cahoot-02c.4
$ git commit when the code works.a.out) to your
repo..gitignore file in your repository.$ git help COMMAND will show you documentation.
$ git COMMAND --help will usually too.$ man git COMMAND often does too.https://en.wikipedia.org/wiki/Continuous_testing
https://en.wikipedia.org/wiki/Continuous_integration
https://en.wikipedia.org/wiki/Deployment_environment
Continuous testing was originally proposed as a way of reducing waiting time for feedback to developers by introducing development environment-triggered tests as well as more traditional developer/tester-triggered tests.
Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.
For Continuous testing, the scope of testing extends from validating bottom-up requirements or user stories to assessing the system requirements associated with overarching business goals.
Note:
Your https://git-classes.mst.edu unit tests are built into the git CI
framework!
Check out how we do it:
* https://about.gitlab.com/ci-cd/
* https://docs.gitlab.com/ee/ci/
* https://about.gitlab.com/product/continuous-integration/
Remember, in learning to code, and trying new projects:
Fork it until you make it!