/
Git workflows

Git workflows

Owned by Selvyn Wright
Last updated: Feb 09, 2020
3 min read

Centralized Workflow

Overview

Everyone develops of master.

Regular commits are essential.

Simulation Setup

You will need two git accounts. A root account where team 1 create the main project repo and to which all other teams get invited. Other teams create their own accounts. In one location on my machine I created the main project and linked it to the root git repo (so this became team 1 repo). I then git cloned from the invited team member’s git repo the project into another location on my machine. So the same project (git repo) was available in two git repos and on two file locations on my single machine, each location tied to a different git account i.e. having different ORIGINS. Follow steps below to repeat the simulation:

  1. One team member (team 1) creates a remote git repo (we will call this the root account)

  2. Invite the other team members from team 2 into this root account. Once they accept, the root repo will appear in their account

  3. Someone in team 1 must set up a project up on their machine (it doesn’t matter what the project looks like but some files and subfolders would be good). Once they create the project structure etc they should push this to the root repo (this becomes the teams - 1 and 2, project structure starting point)

  4. Team 2’s members clone the project. Once cloned they can begin to work on their part of the project (different files and folders preferably)

  5. Team 1 creates assets and pushes them to master

  6. Team 2 creates some assets and attempts to push them to master

  7. A git conflict occurs

     

  8. User git pull --rebase origin master

    1. git pull is like using svn update

    2. --rebase option tells Git to move all of Team 2’s commits to the tip of the master branch after synchronising it with the changes from the central repository. The pull would still work if you forgot this option, but you would wind up with a superfluous “merge commit” every time someone needed to synchronize with the central repository. For this workflow, it’s always better to rebase instead of generating a merge commit.

  9. Team 2 member begins to resolve conflicts if their any, git will indicate there conflicts using the following message

     

  10. Team 2 member can resolve their conflicts using git status, it will show something like

    1.  

      # Unmerged paths: # (use "git reset HEAD <some-file>..." to unstage) # (use "git add/rm <some-file>..." as appropriate to mark resolution) # # both modified: <some-file>

  11. Resolve the conflicts if there are any, then use the following commands

    1.  

      git add <some-file> git rebase --continue

       

  12. Git will move onto the next conflict

  13. Once completed, execute git push origin master

  14. If things get confused and messed up on the merge execute a git rebase --abort, this will revert everything back to the start

Gitflow Workflow