GIT 2 and OOP tasks

So far we've seen how to create a project but how do we join an already existing one. It's simple go to projects Github page. Click on green button saying Code choose the way you want to acquire a copy -> ssh/ hhtp. Open up the terminal, go to the place where you want to clone the project and then clone it:

git clone <link_to_project>

Now you have acquired a copy of codebase to your computer. Be careful, because is not being updated automatically. To grab the latest changes we need to do:

git pull .

This simply tells git to pull latest changes from remote repository (Github). Note that the command is similar to git push but does the exact opposite - it updates the local copy of codebase.

.gitignore

.gitignore is a configuration file used in Git to specify which files and directories should be ignored by the version control system. This is useful for excluding files that don't belong in the repository, such as compiled binaries, temporary files, or sensitive information like passwords.

The file is named .gitignore, and it should be placed in the root directory of your Git repository.

Example:

# Ignore compiled binaries
*.exe
*.o
*.out

# Ignore log files
*.log

# Ignore virtual environment directories (for Python projects)
venv/
__pycache__/

# Ignore compiled bytecode files (for Python projects)
*.pyc
*.pyo
__pycache__/

# Ignore database files
*.db
*.sqlite

# Ignore editor/IDE-specific files and directories
.vscode/
.idea/

# Ignore environment configuration files with sensitive information
.env

Readme.md 📑

A README.md file is a plain text or markdown file commonly found in software projects and repositories. Its primary purpose is to provide essential information about the project, making it easier for users, collaborators, or visitors to understand and use the project. It often serves as the project's documentation, giving an overview of what the project is, how to use it, and other relevant details.

Branching, working within teams

When we are working on a bigger project it is a good practice to NOT PUSH DIRECTLY TO MAIN/MASTER. We usually create feature branch and then work on our feature there, once the work is done we ask our colleagues to review change with Pull Request (We will see what that is shortly). Once we are given feedback and solve all the issues - we are allowed to merge our codebase with the one that is in the main branch.

command to create new branch is:

git checkout -b <branch_name>

Once you start working on it and do the first push, just do git push - git will throw an error but will suggest the correct command on how to set upstream (basically this means that we are mapping the branch from our computer to the one on remote - GitHub, GitLab, bitbucket or whatever you are using)

If you want to change branch, but not create it:

git checkout <branch_name>

Note: git terminal is extremely useful - it gives you suggestions whenever you are doing something wrong. So just keep an eye on terminal messages!

pull requests (merge requests)

As mentioned before once you finish working on the feature and you feel that everything is done - you now should create a pull request and inform your colleagues that they now have to review your changes. This way you get feedback from senior colleagues, maybe some guidance how to fix, implement something etc. You can exchange comments in GitHub and other popular version control platforms. Let's go through quick demo of how typical pull request looks like.

1. I just created a new branch, where I changed name of one of the users. I pushed changes to my new branch and github is showing notification of changes in that branch. You can create pull request by clicking green button:

2. Add a title to your changes and description. You can add reviewer(s) as well:

3. You can see pull request created:

4. Files changes section has all relevant code changes that you as a reviewer would need to see:

Tasks

Exercise 1: Create and Clone Your GIT Repository

• Create a new repository on GitHub. Name it as per your choice.
• Clone the repository to your local machine using git clone <repository_link>.
• Create a new python file in the cloned repository, add some content, and save it.
• Add a README.md file with a brief description of the repository.
• Push these changes back to the remote repository using git add, git commit, and git push.

Exercise 2: Working with .gitignore

• Inside your previoously repository, create a .gitignore file.
• Add rules to .gitignore to exclude files such as .log, .tmp, or a specific folder.
• Create dummy files and folders in your repository that match your .gitignore rules.
• Use git status to confirm that these files are not being tracked.
• Make some changes to the code, and push them to the repository. Are untracked files not included?

Exercise 3: Exploring Basic OOP Concepts

• Write a simple Python class, such as Book, with basic attributes like title, author, availability for a Book
• Include at least two methods that perform actions relevant to the object, like read_book() or change_availability().
• Instantiate your class in a Python script and demonstrate the functionality of its methods.
• Push these changes to your GitHub repository.

Exercise 4: Experimenting with Branches

• In your previously created repository, create a new branch using git checkout -b <branch_name>.
• Make a change in this branch by adding a new file or modifying an existing one.
• Commit the changes and push the branch to the remote repository.
• Merge the branch back into the main branch using GitHub's interface.
• Reflect on the use of branches for feature development and version control.

Exercise 5: Implementing a Multi-Method Class with Pull Request

• Develop a Python class representing a more complex concept. This class should have multiple methods to handle different functionalities (e.g., add_book, borrow_book, return_book, and display_available_books).
• Implement error handling within these methods to deal with common issues like trying to borrow a book that's already lent out.
• Write a short script to demonstrate the functionality of your class by creating an instance and calling its methods.
• Commit your changes to a new branch in your repository and push it to GitHub.
• Create a pull request on GitHub to merge your new branch into the main branch.
• Add one classmate and lecturer as a reviewer
• Reflect on the process of writing a more complex class, handling pull requests, and the importance of code reviews.