...
You will need two git accounts. A root account and then all others get invited into to the repowhere 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 accounts, the git accounts have a shared repoaccount i.e. having different ORIGINS. Follow steps below to repeat the simulation:
One team member (root userteam 1) creates a remote git repo (we will call this the root account)
Invite the other team members from team member 2 into this root account. Once they accept, the root repo will appear in their account
Someone in the team 1 must set the project up, they 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 Other team (this becomes the teams - 1 and 2, project structure starting point)
Team 2’s members clone the project. Once cloned they can begin to work on their part of the project Root user (different files and folders preferably)
Team 1 creates assets and pushes them to master
Team member 2 creates some assets and attempts to push them to master
A git conflict occurs
User git pull --rebase origin master
git pull is like using svn update
--rebase option tells Git to move all of Mary’s Team 2’s commits to the tip of the
masterbranch 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.
Team 2 member begins to resolve conflicts if their any, git will indicate there conflicts using the following message
Team 2 member can resolve their conflicts using git status, it will show something like
Code Block # 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>
Resolve the conflicts if there are any, then use the following commands
Code Block git add <some-file> git rebase --continue
Git will move onto the next conflict
Once completed, execute git push origin master
If things get confused and messed up on the merge execute a git rebase --abort, this will revert everything back to the start
...