Understanding Github and Version Control System.pptx

This presentation is basically to help beginner to understand the concept of GitHub. It can help you gain grasp of GitHub really quick. Part two coming later

1. WHAT IS G I T H U B? Git is a distributed version control system, so each developer has a copy of the repository on their local machine. A remote repository is a copy of the repository that is hosted on a server. Developers can synchronize their local repositories with the remote repository. GitHub is a popular web-based Git repository hosting service. GitHub offers free public and private repositories.

2. To use github To use GitHub, you need to create an account and create or contribute to repositories. You can create a remote repository on GitHub by signing up for a free account and clicking "Create a repository".

3. To use github You can then clone the remote repository to your local machine using git clone. This will create a directory on your local machine that contains a copy of the remote repository.

4. To use github You can make changes to the files in the local repository and then stage and commit those changes. You can push your changes to the remote repository using git push.

5. To use github There are a few ways to avoid having to enter your password every time you push or pull changes. One way is to create an SSH key pair and store the public key in your GitHub profile. Another way is to use a credential helper, which caches your credentials for a time window. There is a built-in credential helper in Git that can be enabled using git config -- global credential.helper cache.

6. To use github git clone https : // github . com / username / repo - name . git C d r epo - name / ls - l code README . md # The code above opens README.md file on VsCode # That is for those using VsCode editor

7. To use github If the repo you clone is private, you likely going to be required to put username and password everytime you and pushing or pulling. To avoid this, the code below would help. It is only going to ask you just once after running the code. git config -- global credential . helper cache git pull

8. What is a remote? Remote repositories allow developers to collaborate on a project from their own machines. There are several Git hosting services like GitHub , BitBucket , and GitLab . You can also set up your own Git server. When working with remote repositories, developers push their local commits to a central repository and pull changes from that repository.

9. What is a remote? Git can automatically merge changes or prompt you to fix merge conflicts. There are different protocols for connecting to remote repositories, such as HTTP, HTTPS, and SSH. HTTP allows read-only access, while HTTPS and SSH allow for access control. Web services like GitHub offer mechanisms to control access to repositories.

10. Working with remotes By default, Git sets up a remote repository with the name origin . You can view information about the remote repository using git remote -v . This command shows the fetch and push URLs for the remote. You can view more information about a remote repository using git remote show < remote_name > .

11. This command shows information like the fetch and push URLs, and the local and remote branches. Remote branches are read-only copies of the branches in the remote repository. You can view remote branches using git branch -r. You can use git status to see if your local branch is up-to-date with the remote branch. cd health - checks / #change directory to the new repo ypu just cloned git remote - v # Code output: origin https : // github . com / redquinoa / health - checks . git ( fetch ) origin https : // github . com / redquinoa / health - checks . git ( push ) git remote show origin git branch - r # Code output: origin / HEAD -> origin / master origin / master Fetching New Changes The git remote show origin command shows information about the remote repository. You can use git fetch to download commits from the remote repository without merging them into your local branch. git log origin/master shows the commits in the remote branch. git status tells you if your local branch is up-to-date with the remote branch. git merge origin/master merges the remote branch into your local branch. git pull is a shortcut for git fetch and git merge and updates your local branch in one step. git remote git remote In [ ]: In [ ]: In [ ]:

12. $ git remote allows you to manage the set of repositories or “remotes” whose branches you track. git remote -v $ git remote -v is similar to , but adding the -v shows more information such as the remote URL. git remote show < name> $ git remote show < name> shows some information about a single remote repo. git remote update $ git remote update fetches updates for remotes or remote groups. git fetch $ git fetch can download objects and refs from a single repo, a single URL, or from several repositories at once. git branch -r $ git branch -r lists remote branches and can be combined with other branch arguments to manage remote branches. The Pull-Merge-Push Workflow When you try to push your changes to a remote repository that has been updated since you pulled, Git may reject your push because your local branch is not up-to-date. You can use git pull to fetch the latest changes from the remote repository and attempt to merge them into your local branch. If there are conflicts between your local changes and the remote changes, Git will stop the merge process and you will need to resolve the conflicts manually. To resolve a merge conflict, you need to edit the file that contains the conflict and remove the conflict markers. Once you have resolved all conflicts, you can stage the file and commit the merge. After you have resolved the conflicts and committed the merge, you can try pushing your changes to the remote repository again.

