Git on Teams

Git in the final projects

In the final projects you will have to manage a Git repository to work all the Team together, there are many ways to do it, but these are our recommendations:

  • Separate front-end and back-end code: Create one repository for the back-end code and another one for the front-end code, or in the same repository create a folder for the back-end and a different folder for the front-end, but take into account to manage the folders and package.json properly without breaking others work

  • One Team, One Repo: Create the repositories in the account of one member of the team, and grant the others students to work there. The other members should clone directly the repository, DO NOT FORK IT! if you fork it every member of the team will work in an independent repository adding difficulties to manage merges of work

    • To give push privileges to other team members, go to your repository in GitHub, and click Settings->Manage access -> Invite a collaborator

  • Use a Git strategy: once you divide your work in different functionalities and are assigned to team members, to reduce the number of merges and do not involve everybody in the common files, you should have a strategy to work

  • Assign a Git Release Manager: Assign a member of the team that knows all the code structure and will be the best member to join all functionalities together. The Migracode Team and mentors will help this member to solve conflicts and manage the versions of the project.

  • Use gitignore: Check this link

Small Teams

Git strategy

There are strategies with more branches and more structured, like the common strategy in companies, but taking into account number of people, the criticality of our software and to not spend many hours merging. We recommend you this strategy for the final project!

  • 3 type of branches: master, develop and developers branches

  • 2 user roles: Release Manager and Developer

Branches:

  • master: The master branch stores the official release history, the versions that we will show to the client or to the class after each sprint.

  • develop: The develop branch serves as an integration branch for features. Once develop has acquired enough features for a release, those will be tested before merge it with master.

  • developer branches: Each new developer has a branch with their name, as dev-john or john. developer branches are created from develop and the developer will always work there.

Roles:

  • Release Manager: is the one that manages master and develop. This user, that at the same time is a Developer, do all merges between developers branches and develop. Also is the one that creates versions in master.

  • Developer: all the members on the team are developers, they develop the assigned features in the branch.

Main actions and commands

First steps:

Create the repositories (Release Manager):

  • Create and add write and push privileges to all developers

  • Create a new branch develop from master:

    • git checkout master be sure you are on master branch

    • git checkout -b develop Create the branch develop from master

    • git push -u origin develop Push the local branch to remote, so it is published on Github and other members can see it

  • Create a new branch for each developer from develop:

    • git checkout -b dev_john

    • git push -u origin develop

Move to working repositories (all developers):

  • Each developer should get the new branches from remote and move to the assigned branch:

    • git fetch --all Get all new branches created

    • git checkout dev_john Move yo your name branch

Daily work:

  • All developers should commit and push all your work

    • git add .

    • git commit -m "new feature"

    • git push

End of a sprint:

Create the sprint version (Release Manager):

  • git checkout develop

  • git fetch --all

  • Merge develop branch with the branch of each developer

    • git merge dev_john

    • git add .

    • git commit -m "merge with john"

    • git push

  • Check that all functionalities are working together, have a meeting to check the version and fix all integration or merge problems

  • As a closed version, move the code to master:

    • git checkout master

    • git merge develop

    • git add .

    • git commit -m "merge with john"

    • git push

  • Go back to your working branch

    • git checkout dev_me

Update your working branches with last version (all developers)

  • git fetch --all to get last version of all branches

  • git merge develop

  • git add .

  • git commit -m "merge with develop"

  • git push

Main companies

Here you can find an example on how to manage planned and unplanned (with bugs) versions of a software. More information

  • master: The master branch stores the official release history, for each published version a tag is assigned with a version number

  • hotfix: is the branch we use to fix bugs from the published version as soon as possible, without adding new features. As we can see in v0.1 version the software has a bug, we fix it in the Hotfix branch, and then we merge it directly with master. Also this change is added to develop branch for future versions.

  • release-xxx: release branches are created from develop, to have a version that should be tested in detail to become a new version, if during the test some bugs are found are fix directly in this branch. xxx is the name o the release

  • develop: The develop branch serves as an integration branch for features. Once develop has acquired enough features for a release, a new release branch is created to test it before go to master.

  • feature-xxx: Each new feature with name xxx, should reside in its own branch. But, instead of branching off of master, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with master.