Setup repository with a master
branch and a dev
branch. dev
should be made the default branch.
All development should be worked on in respective branches and merged into dev
. See branch naming and merging guidelines below.
Master
should contain the most recent published/released copy. See merging guidelines below.
category/master
category/github_username/short_description
-
category
examples:sample_code
,guidebook
-
keep this consistent within a project
-
each
category
should have its own master branch
-
-
short_description
should explain whatgithub_username
is working on in that branch
-
Pull request: select
merge pull request
option -
Via command line: Using
merge
will maintain the true history of the development work.
git checkout category/github_username/short_description
git merge category/master
-
Pull request: select
squash and merge
option -
Via command line: Using
rebase
will maintain a linear timeline for clarity. Squash new commits into one during the interactive rebase.
git checkout category/master
git rebase -i dev
Merging dev
into master
-
Pull request: select
merge pull request
option -
Via command line:
git checkout dev
git merge master
Proposing changes to your work with pull requests
Git commit messages should be thought out and not rushed. This message provides other users with a way to understand what changes you made in your commit.
A proper git commit message should follow a standard format.
The standard commit message is as follows:
type(category): subject — footer
for example: feat(guidebook): added title-page
-
feat
— A new feature. -
fix
— A bug fix. -
docs
— Changes to only documentation. -
style
— Changes to formatting (missing semicolons, etc.). -
refactor
— A code change that neither fixes a bug nor adds a feature. -
test
— Adding missing or correcting existing tests. -
chore
— Change to build process or auxiliary tools, or maintenance.
This should correspond with the branch names.
The subject should be limited to 50 characters and be descriptive of the changes. If there are multiple things changed, consider splitting into smaller commits (use git add -p
).
Git Workflow Etiquette - Better Programming
git add -p # stage only some changes within file(s)
git rebase -i HEAD~n # can be used to squash last n commits
git reset --soft HEAD^ # undoes the last commit and saves stage
git stash, git stash pop # temporarily saves local changes