├── LICENSE ├── .gitignore ├── README.md └── advanced └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2024 Maras13 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Byte-compiled / optimized / DLL files 2 | __pycache__/ 3 | *.py[cod] 4 | *$py.class 5 | 6 | # C extensions 7 | *.so 8 | 9 | # Distribution / packaging 10 | .Python 11 | build/ 12 | develop-eggs/ 13 | dist/ 14 | downloads/ 15 | eggs/ 16 | .eggs/ 17 | lib/ 18 | lib64/ 19 | parts/ 20 | sdist/ 21 | var/ 22 | wheels/ 23 | share/python-wheels/ 24 | *.egg-info/ 25 | .installed.cfg 26 | *.egg 27 | MANIFEST 28 | 29 | # PyInstaller 30 | # Usually these files are written by a python script from a template 31 | # before PyInstaller builds the exe, so as to inject date/other infos into it. 32 | *.manifest 33 | *.spec 34 | 35 | # Installer logs 36 | pip-log.txt 37 | pip-delete-this-directory.txt 38 | 39 | # Unit test / coverage reports 40 | htmlcov/ 41 | .tox/ 42 | .nox/ 43 | .coverage 44 | .coverage.* 45 | .cache 46 | nosetests.xml 47 | coverage.xml 48 | *.cover 49 | *.py,cover 50 | .hypothesis/ 51 | .pytest_cache/ 52 | cover/ 53 | 54 | # Translations 55 | *.mo 56 | *.pot 57 | 58 | # Django stuff: 59 | *.log 60 | local_settings.py 61 | db.sqlite3 62 | db.sqlite3-journal 63 | 64 | # Flask stuff: 65 | instance/ 66 | .webassets-cache 67 | 68 | # Scrapy stuff: 69 | .scrapy 70 | 71 | # Sphinx documentation 72 | docs/_build/ 73 | 74 | # PyBuilder 75 | .pybuilder/ 76 | target/ 77 | 78 | # Jupyter Notebook 79 | .ipynb_checkpoints 80 | 81 | # IPython 82 | profile_default/ 83 | ipython_config.py 84 | 85 | # pyenv 86 | # For a library or package, you might want to ignore these files since the code is 87 | # intended to run in multiple environments; otherwise, check them in: 88 | # .python-version 89 | 90 | # pipenv 91 | # According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control. 92 | # However, in case of collaboration, if having platform-specific dependencies or dependencies 93 | # having no cross-platform support, pipenv may install dependencies that don't work, or not 94 | # install all needed dependencies. 95 | #Pipfile.lock 96 | 97 | # poetry 98 | # Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control. 99 | # This is especially recommended for binary packages to ensure reproducibility, and is more 100 | # commonly ignored for libraries. 101 | # https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control 102 | #poetry.lock 103 | 104 | # pdm 105 | # Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control. 106 | #pdm.lock 107 | # pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it 108 | # in version control. 109 | # https://pdm.fming.dev/latest/usage/project/#working-with-version-control 110 | .pdm.toml 111 | .pdm-python 112 | .pdm-build/ 113 | 114 | # PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm 115 | __pypackages__/ 116 | 117 | # Celery stuff 118 | celerybeat-schedule 119 | celerybeat.pid 120 | 121 | # SageMath parsed files 122 | *.sage.py 123 | 124 | # Environments 125 | .env 126 | .venv 127 | env/ 128 | venv/ 129 | ENV/ 130 | env.bak/ 131 | venv.bak/ 132 | 133 | # Spyder project settings 134 | .spyderproject 135 | .spyproject 136 | 137 | # Rope project settings 138 | .ropeproject 139 | 140 | # mkdocs documentation 141 | /site 142 | 143 | # mypy 144 | .mypy_cache/ 145 | .dmypy.json 146 | dmypy.json 147 | 148 | # Pyre type checker 149 | .pyre/ 150 | 151 | # pytype static type analyzer 152 | .pytype/ 153 | 154 | # Cython debug symbols 155 | cython_debug/ 156 | 157 | # PyCharm 158 | # JetBrains specific template is maintained in a separate JetBrains.gitignore that can 159 | # be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore 160 | # and can be added to the global gitignore or merged into this file. For a more nuclear 161 | # option (not recommended) you can uncomment the following to ignore the entire idea folder. 162 | #.idea/ 163 | 164 | # DS_Store 165 | 166 | .DS_Store 167 | 168 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Welcome to GitHub Playground 🛠️🐙 2 | 3 | This is your go-to space to experiment, learn, and maybe have a little fun with GitHub. Whether you're a coding newbie or just brushing up on the basics, these exercises will guide you through the essentials of GitHub, one task at a time. 🎢 4 | 5 | Each exercise has a fun theme and clear goal to keep you on track. Plus, we threw in a few emojis just for flair. 🚀 Ready to level up your GitHub game? Let’s dive in! 🌊 6 | 7 | 8 | 9 | ## Beginner Exercises 🐣 10 | 11 | 1. **Explore the GitHub Interface** 🖱️ 12 | 13 | Spend some time snooping around the GitHub interface. Check out tabs like **Code**, **Issues**, **Pull Requests**, **Actions**, and **Settings**. 14 | **Goal**: Get comfy with the layout and start feeling like a GitHub pro! 15 | 16 | 2. **Create Your First Repository** 🐱 17 | 18 | Head over to GitHub, click that shiny **New Repository** button, and name it `my-first-repo`. Add a README to introduce your project. 19 | **Goal**: Experience the thrill of creating your very own repository. 20 | 21 | 3. **Add a Description to Your Repository** ✏️ 22 | 23 | Add a brief description and relevant tags under **Settings** to make your project stand out. 24 | **Goal**: Metadata matters! Improve organization and discoverability. 25 | 26 | 4. **Create a New File Directly on GitHub** 🗂️ 27 | 28 | No command line needed! Just create an `about.md` file directly on GitHub and write a few words about your project. 29 | **Goal**: Master the art of in-browser edits for quick, on-the-go changes. 30 | 31 | 5. **Edit a File Directly on GitHub** 📝 32 | 33 | Tweak your `README.md` or `about.md` right in the GitHub editor, then save it with a clear commit message. 34 | **Goal**: Get comfortable with fast, direct edits to keep your project updated. 35 | 36 | 6. **Clone a Repository to Your Local Machine** 📥 37 | 38 | Bring your repository from GitHub to your local setup with `git clone`. 39 | **Goal**: See how to pull projects from the cloud down to earth. 40 | 41 | 7. **Make Your First Commit** ✍️ 42 | 43 | Add some local changes, then stage and commit them with `git add ` and `git commit -m "message"`. 44 | **Goal**: Lock in your edits and start tracking changes like a version control wizard. 45 | 46 | 8. **Push Your Changes to GitHub** 🚀 47 | 48 | Send your local commits back to GitHub with `git push`. 49 | **Goal**: Keep your remote repository up-to-date with your latest changes. 50 | 51 | 9. **Create and Switch to a New Branch** 🌿 52 | 53 | Start a new branch called `feature-branch` with `git switch -c feature-branch`. 54 | **Goal**: Discover the magic of branches and avoid breaking your main codebase! 55 | 56 | 10. **Make a Pull Request (PR)** 🔄 57 | 58 | Make some edits on `feature-branch`, push it, and open a PR to merge with `main`. 59 | **Goal**: Practice the PR flow to collaborate and get code reviews like a pro. 60 | 61 | 11. **Resolve a Merge Conflict** ⚔️ 62 | 63 | Create a merge conflict by editing the same line in both `main` and `feature-branch`, then resolve it. 64 | **Goal**: Learn to handle conflicts with grace under pressure. 65 | 66 | 12. **Fork Another Repository** 🍴 67 | 68 | Fork [this GitHub Playground repository](https://github.com/Maras13/git_playground) and bring it to your own account. 69 | **Goal**: Forking lets you contribute to projects or even build on them independently! 70 | 71 | 13. **Make Changes on a Forked Repository** 🔄 72 | 73 | Clone your forked repository, make a small edit, and push it back to GitHub. 74 | **Goal**: Practice making contributions to projects you don’t own. 75 | 76 | 14. **Submit a Pull Request to the Original Repository** 📨 77 | 78 | From your fork, open a PR to the original repo with your edits. 79 | **Goal**: Contribute to open-source projects and become part of the GitHub community. 80 | 81 | 15. **Explore GitHub Insights** 📊 82 | 83 | Visit **Insights** on one of your repos and check out analytics like Contributors and Commits. 84 | **Goal**: Learn to monitor project activity and keep track of contributions. 85 | 86 | 16. **Star and Watch a Repository** ⭐️👀 87 | 88 | Give [GitHub Playground](https://github.com/Maras13/git_playground) a star, and `Watch` it to stay updated on changes. 89 | **Goal**: Show some love to your favorite projects and follow their progress. 90 | 91 | --- 92 | 93 | Now you’re ready to take on GitHub like a pro. Each exercise is a small step toward mastering version control, collaboration, and the amazing open-source community on GitHub. So dive in, and may your commit messages be clear and your merge conflicts be few! 94 | 95 | 96 | 97 | 98 | 99 | 100 | -------------------------------------------------------------------------------- /advanced/README.md: -------------------------------------------------------------------------------- 1 | # 🧙‍♂️ Advanced Git Wizardry: Exercises to Master Version Control 🛠️ 2 | 3 | Congratulations, Git master-in-training! 🎓 You're about to embark on a journey through the labyrinth of advanced Git techniques. Let’s push your skills to the next level! 🚀 4 | 5 | --- 6 | 7 | ## **🧵 Exercise 1: Advanced Branch Management** 8 | 9 | 1. Create a repository with the following structure: 10 | 11 | main ├── featureA ├── featureB 12 | 13 | 2. Create branches `featureA` and `featureB` from `main`. 14 | 3. On `featureA`, modify a file and commit the changes. ✍️ 15 | 4. On `featureB`, modify the **same file differently** and commit the changes. 😱 16 | 5. Merge both `featureA` and `featureB` into `main`. Resolve the epic merge conflict. ⚔️ 17 | 6. Visualize the battle scars using `git log --graph`. 18 | 19 | **🎯 Goal:** Conquer branching, merging, and conflict resolution like a Git ninja. 🥷 20 | 21 | --- 22 | 23 | ## **🪄 Exercise 2: Interactive Rebase** 24 | 1. Create a branch `rebase-exercise` and make five commits. (Go wild with creativity! 🎨) 25 | 2. Decide that two commits in the middle were... a terrible idea. 😬 26 | 3. Use `git rebase -i` to erase them from history like they never happened. 🧠 27 | 4. Squash the last two commits together into a glorious masterpiece. 🏆 28 | 29 | **🎯 Goal:** Clean up your commit history like a pro janitor. 🧹 30 | 31 | --- 32 | 33 | ## **🍒 Exercise 3: Cherry-picking** 34 | 1. Create a branch `bugfix` and make **two unrelated commits** fixing different bugs. 🐞 35 | 2. Switch back to `main`. (Don’t panic. Stay calm. 🧘) 36 | 3. Cherry-pick just **one of the commits** to `main`. 37 | 4. Confirm that only your chosen commit was applied. 🎯 38 | 39 | **🎯 Goal:** Selectively apply the creme de la commit. 🍰 40 | 41 | --- 42 | 43 | ## **🔍 Exercise 4: Bisecting** 44 | 1. Create a repository with 10 commits. Hide a pesky bug in one of them. 🐛 45 | 2. Use `git bisect` to find the bug like a Git detective. 🔎 46 | 47 | **🎯 Goal:** Master the art of debugging with precision and flair. 🕵️ 48 | 49 | --- 50 | 51 | ## **🛠️ Exercise 5: Stash Management** 52 | 1. Make a change to a file but don’t commit it. (You rebel, you. 😎) 53 | 2. Stash the change using `git stash`. 👜 54 | 3. Make additional changes and stash them too. 55 | 4. List all your stashes like a treasure map. 🗺️ 56 | 5. Apply the **first stash selectively** and drop the remaining stash like a hot potato. 🥔 57 | 58 | **🎯 Goal:** Master temporary changes and stash away your secrets. 🤐 59 | 60 | --- 61 | 62 | ## **📦 Exercise 6: Submodules** 63 | 1. Create a main repository and a separate repository for a library. 📚 64 | 2. Add the library as a submodule to the main repository. 65 | 3. Make a change in the library and update the submodule in the main repo. 66 | 4. Use `git submodule update` to sync changes like a boss. 🤖 67 | 68 | **🎯 Goal:** Manage submodules without losing your sanity. 🧠 69 | 70 | --- 71 | 72 | ## **📜 Exercise 7: Advanced Logging and Searching** 73 | 1. Clone a repository with a hefty commit history. (The more, the messier! 🐘) 74 | 2. Use `git log` with options (`--author`, `--grep`, `--since`, etc.) to find: 75 | - Commits by a specific **author**. 🕵️ 76 | - Commits containing a specific **keyword**. 🔑 77 | - Commits made after a specific **date**. 📅 78 | 3. Use `git blame` to figure out who did what, line by line. 😏 79 | 80 | **🎯 Goal:** Log and search like a Git historian. 📖 81 | 82 | --- 83 | 84 | ## **😵 Exercise 8: Detached HEAD State** 85 | 1. Check out a specific commit using its SHA (enter the **detached HEAD state**—spooky! 👻). 86 | 2. Make some changes and commit them. 87 | 3. Switch back to a branch and merge the changes from your detached state. 🪄 88 | 89 | **🎯 Goal:** Embrace the detached HEAD state and wield it wisely. 🧙 90 | 91 | --- 92 | 93 | ## **⚔️ Exercise 9: Advanced Conflict Resolution** 94 | 1. Create three branches (`feature1`, `feature2`, `feature3`) that **all modify the same lines** in a file. 🔥 95 | 2. Merge `feature1` and `feature2` into `main`, resolving the ensuing conflict. 🥊 96 | 3. Finally, merge `feature3` into `main` and resolve the next conflict. 97 | 98 | **🎯 Goal:** Become the ultimate merge conflict warrior. 🏅 99 | 100 | --- 101 | 102 | ## **💡 Exercise 10: Custom Git Aliases** 103 | 1. Define custom aliases for frequently used Git commands (e.g., `git lg` for a visual log). 🎨 104 | 2. Test your aliases in a variety of situations. 105 | 3. Share your alias magic with your team and become their hero. 🦸 106 | 107 | **🎯 Goal:** Make Git your obedient servant with custom aliases. 🐶 108 | 109 | --- 110 | 111 | ## Ready to Git It Done? 💪 112 | Don’t just sit there staring at the screen! Clone, branch, stash, and bisect your way to glory. 🏆 Let me know if you get stuck—after all, even wizards need a mentor sometimes. 🧙 113 | 114 | --------------------------------------------------------------------------------