sosokker/git-commands
1
0
Fork 0
mirror of https://github.com/Sosokker/git-commands.git synced 2025-12-18 12:44:04 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

Answer all question in README.md/Add .gitignore

Browse Source
This commit is contained in:
sosokker 2023-08-21 20:03:50 +07:00
parent 0665dffc23
commit 50fa418a42
2 changed files with 217 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

153
.gitignore vendored Normal file
View File

@ -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/

115
README.md
View File

@ -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 <repository url>```
## 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.