summary.
Edit me
git rebase vs merge
| Golden rule | merge | rebase |
|---|---|---|
| 🍂Use merge in cases where you want a set of commits to be clearly grouped together in history 🍂Use rebase when you want to keep a linear commit history 🍂 DON’T use rebase on a public/shared branch 🍂 gitbucket 🍂git checkout feature && git checkout -b temporary-branch && git rebase -i main [Clean up the history] git checkout main && git merge temporary-branch 🍂 git pull –rebase |  |
 |
| git checkout master && git merge feature | git checkout feature && git rebase master |
Git team of one
Git team
workflow
Create and customize step-by-step documentation for your team on how to use Git in your own work flow
• basic tools to document your team’s process;
• where documentation should be placed;
• what types of things need to be documented; and,
• sample states for your ticketing system
Example
+Product Manager [Name]
-Dev site [URL] Branch deployed on dev site [name of branch]
+Live site [URL]
-Branch deployed on live site [name of branch]
+When starting a dev ticket, branch from [name of branch]
-When starting a hotfix ticket, branch from [name of branch]
+When updating your work, use [git command]
-When merging your work, post review use [git command]
ghi cli: The most commonly used ghi commands are:
list List your issues (or a repository's)
show Show an issue's details
open Open (or reopen) an issue
close Close an issue
edit Modify an existing issue
comment Leave a comment on an issue
label Create, list, modify, or delete labels
assign Assign an issue to yourself (or someone else)
milestone Manage project milestones
color the shell output for git: add below in .gitconfig You can also fine control what you want to have coloured in what way, e.g.
[color]
diff = auto
status = auto
branch = auto
interactive = auto
ui = true
pager = true
[color "status"]
added = green
changed = red bold
untracked = magenta bold
[color "branch"]
remote = yellow
diagram and workflow gui
github pages documentation for visibility and dns
git pull/merge strategy
Branching strategies
• how to choose a branching convention for your team.
• mainline development
• branch-per-feature deployment
• scheduled deployment
×Note: Know when to increment with semantic versioning In semantic versioning, a release should always be numbered as follows: MAJOR.MINOR.PATCH. The first number (MAJOR) should be incremented when you make API-level changes which are not backwards compatible. The second number (MINOR) should be incremented when you add new functionality which does not break existing functionality (it is “backwards-compatible”). The third number (PATCH) should be incremented when you make backwardscompatible bug fixes.