13. This video covers how to resolve simple merge conflicts. In the next video, they will discuss using branches with remote repositories. Pushing Remote Branches It is recommended to create separate branches for new features or large refactors. This allows you to isolate your work and make it easier to merge changes. To create a new branch and check it out, you can use the git checkout -b < branch_name> command. Once you have made changes to your branch, you can commit them using the git commit command. When you are ready to share your branch with your collaborators, you can push it to the remote repository using the git push -u origin < branch_name> command. The -u flag tells Git to set the upstream branch for your local branch. This will allow you to easily pull and push changes from the remote branch. You can merge branches using either git merge or git rebase . Rebasing rewrites branch history by replaying your commits on top of a new base branch. This can be useful for keeping your commit history linear, but it can also be dangerous if the branch has already been shared with others. Rebasing only works if there are no conflicts between the branches. The video shows how to rebase a feature branch onto the master branch and then merge it in. It also shows how to delete the branch locally and remotely. Here are the pros and cons of rebasing: Pros : Keeps commit history linear and easier to read Easier to understand where bugs were introduced Cons :

14. Can be dangerous if the branch has already been shared with others Requires more manual intervention than merging Can be confusing for other developers who see a rewritten history It is recommended to create a separate branch for refactoring code. This allows you to isolate your changes and make it easier to merge them later. The first time you push a branch to a remote repository, you need to use the -u flag to set the upstream branch. Here are the steps on how to create a git branch for a refactor and push it to the remote repository: Create a new branch using git checkout -b < branch_name> . Make your changes and commit them. Push the branch to the remote repository using git push -u origin < branch_name> . A Simple Pull Request on GitHub Forking creates a copy of a repository that you can make changes to. A pull request is a way to suggest changes to a repository. The pull request can be reviewed by the owner of the repository before being merged. Here are the steps on how to create a pull request on GitHub: Fork the repository that you want to make changes to. Make your changes to the code. Create a pull request from your forked repository. Add a description of your changes to the pull request. Submit the pull request. The owner of the repository can then review your changes and decide whether or not to merge them into their repository. The Typical Pull Request Workflow on GitHub Here are the steps on how to create a pull request using a local copy of the repository:

15. Fork the repository that you want to make changes to. Clone the forked repository to your local machine. Create a new branch in your local repository. Make your changes to the code. Commit your changes to your local branch. Create a remote branch that corresponds to your local branch. Push your changes to the remote branch. GitHub will tell you if your change can be automatically merged. Add a description of your changes to the pull request. Review the diff to make sure it is correct. Submit the pull request. The owner of the repository can then review your changes and decide whether or not to merge them into their repository. Updating an Existing Pull Request Here are the steps on how to address comments on a pull request: Go to the pull request that you want to update. Read the comments from the project maintainers. Make the changes that are requested in the comments. Commit your changes to your local branch. Push your changes to the remote branch. The new commits will be automatically added to the pull request. Squashing Changes Here are the steps on how to squash commits into a single commit using Git rebase: Go to your local repository. Run the command git rebase-i master to start an interactive rebase.

16. A text editor will open with a list of your commits. Change the first word of the line for the commit you want to squash to "squash". Save and exit the text editor. Git will open another editor with the combined commit message. Edit the commit message to include the information you want. Save and exit the editor. Run the command git push -f origin < branch_name> to force push the changes to the remote branch. Note: Squashing commits rewrites history, so only do this on a branch that has not been shared with others. Study guide: Git forks and pull requests Git forks and pull requests GitHub is an open-source platform for collaboration and knowledge sharing, allowing users to explore code created by others. This study guide will provide you with pointers on effectively using the platform to make pull requests in the Git environment. Pull requests Pull requests allow you to inform fellow contributors about changes that have been made to a branch in Git. When pulling requests, you can discuss and evaluate proposed changes before implementing changes to the primary branch. You can eventually merge changes back into the main repository (or repo) by creating a pull request. However, it is important to note that before any changes are made to the original code, GitHub creates a fork (or a copy of the project), which allows changes to be committed to the fork copy even if changes cannot be pushed to the other repo. Anyone can suggest changes through the inline comment in pull requests, but the owner only has rights to review and approve changes before merging them. To create a pull request: Make changes to the file. Change the proposal and complete a description of the change. Click the Proposed File Change button to create a commit in the forked repo to send the change to the owner.

