Skip to this tutorial if you have enrolled in SGV in Estia 1a.

Up until now, How did you manage modifications while working on a collaborative project? Did you name the same file: internship_report.pdf, internship_report_v1.pdf, internship_report_v2.pdf, internship_report_v2_Final.pdf? Then did you send this file to Alice Martin just to receive internship_report_v2_Final_AM.pdf, and went on having internship_report_v1_Final_AM_2.pdf, ... internship_report_v1_Final_AM_2_Finale.pdf...

Maybe you used google drive, or Microsoft OneDrive, to manage the different version of your files. You have shared a file in the cloud that automagically save every changes made by you and your collaborators. Maybe you know about a revision system that tracks individual change, and you came back on a previous version. But working concurrently on a same section or on different files is not easy.

All the previous systems (saving backups, using cloud solutions) are version control system, albeit not very good ones a software development project.

From the Git handbook:

A version control system, or VCS, is a system that tracks the history of changes as people and teams collaborate on a project together. As the project evolves, teams can run tests, fix bugs, and contribute new code with the confidence that any version can be recovered at any time. Developers can review project history to find out:

• Which changes were made?
• Who made the changes?
• When were the changes made?
• Why were changes needed?

A distributed version control system (DVCS) is a type of version control where the complete codebase — including its full version history — is mirrored on every developer's computer. It's abbreviated DVCS.

From the Git handbook:

Git is an example of a distributed version control system (DVCS) commonly used for open source and commercial software development. DVCSs allow full access to every file, branch, and iteration of a project, and allows every user access to a full and self-contained history of all changes. Unlike once popular centralized version control systems, DVCSs like Git don’t need a constant connection to a central repository. Developers can work anywhere and collaborate asynchronously from any time zone.

Some of the ressources used to create this page, Git handbook

Learn how to change something in the project and publish the change to the world.

At the end you will know :

• Create an group repository
• Create a local repository
• Make and stage your modifications
• Commit your progress with a message.
• Push your commit to a group repository

git-101-Ex1

In collaborative project, several people will modify the code base concurrently, and sometimes multiple changes will affect the same file. When you push your commit these concurrent changes must be merged. Some merges can happen automatically, - because they affect different files or different parts of a file for example. Some merges will result in a conflict, that you will need to resolve. While good team organization (exercice 3)) will allow you to reduce the number of these conflicts, they are a normal part of the process that you'll need to address serenely.

At the end you will know :

• How to pull modifications from the group repository
• perform concurrent Commit from several members of the group
• pull and resolve conflict

Detailed Instructions can be found there

In collaborative project, several contributors will modify the code base concurrently. A good organisation of the work will enable you to share your work, review the work of other and integrate contributions into a coherent body of work.

At the end you will know :

• How to stage your modifications
• Commit your progress with a significant message.
• Push your commit to a group repository

Detailed Instructions can be found there

Some references additional references: git flow

Now, we will enter the programming part of the project. See this small tutorial next.