# git exercise. 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 # keeping track what you did and 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://@escher.fuw.edu.pl/git/autumnschool/shared/sn # Check the status of the repository "sn". # 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.