1. Multiple people are developing on the same project, pushing commits into the same (e.g. GitHub) repo.
2. Developer A is working, and commits locally.
3. Developer B converts a folder into a Git submodule.
4. Developer A tries to git pull… BOOM – unresolveable conflict, local repo is left in a mess.

The problem is that because Developer A has a local commit, this forces a merge. Git merge has absolutely no idea how to resolve a conflict between a folder and a submodule.

To fix this, divide the merge into two parts, so you can separate the actions of removing the folder, and adding the submodule:

• Figure out the SHA of the commit where the folder was removed; let’s call it abcdef (as far as I am aware you cannot remove a folder and add in the submodule in 1 commit, so there will always be 2 commits here).
• Reset your local repo back to HEAD
• Merge up to that commit: git merge.
• Merge the remaining commits

i.e.

 
git reset --hard HEAD
git merge abcdef
git merge

Alternatively, if only a few commits have been made and you are very lazy, you can do the following:

 
git merge origin~5
git merge origin~4
git merge origin~3
git merge origin~2
git merge origin~1
git merge

Note that if you don’t have local changes, this issue does not occur as the fast-forward mechanism just applies all the commits in sequence and everything is cool.

 
git checkout -b <feature_name>

Develop feature: code test commit rinse repeat.

 
git checkout master
git merge <feature_name>
git branch -d <feature_name>

# Initial 'checkout':
git clone <remote-repository>
 
# Daily process:
cd <local-repository>
git pull
# Make some changes
git add <changed files>
git commit
git push

Setting up a shared git repo:

# Assuming you have an existing project in a git repo called "./project":
mkdir project.git
cd project.git
git --bare init --shared
git --bare fetch ../project master:master
cd ..
scp -r project.git someserver:/some/shared/location
ssh server
sudo chgrp -R group_containing_all_developers /some/shared/location/project.git

Publish branch to remote:

# Create new branch locally:
git branch <branch name>
# Push the branch to the remote repository:
git push origin <branch name>
# Overwrite the local branch with a tracking version:
git branch -f <branch name> origin/<branch name>

Git submodules:

# Add a submodule:
git submodule add <repo> <path>
 
# Cloning a repo with submodules:
git clone <repo>
git submodule init
git submodule update
 
# Updating a project with submodules
git pull
git submodule update

git submodule add <repo> <path>

Cloning a repo with submodules:

git clone <repo>
git submodule init
git submodule update

You have to run ‘git submodule update’ after git pull if you want to update submodules, too.
Always publish the submodule change before publishing the change to the superproject that references it.
It’s not safe to run git submodule update if you’ve made and committed changes within a submodule without checking out a branch first. They will be silently overwritten.

Create new branch locally:

$ git branch <branch name>

Push the branch to the remote repository:

$ git push origin <branch name>

Now for the wrinkle: as mentioned here, the local branch is not yet tracking the remote branch. To fix this, overwrite the local branch with a tracking version:

$ $ git branch -f <branch name> origin/<branch name>

To merge the branch back into the ‘trunk’:

$ git checkout master
$ git merge <branch name>

To delete the local and remote versions of the branch:

$ git branch -d <branch name>
$ git push origin :<branch name>

Initial ‘checkout’:

git clone <remote-repository>

Daily process:

cd <local-repository>
git pull
# Make some changes
git add <changed files>
git commit
git push 

Assuming you have an existing project in a git repo called “project”:

mkdir project.git
cd project.git
git --bare init --shared
git --bare fetch ../project master:master
cd ..
scp -r project.git someserver:/some/shared/location
ssh server
sudo chgrp -R group_containing_all_developers /some/shared/location/project.git