17. Enter comments about the change. If more context is needed about the change, use the text box. Click Pull Request. When creating multiple commits, a number next to the pull request serves as the identifier for accessing the pull requests in the future. This is important because it allows project maintainers to follow up with questions or comments. Pull request merges You can merge pull requests by retaining the commits. Below is a list of pull request merge options that you can use when merging pull requests. Merge commits . All commits from the feature branch are added to the base branch in a merge commit using the -- no–ff option. Squash and merge commits . Multiple commits of a pull request are squashed, or combined into a single commit, using the fast-forward option. It is recommended that when merging two branches, pull requests are squashed and merged to prevent the likelihood of conflicts due to redundancy. Merge message for a squash merge . GitHub generates a default commit message, which you can edit. This message may include the pull request title, pull request description, or information about the commits. Rebase and merge commits . All commits from the topic branch are added onto the base branch individually without a merge commit.

18. Indirect merges . GitHub can merge a pull request automatically if the head branch is directly or indirectly merged into the base branch externally. Key takeaways Pull requests are a crucial tool you can use for efficiently capturing, implementing, and receiving approvals for changes. These capabilities are made possible through collaboration. Practicing pull requests can help you hone your skills and contribute to a project. Code Review What are code reviews? Code reviews are a way to improve the quality of code by having other people review it. Code reviews can help to catch bugs, improve code style, and make sure that code is easy to understand. Code reviews are not about finding fault with the person who wrote the code, but about making the code better. Code reviews can be done in person or using a code review tool. Some projects require code reviews for all changes, while others only require them for changes from people who do not have commit access. Getting feedback from code reviews can help you to improve your coding skills. The Code Review Workflow Here are the steps on how a typical code review is done using a code review tool: The code author submits the code for review. The reviewer adds comments to the code, pointing out any issues or suggesting improvements. The code author addresses the comments by fixing the code, adding tests, or making other changes.

19. The code author marks the comments as resolved or replies to the comments for clarification. Once all comments are resolved, the reviewer approves the code. The code is then merged into the main codebase. How to Use Code Reviews in GitHub Here are the steps on how to address comments on a pull request: Go to the pull request that you want to update. Read the comments from the project maintainers. Make the changes that are requested in the comments. Commit your changes to your local branch. Push your changes to the remote branch. The new commits will be automatically added to the pull request. Some projects may have contribution guidelines that specify how pull requests should be formatted. You can find a link to the contribution guidelines whenever you create a new pull request or issue in a project. It is important to read these guidelines and make sure that your pull requests match them. Managing Collaboration It is important to keep your colleagues informed about large refactors. It is important to write clear code with good comments and documentation. Project maintainers should reply promptly to pull requests. Project maintainers should understand any changes they accept. It is a good idea to have a style guide for your project. Issue trackers are a useful tool for coordinating who does what and when. There are different communication channels that can be used for collaboration, such as mailing lists, IRC channels, Slack channels, and Telegram groups. Tracking Issues An issue tracker is a tool that helps teams track the tasks that need to be done, the state they're in, and who's working on them.

20. Issue trackers can also be used to report bugs and request features. When creating a new issue, it is a good idea to include all of the information that you have about the problem or missing feature, as well as any ideas on how to solve it. Issues can be assigned to collaborators to help track who is working on what. When fixing an issue through a pull request, it is possible to automatically close the issue once the code is merged. This can be done by including a string like "closes:#" in the commit message or pull request description. Continuous Integration A CI system will automatically build and test your code every time there's a change. This can help to catch errors early in the development process. CD is the practice of deploying new code to production frequently. This can help to ensure that new features and bug fixes are available to users as soon as possible. There are a number of tools available for setting up CI and CD, such as Jenkins and Travis. When setting up CI and CD, it is important to be careful about how you manage secrets, such as passwords and API tokens. Terms and definitions CI/CD: The name for the entire continuous integration and continuous deployment system Code reviews: The deliberate and methodical gathering of other programmers to examine each other's code for errors to increase the code quality and reduces the amount of bugs Continuous deployment (CD): New code is deployed often after it has been automatically built and tested Continuous integration (CI): A system that will automatically build and test our code every time there's a change Fix up: The decision to discard commit messages for that commit

21. Forking: A way of creating a copy of the given repository so that it belongs to our user Indirect merges: GitHub can merge a pull request automatically if the head branch is directly or indirectly merged into the base branch externally Issue tracker (bug tracker): A tracker that shows tasks that need to be done, the state they're in and who's working on them Merge commits: All commits from the feature branch are added to the base branch Pipelines: The specific steps that need to run to obtain the desired result Pull request: A procedure where new code is examined before it is merged to create a branch or master branch Squash commits: The decision add commit messages together and an editor opens to make any necessary changes This notebook was converted to PDF with convert.ploomber.io