My workflows

fvPMC
1. bare repositories are indicated by .git suffix.
2. develop and master are two parallel upstream branches
3. tmp branches can originate from either one. Usually tmp branches are meant for some
local temporary cases (e.g., pureScattering). They will rarely merge back to master (one
exception early on was tmp_kPlanckTab). If they are merged back to master, they are
to be deleted. If they do not merge back, but may be needed again in future, they may
not be deleted. Name convention:
a. From master: tmp_feature
b. From develop: devtmp_feature
4. hotfixes can originate from master only. They are used for small bug fixing. They
should be merged back to master and deleted.
5. new feature branches can originate only from develop. They are named
dev_feature. Once the feature is ready, they should merge back to develop and
follow a release cycle.
6. release branch can originate from either one. release from master usually will be for
critical bug fixes, whereas release from develop is usually for adding new feature. Both
develop and master branch must be sync-ed at every release point. release branches
should be deleted after merging to corresponding main branch. Name convection
releaseX.Y
a. Sync-ing at release: Lets say, master had a critical bug fix and a new release 1.1
is committed and pushed there
i. go to develop branch
ii. checkout master
iii. git pull master
iv. switch to develop
v. git merge --no-ff --no-commit master (--no-commit make
sure it is not automatically committed. So inspect before committing)
vi. Resolve conflicts and comment: “SYNC: Merged master at
release 1.1 into develop”
vii. The tag from master will automatically come to develop now
viii. git push origin develop
7. release tags are as follows:
a. 1.0 was the first git tag
b. n.x would be a major change (e.g., from tmp_kPlanckTab)
c. if x>9, automatically move to n=n+1 and reset x counter.
d. n.xy would be yth small bug fix of n.x release
e. if y>9, automatically move to x=x+1 and reset y counter.
 f. Full release (n=n+1) would come with some major change, e.g., parallel/ fully
preprocessor directive MMAP / FSK-MCRT, etc.
8. You can revert to any old commit by:
a. git checkout SHA1 .
9. You can retrieve any deleted branch by:
a. git clone file:///home/sro/repositories/fvPMC.git x
b. git checkout --detach SHA1. SHA1 is the commit SHA1. This will create
a DETACHED-HEAD
c. Now the local copy do not exist on any branch. To get back to master or any
other branch, simply git checkout <existing-branch>. Now your local
DETACHED-HEAD copy will be lost; to get that back do git checkout
--detach SHA1 again
d. You can do local commits on a DETACHED-HEAD for testing, etc. But you cannot
directly merge that to any real branch of the repository.
10. Whenever you git push a branch for the first time, you actually create a remote
branch origin/branch. git branch -r lists all remote branches and git branch
-a lists all branches at the working directory, local and remote
11. Once pushed, anyone can clone that branch and work
12. When you commit, all your changes are stored locally, they will not be published to the
repository unless you do a git push. So collaborators won’t see those changes when
they clone.
13. Once the development of the branch is complete, merge it master or develop and
delete the branch locally by git branch -d branch and delete from remote by git
push origin :branch. Now no one can clone that branch. They can however,
checkout the commit of that branch from master or develop
14. In general, hotfix_branch should not be needed to pushed to remote, tmp_branch
and dev_branch may be needed to pushed to remote.

Git diff using vimdiff: git difftool -t vimdiff -y

To remove an already tracked file: git rm --cached lib/file.f and add it to gitignore as
*lib/file.f

sprayPMC
Yet to be developed

Branch deletion:
http://gitready.com/beginner/2009/02/02/push-and-delete-branches.html

Pushing existing local repositories to github with changelogs.

1. Create an empty repository in github. Do not create README, gitignore, etc at this time
2. Checkout the local repo on local machine
3. On local checkout:
a. git remote set-url origin
https://github.com/spr177/repo.git
b. git push -u origin master
c. Switch to other branches and push them upstream, e.g.
i. git checkout develop
ii. git push -u origin develop
4. Done