# other musings related to git

## what should the default master branch be for?
the master branch should contain the most recent development version.
the question that can be used to decide what the master branch should be for is what version of the codebase someone who clones a repository without specifying a branch should receive, since they will get the master branch by default. switching branches is easy. should clones without explicit branch copy the development version or a stable version? from the perspective of a developer, who checks out the repository to contribute to the project, it would probaly be ideal to receive the most current development version, so they can start developing immediately without searching for the right branch and switching. from the perspective of an end-user of the application, it would be desirable to have "master" be a stable version, but git repositories are mainly for versioning source code in development, git repositories are primarily for developers also because end-users do not need git features as much and it is more complicated anyway than say downloading and extracting an archive file, besides requiring a git client. so why optimise a git repository for end-users

### other arguments
#### "master should be stable for automatic deployment"
that does not make sense since it does not matter which branch is automatically deployed. automatic deployment is an automated process where the source and branch has to be configured in any case

#### "master is central and that corresponds to the existence of our unique most current stable version"
the general development state is also unique and it is more likely that there are more stable or release branches than the most current development branch where new features are continuously merged in

## git flow
git flow is a set of tools and a specification of how to use git and branches that has gained popularity. but it is overcomplicated and not worth the effort. with extra commands, software wrappers and many forced requirements for the branching process (must use tags, must use hotfix and release branches, master is stable and branch named "develop" is added, et cetera) it introduces many sources of errors and ways to get into an unclean state. every developer has to install the utility applications. the actual benefit is not even that distinct because it is basically just feature branches

# how to write commit messages
* check out how the commits are done on [kernel.org](https://kernel.org/) (where git originated), see the "browse" links
* use imperative present tense,  just because it makes words shorter: "add ipv6 support" instead of "added ipv6 support"
* "network module: implement support for ipv6"
* "network utilities: ip verifier: ipv6 parsing"
* do not prefix tags to every commit message with things like "-feature-, -bugfix-" or similar without a good reason. most of the time there is no benefit situation in having them. they add noise to commit messages, making it harder to choose the right commit when the need arises to choose a previous commit in the worst case, and make readers always skip the first n characters in the best case. if you really need tags, consider adding them to the end of the message
* remember that much of the most important information is already tracked by git: the list of files that has changed in a commit. query git or use a git log format to show the files changed per commit, like "git-log" in [sph-script](https://github.com/sph-mn/sph-script)

# other tips
* if changes can be introduced from multiple remotes, use a separate branch for each remote. otherwise frequent merge conflicts are likely if changes from other servers are incorporated at the wrong times
* branches can be of different histories. for example you can push the contents of a repository to a new branch on a completely different repository

# links
* comparison of some workflows: [atlassian.com/git/tutorials/comparing-workflows/](https://www.atlassian.com/git/tutorials/comparing-workflows/)
* update email and other author information in history commits  [changing-author-info](https://help.github.com/articles/changing-author-info)