Master Version Control with GitHub in Computer Science 209.1
Dive into the world of version control using GitHub, a powerful platform for code hosting and collaboration. Learn how to utilize repositories, branches, commits, and Pull Requests efficiently. Discover the process of creating repositories, managing branches, and working with files both locally and on GitHub. Enhance your understanding of the master branch, branches, and how they facilitate seamless project development in the realm of computer science.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Version Control with GitHub Computer Science 209 1
What is GitHub? A code hosting platform for version control and collaboration Facilitates collaboration Uses repositories, branches, commits, and Pull Requests Available as command-line or GUI 2
Downloading GitHub Desktop The GUI provided by GitHub https://desktop.github.com/ You must also make a GitHub account 3
Repositories A repository is usually used to organize a single project Repositories can contain anything your project needs Files, folders, images, etc GitHub uses repositories as a controllable folder for your project 4
Creating a Repository in GitHub Desktop 1. Select New repository a. Either on the right side of the screen or under the File menu 2. Name your repository 3. Write a short description 4. Select public or private accessibility 5. (Optionally) Select Initialize this repository with a README 6. Click Create Repository 5
File Location GitHub will manage the files on your local computer for you You can access these files with Ctrl+Shift+F on windows Edits made locally to these files will be detected by GitHub Desktop These files will also update to your current branch of code 6
Master Branch By default the repo has one branch named master The master branch is the "definitive branch" Other branches are created for making edits to the master Once satisfied with the edits, the branch is then committed to the master In general, don't edit the master branch 7
Branches Have you ever saved different versions of a file? story.txt story-liz-edit.txt story-liz-edit-final.txt Branches accomplish similar goals in GitHub repositories Creating a branch off the master branch is making a copy of master As it was at that point in time 8
Making a Branch 1. Go to your repository 2. Click the drop down at the top of the file list that says branch: master 3. Type a branch name into the new branch text box 4. Select the blue Create branch box or hit Enter on your keyboard The branch will be identical to the master until edits are made 9
Switching Branches Selecting the drop-down menu at the top will let you switch between published branches GitHub will automatically change the files on your local computer Give it a little time to update on larger projects Make sure you're on the correct branch before editing any files! 10
Making Edits and Running Programs You can use any editor of your choice on the files in the GitHub repo It behaves just like any other folder on your computer Same for running the code javac, java Saving locally will not save to the repo branch To save to the branch you must commit the edits 11
Committing On GitHub, saved changes are called commits Each commit has an associated commit message A description explaining why a particular change was made Commit messages capture the history of your changes Other contributors can understand what you ve done and why Committing also shows how frequently you are working on your code This will be important for projects 5 onwards 12
Edit and Commit 1. Open the file you wish to edit 2. Make edits 3. Write a commit message a. Describe your changes briefly in the summary bar b. More details can go in the box in the larger text box 4. Click the blue commit button to save to the current branch a. You can select which files are committed with the checkboxes to the left of the files 13
Differences GitHub Desktop will show you a visualization of the changes made Red means removed Green means added 14
Pushing Committing will only update your local repo Making a push request will update the repo online So that other collaborators can see the changes In order to finally accept the new edits as final, a pull request is needed Push by using the blue button or typing Ctrl+P 15
Pull Requests Pull request propose your changes to the rest of your collaborators Requesting that someone review the code Finally pull in your contribution and merge them into their branch Pull requests show diffs (differences) of the content from both branches The changes, additions, and subtractions are shown in green and red 16
More on Pulling Typing @mention in your pull request message will tag that user in the request You can even open pull requests in your own repository and merge them yourself A great way to learn the GitHub flow before working on larger projects 17
How to Make a Pull Request 1. Click the blue "pull request" button a. You must be logged in to GitHub for this page to load b. If you get a 404 error, log in! 2. Fill out information about your edits 3. Click create pull request 18
Finally, Merging When a branch is complete it s time to bring the changes together A branch can be considered complete when one new element is added which does not break the code Everything still compiles, other tests do not crash, etc. This is achieved by merging the branch into the master branch 19
How to Merge a Branch 1. Click the green Merge pull request button to merge the changes into master 2. Click Confirm merge 3. Delete the branch with the Delete branch button in the purple box a. Since its changes have been incorporated it is no longer needed 20
Conflicts The bane of every GitHub user's existence is conflicts between local check-outs of repos If two people change the same file in different ways, GitHub does not know which one to use Avoid conflicts at all costs! Never work on the same file as another user Communicate with your team All else fails nuke it Save your edits somewhere else and check out a new copy of the master branch 21
