diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..d550eaa --- /dev/null +++ b/.gitignore @@ -0,0 +1,153 @@ +# Byte-compiled / optimized / DLL files +__pycache__/ +*.py[cod] +*$py.class + +# C extensions +*.so + +# Distribution / packaging +.Python +build/ +develop-eggs/ +dist/ +downloads/ +eggs/ +.eggs/ +lib/ +lib64/ +parts/ +sdist/ +var/ +wheels/ +share/python-wheels/ +*.egg-info/ +.installed.cfg +*.egg +MANIFEST + +# PyInstaller +# Usually these files are written by a python script from a template +# before PyInstaller builds the exe, so as to inject date/other infos into it. +*.manifest +*.spec + +# Installer logs +pip-log.txt +pip-delete-this-directory.txt + +# Unit test / coverage reports +htmlcov/ +.tox/ +.nox/ +.coverage +.coverage.* +.cache +nosetests.xml +coverage.xml +*.cover +*.py,cover +.hypothesis/ +.pytest_cache/ +cover/ + +# Translations +*.mo +*.pot + +# Django stuff: +*.log +local_settings.py +db.sqlite3 +db.sqlite3-journal + +# Flask stuff: +instance/ +.webassets-cache + +# Scrapy stuff: +.scrapy + +# Sphinx documentation +docs/_build/ + +# PyBuilder +.pybuilder/ +target/ + +# Jupyter Notebook +.ipynb_checkpoints + +# IPython +profile_default/ +ipython_config.py + +# pyenv +# For a library or package, you might want to ignore these files since the code is +# intended to run in multiple environments; otherwise, check them in: +# .python-version + +# pipenv +# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control. +# However, in case of collaboration, if having platform-specific dependencies or dependencies +# having no cross-platform support, pipenv may install dependencies that don't work, or not +# install all needed dependencies. +#Pipfile.lock + +# poetry +# Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control. +# This is especially recommended for binary packages to ensure reproducibility, and is more +# commonly ignored for libraries. +# https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control +#poetry.lock + +# pdm +# Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control. +#pdm.lock +# pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it +# in version control. +# https://pdm.fming.dev/#use-with-ide +.pdm.toml + +# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm +__pypackages__/ + +# Celery stuff +celerybeat-schedule +celerybeat.pid + +# SageMath parsed files +*.sage.py + +# Environments +.env +.venv +env/ +venv/ +ENV/ +env.bak/ +venv.bak/ + +# Spyder project settings +.spyderproject +.spyproject + +# Rope project settings +.ropeproject + +# mkdocs documentation +/site + +# mypy +.mypy_cache/ +.dmypy.json +dmypy.json + +# Pyre type checker +.pyre/ + +# pytype static type analyzer +.pytype/ + +# Cython debug symbols +cython_debug/ \ No newline at end of file diff --git a/README.md b/README.md index 7d4a332..2a7b8a1 100644 --- a/README.md +++ b/README.md @@ -1,24 +1,3 @@ - -**TODO**: Delete these instructions before you submit your work. -## Instructions - -1. Read Chapters 2 & 3 of [Pro Git][ProGit]. The chapters are short. -2. Answer these questions using [Markdown format][markdown-cheatsheet] (also [Github Markdown][github-markdown]). -3. Place your answers between lines beginning with 3 backquotes, which tells Markdown it should be unformatted text, and write only the commands you would type (**no** shell prompt). E.g.: - ``` - git status CORRECT - $ git status WRONG - you do not type "$" - ``` -4. Indent the 3 backquotes so they line up with the question text (3 leading spaces) so Markdown formats you answer as part of the numbered item. - Example: - ``` - git init - ``` -5. **Test that your answers are correct!** There is **no excuse** for incorrect answers since you can test your answers by experimentation. -6. Verify that your Markdown formatting is correct -- points deducted for bad formatting. VS Code and IntelliJ have markdown previewers. You should also preview it on Github, since Github Markdown is a bit non-standard. - -**TODO**: Delete these instructions before you submit your work. Points deducted for each "TODO" in this file. - ## Using Git [Basics](#basics) @@ -38,21 +17,23 @@ In this file, directory paths are written with a forward slash as on MacOS, Linu ## Basics 1. When using Git locally, what are these? Define each one in a sentence - * Staging area - - * Working copy - - * master - - * HEAD - + * Staging area - Changes are prepared here before they are committed to the repository. It also allows us to selectively choose which change to include in next commit. + * Working copy - our local directory where we make changes to files. + * master - The default branch of out git repository. It is the main line of development. + * HEAD - Pointer that point to the most recent commmit in the current branch represent the curent position within the commit history. 2. When you install git on a new machine (or in a new user account) you should perform these 2 git commands to tell git your name and email. These values are used in commits that you make: ``` # Git configuration commands for a new account + git config --global user.name "Your Name" + git config --global user.email "your.email@example.com" ``` 3. There are 2 ways to create a local Git repository. Briefly descibe each one: - - todo: describe first way to create a local repo - - todo: describe second way to create a local repo + - Create from scratch using ```git init``` in empty directory. + - Clone from an existing repository using ```git clone ``` ## Adding and Changing Things @@ -69,43 +50,42 @@ test/ test_a.py ... ``` -> TODO: Write the git command to perform each of these: 1. Add README.md and *everything* in the `src` directory to the git staging area. ``` - todo your answer here + git add README.md src/ ``` 2. Add `test/test_a.py` to the staging area (but not any other files). ``` - todo your answer + git add test/test_a.py ``` 3. List the names of files in the staging area. ``` - todo your answer + git diff --name-only --cached ``` 4. Remove `README.md` from the staging area. This is **very useful** if you accidentally add something you don't want to commit. ``` - todo your answer + git reset HEAD README.md ``` 5. Commit everything in the staging area to the repository. ``` - todo your answer + git commit -m "commit message here" ``` 6. In any project, there are some files and directories that you **should not** commit to git. For a Python project, name *at least* files or directories that you should not commit to git: - - - - - - + - Byte-compiled (`__pycache__/`) + - Django stuff (`db.sqlite3`, `*.log`) + - Jupyter Notebook (`.ipynb_checkpoints`) 7. Command to move all the .py files from the `src` dir to the top-level directory of this repository. This command moves them in your working copy *and* in the git repo (when you commit the change): ``` - + git mv src/*.py . ``` @@ -116,33 +96,50 @@ test/ ## Undo Changes and Recover Files -> TODO: enter the git command to do each of these -> For questions where you are showing a command, use triple-backquote marks (as above) so the text is formatted as code. 1. Display the differences between your *working copy* of `a.py` and the `a.py` in the *local repository* (HEAD revision): + ``` + git diff a.py + ``` 2. Display the differences between your *working copy* of `a.py` and the version in the *staging area*. (But, if a.py is not in the staging area this will compare working copy to HEAD revision): + ``` + git diff --staged a.py + ``` + 3. **View changes to be committed:** Display the differences between files in the staging area and the versions in the repository. (You can also specify a file name to compare just one file.) + ``` + git diff --cached + ``` + 4. **Undo "git add":** If `main.py` has been added to the staging area (`git add main.py`), remove it from the staging area: + ``` + git restore --staged main.py + ``` 5. **Recover a file:** Command to replace your working copy of `a.py` with the most recent (HEAD) version in the repository. This also works if you have deleted your working copy of this file. + ``` + git checkout a.py + ``` 6. **Undo a commit:** Suppose you want to discard some commit(s) and move both HEAD and "master" to an earlier revision (an earlier commit) Suppose the git commit graph looks like this (`aaaa`, etc, are the commit ids) ``` aaaa ---> bbbb ---> cccc ---> dddd [HEAD -> master] ``` The command to reset HEAD and master to the commit id `bbbb`: - + ``` + git reset --hard bbbb + ``` 7. **Checkout old code:** Using the above example, the command to replace your working copy with the files from commit with id `aaaa`: ``` - todo your answer here + git checkout aaaa ``` Note: - Git won't let you do this if you have uncommitted changes to any "tracked" files. @@ -159,13 +156,13 @@ test/ 2. Show the history (as above) including *all* branches in the repository and include a graph connecting the commits: ``` - + git log --oneline --graph --all ``` 3. List all the files in the current branch of the repository: ``` - todo your answer + git ls-tree --name-only -r HEAD ``` Example output: ``` @@ -180,20 +177,36 @@ test/ ## Branch and Merge -**TODO**: This section is free-form. Create 4 numbered items for common branch-and-merge tasks you would like to remember and show the git command to do each one. (You are write *more* than 4 if you want.) - - - +1. Create a new branch named `feature-branch` and switch to it: +``` +git checkout -b feature-branch +``` +2. Merge the `feature-branch` into the `master` branch: +``` +git checkout master +git merge feature-branch +``` +3. Delete the `feature-branch` after it has been merged: +``` +git branch -d feature-branch +``` +4. See the list of branches with pending merges. +``` +git branch --merged # Show merged branches +git branch --no-merged # Show branches with pending merges +``` ## Favorites -> TODO: Describe *at least* 1 task that you would like to remember, and the git command(s) to do it. - - +The git command that I want to remember is the git command that I see on blog [A better git log](https://coderwall.com/p/euwpig/a-better-git-log) +``` +git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit +``` +It add ```git lg``` that is other cool way to log commit --- ## Resources -> TODO: Add your favorite Git resources (at least 1) +* [OhMyGit](https://ohmygit.org/) Learn git using game OhMyGit! Nice Learning tool for git! * [Pro Git Online Book][ProGit] Chapters 2 & 3 contain the essentials. Downloadable e-book is available, too. * [Visual Git Reference](https://marklodato.github.io/visual-git-guide) one page with illustrations of git commands.