Scenario 2 : Collaboration

Let’s say you were given a presentation project involving two other members. Each member decides to handle different aspects of the presentation:

  • person A – gets related images, updates their captions and handles the slides transitions
  • person B – handles the text content of each slide
  • person C – writes up the script for each slide

This all happens in one File.pptx . Without a version control system, if all 3 persons made updates to the Powerpoint presentation file, you may probably need to wait on one another to save his/her own version as to prevent possible overwriting.

In reality, each person would have his/her own copy of the initial (empty) pptx file, which then gets “merged” a couple of days before the day of presentation via copy and paste technique.  However with GIT, this process could run smoother.We will be using GITHUB and our friendly command line.

Create New Repository

Person A creates a remote repository on git-hub, makes it public and shares its link. Person A, B and C have their own personal laptops so they could work on the presentation individually.

Create a new repository

Making your repository public

using github to host remote git repository

Clone existing remote Repository

How could each group member’s work/version be obtained ? You copy/ clone the repository.

cloning the empty remote repository









But wait.. there isn’t an existing .pptx file in the repository. Yea, because it is empty. For that reason, a Powerpoint file is to be created and saved into the remote git repository, so that everyone could have access to the initial pptx file.

Accordingly, person A creates a new Powerpoint file and saves it into his local repository (as shown above) called Powerpoint-presentation. However at this point, no one but him has the file. To expose it to person B and C, the local branch has to be sent or  “PUSHED” to the remote git(hub) repository. Before that, three actions should be made :

  1. git add <FILE>
  2. git  commit -m <message>.
  3. git pull origin master

The first two actions registers the new changes while giving it a message  or description, which could be found by viewing the git commit history (run git log). While the last actions simply PULLS the possible changes made by your friends stored in the remote repository. This is similar to you copying and pasting all the changes person B and C made to your own version of the presentation and saving it.

Before moving forward, you should “test” if the changes from person B or C did not negatively affect your version of the presentation. If not problem was found, then expose your version to your group members by pushing it to the remote repository, which was tagged “origin” locally. The command to run is as follows:

git push origin master 

This simply pushes all changes made in the “master” branch to remote repository tagged “origin”. If there is another branch called “stable”, where the tracking history is to be pushed, how would the command look then ?

git push origin stable

What if the the remote repository wasn’t named “origin” ? figure out the actual name by running command git remote and git remote show <name>.

git push <name> stable

Now your changes have been made public

There are probably three branches in the remote repository, each for the group members. How is obtaining the full presentation possible? By merging

Useful Links

  1. what is the difference between tag and branch with git?
  2. How is a tag different from a branch in Git?
%d bloggers like this: