Branch Naming Convention #14
Replies: 5 comments 5 replies
-
|
issue-number/githubusername/fix-feature-or-refactor/description/ |
Beta Was this translation helpful? Give feedback.
-
|
wondering to keep names a little shorter, like for 74/features/css-added/emmettpenn...can we use a universal team acronyms for longer words like features and contributions. feat for features and contr for contributions? or to shorten up more we can use initials? Thinking that 74 (issure #) and action taken are important to track. 74/features/css-added/emmettpenn 47/contributing/added-name/emmettpenn |
Beta Was this translation helpful? Give feedback.
-
|
I think the shorter name is helpful for sure considering it is difficult to find the branch name as it cuts off in the drow-down menu. I think if we put our initials after the issue-number, it would be easier to find. |
Beta Was this translation helpful? Give feedback.
-
|
stacy, i agree the use of initials, shortens in up more. and there seems to be only a few long types of issues; like contributing or features or user-story. those could be shortened too. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for contributing I will convert some of these ideas into a poll for us to vote and agree upon something hopefully =) |
Beta Was this translation helpful? Give feedback.
-
|
go with shorter; [ 104/bug/favicon-added/ep ] like this. that looks good i believe. What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
I like this. Take note the bug is a good choice for your |
Beta Was this translation helpful? Give feedback.
-
|
shorter naming definitely show better in the drop downs. [ 93/user-story/css-added/ep ] |
Beta Was this translation helpful? Give feedback.
-
|
A better secondary branch name in this scenario would be |
Beta Was this translation helpful? Give feedback.
-
|
The above comments have been converted into a poll which is on the top of this page. Please vote on a naming convention to truly close #9 |
Beta Was this translation helpful? Give feedback.
-
Please Review Below
(taken from the Chingu Handbook, specifically from the Git Workflow section)
Working / Development / Master Branch Workflow
There are multiple workflow models you can choose to adopt, but if you are new
to Git and GitHub, one type of Git workflow is presented here. This model is
based on the assumption that your team will set up a skeleton repo in GitHub
from which all team members will then clone to their computers.
Git Branches
A three-level hierarchy of branches is created, through which changes are
promoted.
they are working on changes and bug fixes. There are 3 basic types of
branches: fix, feature, and refactor. For example:
feature/course-review.working branches, which are then pulled into this branch. All code pulled into
this branch must be tested and undergo peer review as part of the PR process.
branch always reflects the current production release that is seen by live
users.
The Workflow
tasks (like bug fixes).
computers. Commits should be frequent and each commit should have a
discrete, atomic purpose.
GitHub. This ensures that if a computer is lost, stolen, or malfunctions, your
work will still be available to the rest of your team.
individual computer. For example, you'll need to do this if/when you help
another team member with one of their tasks.
to fold it into the development branch. It's always a good idea to require that
PRs be reviewed by another member of the team. This helps to ensure that the
quality of the app is maintained.
should be thoroughly tested together. Then, a Pull Request should be created
in order to move them into the master branch which reflects the code base
that's in Production or soon to be promoted to Production.
release its contents into your Production runtime environment.
Closes Issue #9
3 votes ·
Beta Was this translation helpful? Give feedback.
All reactions