VERSION CONTROL AND GIT 1 / 23
PROBLEM SCENARIO 1: WORKING ALONE How do you keep track of changes, and different versions of your work? 2 / 23
SOLUTION? 3 / 23
PROBLEM SCENARIO 2: WORKING IN A TEAM "My changes got overwritten!" "You weren't supposed to change that �le." etc. 4 / 23
SOLUTION? Go with the �ow, and hope nothing breaks? Send emails: “Okay, I'm going to work on A.java, so don't touch it"? 5 / 23
PROBLEM SCENARIO 3: MOVING AROUND (PRE-COVID PROBLEM?) After a hard day of work on a DH lab computer, you want to go home and do some work at home in the evening. 6 / 23
SOLUTION? Copy all the �les to your home machine Issues: potentially slow depending on your �le sizes, you might overwrite something you did at home but forgot to copy from home to school, etc. 7 / 23
A REAL SOLUTION 8 / 23
VERSION CONTROL 9 / 23
VERSION CONTROL Keeps code in a central location ("repository") This is the master copy To make changes to it, you can create a local copy of the repository in your account at school, on your machine at home, on your laptop… 10 / 23
COMMITTING When the local copy changes, "commit" and "push" the changes to the repository. 11 / 23
SOLUTION TO PROBLEM SCENARIO #1: TRACKING CHANGES WHILE WORKING SOLO When you get something working, commit the changes Tools allow you to revert to a previous version Write good log messages so that you don't have to remember what changed in each version 12 / 23
SOLUTION TO PROBLEM SCENARIO #2: WORKING IN A TEAM Each team member has their own version of the code When a team member makes changes, they can commit their code to the central git repository Other team members can pull the changes from the central repository to their local machines and make their own changes, etc. 13 / 23
SOLUTION TO PROBLEM SCENARIO #3: MOVING AROUND A remote git repository can be accessed from anywhere! As long as you always remember to commit and push your most recent changes, you can go to any other machine and clone a local copy of the repository using a URL to your remote repository 14 / 23
COMMON GIT COMMANDS FOR GETTING THE FILES FROM A REMOTE REPOSITORY git clone <repo> <directory> Clone the repository located at <repo> into the folder called <directory> on the local machine. You will now have all the �les from the repository available locally. You will typically use this once (per machine). Do not clone the same repo over and over. Next time you want to get the most recent version of the remote repo �les, just use the command "git pull". 15 / 23
COMMON GIT COMMANDS FOR MAKING CHANGES TO A REMOTE REPOSITORY After making changes to one of these �les, you should use the following commands to keep the remote git repo synchronized with your local copy: 16 / 23
git add <file> or git add --all Add speci�ed <�le> or all edited �les to a "staging area". This tells Git that you want to include updates to a particular �le in the next commit. (Note: This command does not actually change anything! You have to commit your changes �rst.) 17 / 23
git commit -m "<message>" This command captures a snapshot of the project's currently staged changes; you should always provide some sort of message along with a commit to make it easier to keep track of what changes were just made. This commits your changes to your local git repository. 18 / 23
git push Lastly, in order to synchronize your local repo with the remote repo, you must remember to git push. It's a common mistake to commit but forget to push, which means none of your team members working at different locations would be able to see the changes you committed! 19 / 23
MANAGING CONCURRENCY 20 / 23
WHAT IF TWO (OR MORE) PEOPLE WANT TO EDIT THE SAME FILE AT THE SAME TIME? 21 / 23
WHAT IF TWO (OR MORE) PEOPLE WANT TO EDIT THE SAME FILE AT THE SAME TIME? Make sure you're working on the most up-to-date version (git pull will get you the most recently committed versions of all the repo �les) 21 / 23
WHAT IF TWO (OR MORE) PEOPLE WANT TO EDIT THE SAME FILE AT THE SAME TIME? Make sure you're working on the most up-to-date version (git pull will get you the most recently committed versions of all the repo �les) Then, edit the �le you want to edit 21 / 23
WHAT IF TWO (OR MORE) PEOPLE WANT TO EDIT THE SAME FILE AT THE SAME TIME? Make sure you're working on the most up-to-date version (git pull will get you the most recently committed versions of all the repo �les) Then, edit the �le you want to edit Once you're done editing, try to "git commit" and "git push" 21 / 23
WHAT IF TWO (OR MORE) PEOPLE WANT TO EDIT THE SAME FILE AT THE SAME TIME? Make sure you're working on the most up-to-date version (git pull will get you the most recently committed versions of all the repo �les) Then, edit the �le you want to edit Once you're done editing, try to "git commit" and "git push" If someone else edited that same �le, two things might happen 21 / 23
1. DIFFERENT PARTS OF THE FILE WERE EDITED: Git is smart enough to deal with that on its own, and will auto merge your �les, so both sets of changes get committed to the repository. 22 / 23
2. THE SAME PARTS OF THE FILE WERE EDITED DIFFERENTLY BY MORE THAN ONE PERSON This is where you're going to have a scary merge con�ict! Git will let you know that there is a con�ict, mark the con�icting area for you in the �le with <<<<<< ===== and ====== >>>>>> symbols surrounding it. You can now open up the �le where a con�ict is found, look for those symbols, choose which of the con�icting changes you want to keep, delete the symbols, and then re-commit and push. (Video example of this: https://www.youtube.com/watch? v=__cR7uPBOIk ) 23 / 23
Recommend
More recommend
