git workflow

How I use git and gitHub.

Git is super powerful tool with lots of ways to use it. Like with coding, following certain patterns help to avoid lots of troubles here.

Whenever possible, I use a variation of GitFlow, even in my private projects.

Roles

Setting roles is essential for teamwork and for any kind of cooperation.

Even when soloing, it is good to be aware of what role am I in when doing something.

Creates actual content by adding to / improving it. Without implementor, nothing happens.

Is responsible for updating a non-personal branch. There may be a number of managers with personal responsibility scope in big projects.

the master branch represents the "official" state of the project. In case of app development, the deployments reflect the master contents.
- for ideological reasons, main is sometimes preferred over master. Here we talk about branch hierarchies, not importance, so let's keep using "master" for clarity.
the develop branch is for development team and for monitoring.
the feature branch under the develop are essentially bound to an issue list ticket or alike.
the personal branch is exclusively owned by an implementor. It may emerge from a feature branch or be a feature branch itself.

Role: Manager.

Create a new directory containing at least .gitignore and README.md file. The README contains project title, a short description and status statement, e.g. "No useful data yet.";
git init && git add -A && git commit -m "Initial commit"
git remote add origin https://github.com/{OWNER}/{PROJECT}.git
git push -u origin master
# Create 'develop' branch and both are sync it with the central repository
git checkout -b develop && git push --set-upstream origin develop
Now, it may be a good idea to make the develop a default branch of the central repository.

Role: implementor.

git checkout develop && git pull --rebase -- make sure your copy is up-to-date;
git checkout -b <my-ticket> && git push --set-upstream origin <my-ticket>
Now do whatever you like in this branch, but commit and push often!

Role: implementor. Tests run nicely, everything feels fine... but let the others decide.

Send a message to other team members:
- I think I'm done with <my-ticket>. Please check it out and let me know -
- visit https://github.com/valango/git-workflow/pull/new/<my-ticket>
A code review or other form of communication should follow, you may have to redo something.

Role: implementor. Finally, you've got the manager's blessing.

git checkout develop && git pull --rebase -- make sure your copy is up-to-date;
git checkout <my-ticket> -- do not forget this! ;)
git tag -a done#<N> -- by this tag you'll know later what was sent and when;
git rebase -i <branch-root> -- interactively leave only the meaningful descriptions;
git rebase develop -- make sure the merge will be as clean as possible;
git merge <my-ticket>-tmp develop
git push -- update 'develop' branch in central repo.

In case you think you'll need a detailed commit history as it was until the step #4, create a separate branch before it.

In bigger projects, the last 3 steps should be done by manager, so nobody will update the central develop, while other steps in progress.