====== Version Control with git ====== {{:git_slides.pdf|Slides}} ====== Exercises ====== ====== Single developer and local repository. ====== Instructions: below you can find a list of steps you are requested to follow using a shell and issuing the appropriate git commands. You are requested to write down those same commands within this text file just after each instruction item. This will help you by keeping track what you did and for discussing with tutors. This file is a helpful place where to store your comments and notes about the exercise. Run the 'git' command and read carefully the output. It is quick way to revise some of the contents of the lecture. Ask git about what it knows of the current directory. Hint: in git terminology this is called "status". It is expected that git knows nothing about the current directory. Isn't it? It is time to introduce yourself to git. Set the global git variables "user.name" and "user.email" according your personal information. Hint: check out the slides of the lecture. Verify that git has correctly stored your name and email. Hint: read "git help config" to find out the way to get them. Create a proper directory where you want to host a simple project named "kindergarten". The current directory (e.g., home) is usually fine but you could want a more meaningful place. Then move into the directory you created. Just remember that all files and directories in /tmp/ are thrown away at each reboot. Create a new git repository within the current directory. Verify that you have a brand new ".git/" directory full of interesting things. Ask git about the status and check out what changed with respect the last time you issued that command. Create a file named hello.py that prints some salutation (unexpected uh?) Ask git about the status and check out what changed with respect the last time you issued that command. Put hello.py in the staging area. Ask git about status and check out what changed with respect the last time you issued that command. Now record changes to the repository. Check status again, it is instructive. Edit hello.py some more. Like importing numpy and printing some random numbers, like np.random.rand(3). See how the status changes accordingly. Show changes between current and staged files. Add changes into the staging area (index). Show how the status changes accordingly: Edit again hello.py , e.g., adding another print statement. Commit *only* changes from the staging area: Verify that changes not added to the staging area were not recorded: Commit all changes in hello.py without going through the staging area: Edit hello.py again adding some lines, the create a new file clock.py which imports the module 'time' and prints 'time.ctime()'. Inspect status and changes before commits. Commit all changes made in all files skipping staging area where possible. See the logs of all commits. See the logs of all commits with the GUI. Go crazy and mess with your files. Overwrite content and/or remove files. Oh no! What I've done! Shame on me! Verify that status and differences. Get rid of the last untracked changes and verify everything is back to normal. And relax: your work is safe. ====== Multiple developers and one remote shared repository. ====== Instructions: below you can find a list of steps you are requested to follow using a shell and issuing the appropriate git commands. You are requested to write down those same commands within this text file just after each instruction item. This will help you in keeping track of what you did and in discussing with tutors. This file is a helpful place where to store your comments and notes about the exercise. ===== Scenario 2a : "user of a remote repository". ===== In this scenario we are just users of a remote repository where one or more developers push the code. Clone the git repository [[ssh://@python.g-node.org/git/git-exercise]] Check the status of the repository 'git-exercise'. Ask git about the URL of the remote repository. Read and execute social_network.py to understand what it does. From time to time new code is pushed by developers towards the remote shared repository. You want to fetch these updates to your local repository. (This might not happen in this very moment, but keep your fingers crossed or try fetching multiple times). Inspect how the logs changes accordingly. See the logs from the graphical interface. It is more instructive if see all possible branches (hint: use "--all" flag). Merge the updates within your working tree. Hint you might need to specify "origin/master" to indicate from where to retrieve updates. Inspect how the logs changes accordingly. Execute the script social_network.py again to see the effects of latest updates. See what changed after merging from the graphical interface. Go back to the previous commit. Hint: the last commit is called HEAD, the last but one HEAD~1 etc. Verify that the last updates are not in the log anymore. Verify that the last updates are not merged from the logs' graphical interface. Pull the latest changes and merge them immediately Verify that merge succeeded from the graphical interface. Verify that the logs show the latest pull. ===== Scenario 2b: "local development of a remote project" ===== Task 1: create a new file within the directory "people/" called after your name and surname: .txt . Within that file write a short list of people you know (other students, lecturers, friends, family etc.) one name per line in the form of "name surname". Execute social_network.py and check that it shows correctly the information you have just provided. Add your new file people/ to the staging area. Commit changes in the staging area. Check how the log changes accordingly, both from the shell command and the graphical interface. ===== Scenario 2c: "from local developer to contributor" ===== You want to share your recent changes with other developers. So now you push them remotely. WARNING: the remote repository could have recent updates from other developers that you do not have yet, so your push attempt might fail. In that case you need to pull first. But it instructive to try to push first and see the error. See how the logs of all branches (-all) reflects your push. ===== Scenario 2d: conflicts! ===== Task 2: you want to add a new feature to the social network graph: a better title. Edit social_network.py or social_network.py and improve the title of the graph. Execute social_network.py to verify that your code works well. Commit changes to your local repository. Pull from the remote repository before pushing. WARNING: a conflict could raise. Resolve it by editing the appropriate file. Then add and commit the change to resolve the conflict. Try again to send your changes to other developers.