GitHub Repo Branch

A GitHub Repo Branch is a git branch in a GitHub repository.

• Context:
  • …
• Example(s):
  • GitHub Main Branch.
  • GitHub Staging Branch.
  • GitHub Development Branch.
  • …
• Counter-Example(s):
  • AWS CodeCommit Branch.
  • …
• See: GitHub Repository Tag, Pull Request, Git.

---

---

References

• https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-and-deleting-branches-within-your-repository

2019

• https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-branches
  • QUOTE: ... Use a branch to isolate development work without affecting other branches in the repository. Each repository has one default branch, and can have multiple other branches. You can merge a branch into another branch using a pull request.

    You can use branches to:

    • Develop features
    • Fix bugs
    • Safely experiment with new ideas

2013

• http://datasift.github.io/gitflow/Versioning.html
  • Version Numbers And GitFlow Branches. Here’s what to build from which branch.
    • Feature branches and the develop branch should always build snapshot versions (e.g. 2.6.0-SNAPSHOT201205012).
    • Release branches and hotfix branches should always build release candidate versions (e.g. 2.6.0-0.rc1).
    • The master branch should always build unqualified versions - versions without build numbers (e.g. 2.6.0).

2011

• http://stackoverflow.com/questions/5400460/git-manage-each-version-of-my-app

I would recommend using tags (tag tutorial)
From your master branch since you are done v1.0 add a tag called v1.0.
  git tag -a -m "Tagging release 1.0" v1.0
This way you can always come back to a specific version at any time by calling git checkout [tag_name]
Another common practice is to use branches to work on features until they are stable.
  git checkout -b [feature-branch]
That creates a new branch named whatever is in [feature-branch] and checks it out. Be sure to do this from where you want to start working on the feature (typically from master).
Once stable they can then be safely merged into master. From master run:
  git merge [feature-branch]
This way your master branch always stays in a working state and only completed items get added once ready. This will allow you to keep a working copy of the app at all times (ideally anyways) for testing, etc.
You could use branches for each version of the application however using tags makes it so you can't merge into another branch version by accident.

2010

• http://nvie.com/posts/a-successful-git-branching-model/
  • … The repository setup that we use and that works well with this branching model, is that with a central “truth” repo. Note that this repo is only considered to be the central one (since Git is a DVCS, there is no such thing as a central repo at a technical level). We will refer to this repo as origin, since this name is familiar to all Git users.

---