From b66bcf1decb6841807496a85310cf2f2ccfd3e26 Mon Sep 17 00:00:00 2001 From: LeDuble Date: Tue, 28 Feb 2023 13:16:48 +0200 Subject: [PATCH 01/10] revised header section added with feature section --- README.md | 43 ++++++++++++++++++++++++++++++++++++------- 1 file changed, 36 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 2152a23..b465817 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,42 @@ - -

+ +

-Git Etiquette and Cheat Sheet +Git Etiquette

-

This Git Etiquette and Cheat Sheet is made for The Software Developer Team of DigiTalents Helsinki.

+

+ +

+ +

+ Standardized workflow frame for teams and individuals. + +

+ +

+ + + + + + + + + + + + +

+ + +

+ +Features +

+ +- **Git strategy for branching** +- **Issues, labels and project board automation** +- **Git command cheat sheet**

@@ -35,9 +67,6 @@ Table of Contents Introduction

-[![PRs Welcome](https://img.shields.io/badge/PRs-welcome-success)](http://makeapullrequest.com) -[![License](https://img.shields.io/badge/license-CC%20BY--SA%204.0-blue)](https://creativecommons.org/licenses/by-sa/4.0/) - The essence of the Git Etiquette Cheat sheet is to provide standardized workflow frame and foundation for the team. By charishing unified workflow means that it is easier to review and track the current history of the project. People will come and go so it's very vital to maintain excellent etiquette. As this allows anyone to join, any time, figure out the process and track the status of the project with ease. From 8ad28a1fd6ac905f8f5e5a2254f991c84f062caa Mon Sep 17 00:00:00 2001 From: LeDuble Date: Tue, 28 Feb 2023 13:48:39 +0200 Subject: [PATCH 02/10] revised version of the introduction page added --- README.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index b465817..d93b613 100644 --- a/README.md +++ b/README.md @@ -62,19 +62,19 @@ Table of Contents --- -

- +

+ Introduction -

+ -The essence of the Git Etiquette Cheat sheet is to provide standardized workflow frame and foundation for the team. +The main focus of Git Etiquette is to provide a standard way of using Git and project management tools that is shared among developers, which helps to ensure that everyone is on the same page and following the same standardized workflow frame. -By charishing unified workflow means that it is easier to review and track the current history of the project. People will come and go so it's very vital to maintain excellent etiquette. As this allows anyone to join, any time, figure out the process and track the status of the project with ease. +By following the Etiquette, the team can ensure that their workflow will be more consistent, work will be properly documented and their use of the git will be more efficient. +Additionally, it provides clear instructions for using Git, which helps to minimize the risk of errors and improves the quality of the work being done. -Background story for the Etiquette: -I started Git Etiquette Cheat Sheet as my personal project for personal use to create unified and coherent workflow. The main purpose of this was so that others could interpret easier what I'm working with and navigate history effortlessly. +The background story for Git Etiquette is that it was started as a personal project to create a unified and coherent workflow for personal use. The goal was to make it easier for others to understand the work being done and navigate the history of the project more easily. -Team leader (Joonas) heard about it and asked if I could make it for the whole team. +My team leader was excited about my personal project I was working on and assigned me to write it up so that the rest of the team could benefit from it. (back to top) From 8c3507d5bfac673546dbd5da0d9dec76dec2c220 Mon Sep 17 00:00:00 2001 From: LeDuble Date: Tue, 28 Feb 2023 14:08:55 +0200 Subject: [PATCH 03/10] added new featured section --- README.md | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index d93b613..99179e0 100644 --- a/README.md +++ b/README.md @@ -294,13 +294,17 @@ Cheat Sheet --- - +

- -Author + +Featured organizations, teams, and projects that utilize the Git Etiquette

-* [Raja Rana (LeDuble)](https://github.com/LeDuble/) +| VirittΓ€mΓΆ Helsinki | Aava +:-------------------------:|:-------------------------:| + | + + (back to top) @@ -323,6 +327,18 @@ Feed back and suggestions are welcome! --- + +

+ +Author +

+ +* [LeDuble](https://github.com/LeDuble/) + +(back to top) + +--- +

From 497f81fd45da118ff2dd00d035f0c0f9126ee622 Mon Sep 17 00:00:00 2001 From: LeDuble Date: Tue, 28 Feb 2023 15:01:30 +0200 Subject: [PATCH 04/10] adding new section called getting started --- README.md | 342 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 342 insertions(+) diff --git a/README.md b/README.md index 99179e0..a0de720 100644 --- a/README.md +++ b/README.md @@ -80,6 +80,348 @@ My team leader was excited about my personal project I was working on and assign --- + +

+ +Getting started +

+ +
    +
  1. Project board
    2. +
  2. The labels for issues
    3. +
  3. Issues forms and pull request template
    4. +
  4. Workflow file setup
    5. +
  5. Base tree for repository
    6. +
    7. +
+ +(back to top) + + + +

+ +Project Board +

+Here's how you setup your project board, which is a crucial part of automation and project management. + + +#### Views +Project views allow you to view the project from different layouts and are located at the top as tabs. + +Set up for each view: +Name | Layout | Group | Fields +--- | --- | --- | --- +*List view by status* | Table | Status | All, except Milestones +*Board view* | Board | Default | All, except Milestones, Tracks, Tracked by +*List all* | Table | Default | All, except Milestones + +Remember to save changes! + +#### Status +In projects, click the three dots in the top right corner, select Settings, then under Custom Fields, click on Status and add the following statuses (including the emojis): + +* **Backlog πŸ“œ** +* **In Progress 🚧** +* **Ready for Review πŸ”** +* **Done βœ”οΈ** + +Also don't forget to remove any default statuses. + +#### Example +You can view the project board of this repository to get an example of what the project board should look like and how the automation is handled. + +A project board + +(back to Getting Started) + +(back to top) + + +

+ +The labels for issues +

+ +#### Featured labels +* Labels can either be assigned automatically by the automation or manually by the user. It is best to let the automation handle the assignment of labels marked as "automatically" and not add them manually to an issue. +* when a new issue is opened, it will be automatically assigned the "Backlog πŸ“œ" label. If an issue is already labeled as "In Progress 🚧", you can change the label back to "Backlog πŸ“œ" if needed. + +#### Adding labels to the repository +You can add labels by going to the repository, clicking on the Issues tab, and then clicking on the Labels button, which is located next to the milestones option, and now you can start copying these labels by clicking on the New Labels button. + + + + +#### Organization default repository labels +If you plan to use these labels across all of your organization's future repositories, then you can go to your organization's settings, navigate to the repository section under "code, planning, and automation", and click on repository defaults. Then, you can click on the new label button and add the labels. These labels will featured in all of organization's future repositories, but will not be added to already existing repositories, so you will need to add them manually to those. + +Label Name | Description | Manually or Automatically | Label / Status Field +--- | --- | --- | :---: +Docs πŸ“ | Changes to documentation only | Manually | Label +Feat πŸ†• | A new feature | Manually | Label +Style πŸ–ŒοΈ | Changes to formatting (e.g. the code is missing semicolons) | Manually | Label +Test β˜‘οΈ | Adding/correcting existing tests | Manually | Label +Refactor πŸ” | A code change which isn't bug fix or adds a feature. It's restructure of the code without changing the functionality | Manually | Label +BugFix πŸ› | A bug fix | Manually | Label +Chore πŸ‘·β€β™‚οΈ | Maintenance or change to auxiliary tools | Manually | Label +Add βž• | Adding essentials to the repository (e.g. .gitignore or example files) | Manually | Label +Backend βš™οΈ | When a backend issue is opened, it is automatically given to the issue | Automatically | Label +Frontend πŸ–₯️ | When a fronted issue is opened, it is automatically given to the issue | Automatically | Label +Design 🎨 | When a design issue is opened, it is automatically given to the issue | Automatically | Label +Unassigned ❕ | Currently nobody has been assigned to it | Automatically | Label +Unlabeled ❗ | No labels have been added | Automatically | Label +Backlog πŸ“œ | Tasks that have not yet been started or left unfinished | Both | Both +In Progress 🚧 | Currently in the process of being worked on | Manually | Both +Ready for Review πŸ” | A pull request has been created and it is ready for review | Manually | Both +Done βœ”οΈ | Task has been completed or closed | Manually | Both + +* When copying and pasting labels, make sure to include any associated emojis. + +(back to Getting Started) + +(back to top) + + +

+ +Issues forms and pull request template +

+ +Make sure to add the issue form files to the `.github/ISSUE_TEMPLATE` folder in your repository, and the pull request template goes to the `.github` folder. + +Pick them from here: +Issue forms | Pull request template +---|--- +backend-card.yml | pull_request_template.md +design-card.yml | +frontend-card.yml | + + +When creating an issue, depending on which one you pick, the form will automatically add one of the three labels (Backend βš™οΈ, Design 🎨, or Frontend πŸ–₯️). For example, if you select a card related to backend development, it will add the "Backend βš™οΈ" label. + +
    +
  1. Open a new issue inside the repository.
    2. +
  2. Choose one of the cards or templates (Backend, Frontend, or Design).
    3. +
      - For example if you choose the backend card, then the Backend βš™οΈ label will be added.
    +
      - Backlog πŸ“œ label is always added when opening an issue.
    +
  3. Pick one descriptive label from this list: Docs πŸ“, Feat πŸ†•, Style πŸ–ŒοΈ, Test β˜‘οΈ, Refactor πŸ”, BugFix πŸ›, Chore πŸ‘·β€β™‚οΈ, Add βž•
    4. +
  4. you can add another label from this list: In Progress 🚧, Done βœ”οΈ
    5. +
      The label "In Progress 🚧" means that someone is currently working on the issue.
    +
      The label "Done βœ”οΈ" indicates that the issue has been completed or closed.
    +
+ + ```mermaid + + %%{init: {'themeVariables': { 'fontSize': '20px'}}}%% + graph LR; + classDef infoboxcolors fill:#fff2cc, color:#000000; + classDef firstboxcolors fill:#dae8fc, color:#000000; + classDef secondboxcolors fill:#e1d5e7, color:#000000; + classDef thirdboxcolors fill:#d5e8d4, color:#000000; + + subgraph Main + style Main color:#00000000, fill:#00000000, stroke:#f66, stroke-width:2px, stroke-dasharray:5 5 + + subgraph . + style . color:#00000000, fill:#00000000, stroke-width:3px, stroke:#f66 + subgraph 1. + style 1. color:#272B30, stroke:#f66, fill:#f8cecc + end + + X([Open an issue])-->A[Project]; + class X infoboxcolors; + class A firstboxcolors; + end + + subgraph .. + style .. color:#00000000, fill:#00000000, stroke-width:3px, stroke:#f66 + subgraph 2. + style 2. color:#272B30, stroke:#f66, fill:#f8cecc + end + + A-.->XX([Choose
a template]); + class XX infoboxcolors; + + XX-->B((Backend)) & C((Frontend)) & D((Design)); + class B,C,D secondboxcolors; + end + + subgraph ... + style ... color:#00000000, fill:#00000000, stroke-width:3px, stroke:#f66 + subgraph 3. + style 3. color:#272B30, stroke:#f66, fill:#f8cecc + end + + .... -.->XXX([A more descriptive
label
is added
manually]); + class XXX infoboxcolors; + XXX-->E(Docs); + XXX-->F(Feat); + XXX-->G(Style); + XXX-->H(Test); + XXX-->I(Refactor); + XXX-->J(Bugfix); + XXX-->K(Chore); + XXX-->L(Add); + XXX-->R(In Progress); + XXX-->S(Done); + class E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U thirdboxcolors; + end + + subgraph .... + style .... color:#00000000, fill:#00000000, stroke-width:3px, stroke:#f66 + subgraph 3. + style 3. color:#272B30, stroke:#f66, fill:#f8cecc + end + + Frontend & Backend & Design & Backlog -.- XXXX([These labels
will be automatically
added accordingly]); + class XXXX infoboxcolors; + C-->Frontend(Frontend); + B-->Backend(Backend); + D-->Design(Design); + C & B & D-->Backlog(Backlog); + class E,F,G,H,I,J,K,L,M thirdboxcolors; + end + end + + ``` + Schema for labeling. + +(back to Getting Started) + +(back to top) + + +

+ +Workflow file setup +

+ +Variable | Description | Example Organisation / User specific setting | +--- | --- | --- +`username` | | User +`gh_project_token` | | User +`organization_name` | | Organisation +`gh_app_key` | | Organisation +`gh_app_id` | | Organisation +`gh_app_installation_id` | | Organisation +`project_number` | | Both +`project_portfolio_number` | | Both + +### Authentication for user +Create a Personal Access Token (PAT) +1. Let's begin with creating a PAT by going to the personal settings. From there, go to the developer settings and then click on the personal access tokens on the left menu, which opens a menu of two items. Pick the tokens (classic) from the dropdown menu, and then press the button that says "Generate new token" to generate a new token (classic) + +For additional details on creating a PAT, refer to the documents + +2. Select the following scopes (permissions) + * repo - all + * admin:org - write:org + * admin:org - read:org + * project - read:project + +3. Save the given token in to your repository secrets and name it as `SECRET_TOKEN` so that the workflow file knows what to look for. + +### Authentication for organisation (via app) +* Start by creating a Github App under your organization. Follow the instructions in the documents. + +#### App settings +* For the newly created Github App, set the following requirements: + * Repository permissions (8 in total) + * Actions - Read and write + * Checks - Read and write + * Commit statuses - Read only + * Contents - Read and write + * Environments - Read only + * Issues - Read only + * Metadata - Read only + * Pull requests - Read only + * Organization permissions (2 in total) + * Members - Read only + * Projects - Read and write + + * Check the documents to see how to edit the permissions of the Github App. + +* Go to Optional features (in the app) and opt-out from the following setting: + * User-to-server token expiration +* Generate a private key, treat the file like the password and keep it safe. + +#### Installing +* Install the Github App in the organization + * To install the GitHub App in your organization, go to your organization's settings, navigate to Developer settings, select GitHub Apps, click edit next to the app, select Install App, and then click Install. + +#### Secrets +* To make the private key, the GitHub App's installation id, and the App's id accessible to all the repositories in the organization for the workflow file, store the private key as `PRIVATE_KEY`, the GitHub App's installation id as `APP_INSTALLATION_ID`, and the app's id as `APP_ID` as secrets in the organization's settings and actions. + * The private key can be generated within the app itself, by navigating to the app's settings and selecting the Generate Private Key option. + * App id can be found from configuration general page as App ID + * To find the app installation id, navigate to your organization's settings, select Github Apps, and then select Configure next to the app. The `app installation id` can be found now in the address bar, like this: `https://github.com/organizations//settings/installations/` + +#### Finding number of project board +* Go to the project board and then look in the address bar, it should appear like this: `https://github.com/users//projects/` and for the organization it should appear like this: `https://github.com/orgs//projects/` +* Project id is necessary for the automation. + +(back to Getting Started) + +(back to top) + +#### Editing the parameters in WFprojects.yml file +Only the parameters should be changed that are inside the angle brackets (`<>`). For example, ```username: octocat``` or ```project_number: 1``` (remember to remove anglebrackets). + +These parameters can be found org/user related settings in the WFprojects.yml file and are almost at the beginning of the file. + +* User related settings (only edit these). +``` # ----------------- user related settings (only edit these) ----------------- # +username: +gh_project_token: ${{ secrets.SECRET_TOKEN }} +project_number: +``` +* Organization related settings. +``` # ----------------- org related settings (only edit these) ----------------- # +organization_name: +gh_app_key: ${{ secrets.APP_SECRET_KEY }} +gh_app_id: ${{ secrets.APP_ID }} +gh_app_installation_id: ${{ secrets.APP_INSTALLATION_ID }} +project_number: +``` + + +

+ + + +Base tree for repository +

+In the end the base of the repository should look like this: + +```text +. +β”œβ”€β”€ .github +β”‚ β”œβ”€β”€ CODE_OF_CONDUCT.md +β”‚ β”œβ”€β”€ CONTRIBUTING.md +β”‚ β”œβ”€β”€ ISSUE_TEMPLATE +β”‚ β”‚ β”œβ”€β”€ backend-card.yml +β”‚ β”‚ β”œβ”€β”€ design-card.yml +β”‚ β”‚ β”œβ”€β”€ frontend-card.yml +β”‚ β”‚ └── config.yml +β”‚ β”œβ”€β”€ workflows +β”‚ β”‚ └── WFprojects.yaml +β”‚ └── pull_request_template.md +β”œβ”€β”€ .gitignore +└── README.md + +3 directories, 10 files +``` +Excluding .gitignore file. There's topic about .gitignore later in this guide, which I recommend to check out. + + +(back to Getting Started) + +(back to top) + +--- +

From 898b453ca4600a467c529a1a60f0eacfa0d2f3c9 Mon Sep 17 00:00:00 2001 From: LeDuble Date: Tue, 28 Feb 2023 15:16:35 +0200 Subject: [PATCH 05/10] added new git strategy and usage - new section --- README.md | 98 +++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 96 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index a0de720..a429267 100644 --- a/README.md +++ b/README.md @@ -422,9 +422,23 @@ read more about here and how to add it. --> --- + +

+ +Git strategy and usage +

+ +
    +
  1. Bedrock Rules
    2. +
  2. Branch Strategy
    3. +
  3. Formatting Rules
    4. +
+ +(back to top) +

- + Bedrock Rules

@@ -440,9 +454,89 @@ Bedrock Rules * Key sentence: Quality Over Quantity 5. **Always ask if unsure** +(back to Git Strategy and Usage) + (back to top) ---- + +

+ +Branching Strategy +

+ + +The strategy is based on the Git Flow strategy, where each feature (or issue) is represented by a separate branch. Every new branch created is a feature that is being added or worked for the project. The main branch is the production branch, which is the version that is sent to the customer and is always the working one. The dev branch is where all the feature branches are pull requested to aka merged. + +The actual Git Flow strategy also includes release and hotfix branches, which are not included in this strategy. Additonally, version numbering is missing, which might be added later. + +### Strategy guideline + +#### Branches +Name | Description +--- | --- +main | A production branch +dev | A development branch +feature branches | Each issue is one feature branch +#### Merging +* The merge order is from feature branch to development branch, and then from development branch to main branch. This order ensures that changes are tested in the development branch before they are merged in to the main branch. + * Simply said: the merge order is: feature > dev > main. +* Always open pull request from feature branch to dev branch (never to main!). +* Each issue equals to one feature which is represented by one feature branch. +* Always open pull request, instead of merging straight to the branch! This ensures that changes are peer reviewed and any potential problems can be identified before the changes are applied to the branch. Even if the problems were accepted via a pull request, it is still easy to revert back if needed. + +#### Naming conventions for the branches +* In the two next sections, you can find instructions on how to properly format the branches in order to ensure the team is following a consistent workflow and that the branches are properly documented. + +#### + +(back to Git Strategy and Usage) + +(back to top) + + +

+ +Formatting Rules for a Branch (Type/Reference ID/Description) + +

+ +### 1. Type + * **Docs** - Changes to documentation only + * **Feat** - A new feature + * **Style** - Changes to formatting (e.g. the code is missing semicolons) + * **Test** - Adding/correcting existing tests + * **Refactor** - A code change which isn't bug fix or adds a feature. It's restructure of the code without changing the functionality + * **BugFix** - A bug fix + * **Chore** - Maintenance or change to auxiliary tools + * **Add** - Adding essentials to the repository (e.g. .gitignore or example files) + +### 2. Reference ID + Reference the issue from GitHub, Trello or some other agile source. + For now use one of the two formats shown below. + * Referencing an issue from Github: **__issue(_insert number here_)__** or just **__hashtag + number__** (e.g. **_/issue12/_** or **_/#12/_**) + * Referencing from Trello: **__trello(_insert number here_)__** (e.g **_/trello8/_**) + +### 3. Description + Short Description that is 1-3 words long and separated by hyphens aka " - ". + Briefly describes what is done or worked on. + +### Examples + + +Good Examples :+1: | Bad Examples :-1: +------------ | ------------- +:heavy_check_mark: `add/issue12/gitignore` | :x: `something/bug12/do_S*ame<` +:heavy_check_mark: `style/8/added-missing-semicolons` | :x: `hi/TeSt/ÀÀliâ` +:heavy_check_mark: `fix/trello1/serializer` | :x: `fiX/TreLlo1/SeRiAlIzeR` + +**Note:** +Only use allowed special characters which are " / " and " - " when formatting the branch! + +(back to Git Strategy and Usage) + +(back to top) + +--

From 7728c606818efc3bf537fb32923c56c50de577d7 Mon Sep 17 00:00:00 2001 From: LeDuble Date: Tue, 28 Feb 2023 15:22:36 +0200 Subject: [PATCH 06/10] added new section called useful git commands --- README.md | 46 ++++++++++++++++++++++++++++++++-------------- 1 file changed, 32 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index a429267..f04d589 100644 --- a/README.md +++ b/README.md @@ -464,7 +464,7 @@ Bedrock Rules Branching Strategy

- + The strategy is based on the Git Flow strategy, where each feature (or issue) is represented by a separate branch. Every new branch created is a feature that is being added or worked for the project. The main branch is the production branch, which is the version that is sent to the customer and is always the working one. The dev branch is where all the feature branches are pull requested to aka merged. The actual Git Flow strategy also includes release and hotfix branches, which are not included in this strategy. Additonally, version numbering is missing, which might be added later. @@ -580,9 +580,25 @@ Only use allowed special characters which are " / " and " - " when formatting th --- + +

+ +Useful Git Commands +

+ +
    +
  1. How to Create a Branch (via Git)
    2. +
  2. Deleting Branches Locally & Remotely
    3. +
  3. .gitignore
    4. +
  4. Adding .gitignore into already existing repository
    5. +
  5. Merging Branches
    6. +
+ +(back to top) +

- + How to Create a Branch (via Git)

@@ -606,13 +622,13 @@ How to Create a Branch (via Git) * **__`git push --set-upstream origin `__** * (You can do alias for this) -(back to top) +(back to Useful Git Commands) ---- +(back to top)

- + Merging Branches

@@ -625,13 +641,13 @@ Very important: when merging, make sure that you are on the branch that you want Always consult before merging directly as it can conflict with others. It is recommended to do pull request instead. -(back to top) +(back to Useful Git Commands) ---- +(back to top)

- + Deleting Branches Locally / Remotely

Locally

@@ -643,13 +659,13 @@ Deleting Branches Locally / Remotely * Or use this **__`git push origin --delete `__** to remove remote branch. -(back to top) +(back to Useful Git Commands) ---- +(back to top)

- + .gitignore

@@ -657,13 +673,13 @@ Gitignore is essential part of the repository and workflow. It prevents __unnece * https://gitignore.io - on this page you will find ready-made .gitignore templates that you can use in your projects. -(back to top) +(back to Useful Git Commands) ---- +(back to top)

- + Adding .gitignore into already existing repository

@@ -686,6 +702,8 @@ When attempting to ignore a file (or files) that's already tracked in the reposi Becaution here as this will DELETE the file (or files) that is specified in the .gitignore from the github repository. +(back to Useful Git Commands) + (back to top) --- From 0583ec6870a02bfdad3c4a8d7a435b84eb45e321 Mon Sep 17 00:00:00 2001 From: LeDuble Date: Tue, 28 Feb 2023 15:31:30 +0200 Subject: [PATCH 07/10] revised version on how to contribute section --- README.md | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index f04d589..b7463c6 100644 --- a/README.md +++ b/README.md @@ -770,6 +770,8 @@ Featured organizations, teams, and projects that utilize the Git Etiquette How to Contribute

+[![Contributors](https://img.shields.io/github/contributors/LeDuble/Git-Etiquette)](https://github.com/LeDuble/Git-Etiquette/graphs/contributors) + 1. Clone repository and create a new branch: **__`git checkout https://github.com/LeDuble/Git-Etiquette.git -b `__** 2. Add changes to your branch 3. Create a Pull Request with descriptive text. @@ -803,17 +805,4 @@ License You can read the full license [here](https://github.com/LeDuble/Git-Etiquette/blob/master/LICENSE.md) - ---- - - -

- -Future Updates -

-TODO - -- [ ] TODO -- [ ] TODO -- [ ] TODO -- [ ] TODO \ No newline at end of file +(back to top) \ No newline at end of file From b3f204dba2bbc7a490aa7b95816eae2b7ca3e0af Mon Sep 17 00:00:00 2001 From: LeDuble Date: Tue, 28 Feb 2023 15:38:16 +0200 Subject: [PATCH 08/10] added revised version of the cheat sheet section --- README.md | 65 ++++++++++++++++++++++++++++++------------------------- 1 file changed, 35 insertions(+), 30 deletions(-) diff --git a/README.md b/README.md index b7463c6..8095681 100644 --- a/README.md +++ b/README.md @@ -710,39 +710,44 @@ Becaution here as this will DELETE the file (or files) that is specified in the

- + Cheat Sheet

-:large_orange_diamond: Creating a branch | Description -:------------ | :------------: - | -:small_orange_diamond: `git branch -a` | See all available branches -:small_orange_diamond: `git checkout -b ` | Create a new branch -:small_orange_diamond: `git switch ` | Switch between branches - -:large_blue_diamond: Adding files to a branch (not master) | Description -:------------ | :------------: - | -:small_blue_diamond: `git add -i` | Interactive menu -:small_blue_diamond: `git status` | Files tracked by Git -:small_blue_diamond: `git restore --staged ` | Unstage unwanted file(s) -:small_blue_diamond: `git commit -m ""` | Record changes to the repository -:small_blue_diamond: `git push --set-upstream origin ` | Push staged files in to a branch - -:white_medium_square: Merging branches | Description -:------------ | :------------: - | -:white_small_square: `git add -i` | Interactive menu -:white_small_square: `git commit -m ""` | Record changes to the repository -:white_small_square: `git switch master` | Switch to master branch -:white_small_square: `git merge --no-ff` | Merges a branch into master - -:red_square: Deleting branches | Description -:------------ | :------------: - | -:small_red_triangle: `git branch -d ` | Delete local branch -:small_red_triangle: `git push origin --delete ` | Delete remote branch +### :large_orange_diamond: Creating a branch +Command | Description | Frequently used? +------------ | ------------ | :------------: +`git pull` | Before starting a pull command, it is important to make sure that your working copy is clean and free of any uncommitted local changes. To accomplish this, you can use git's Stash feature to save your local changes temporarily so that they are not overwritten when you pull. This will ensure that any changes you make to the repository are safe and secure. | +`git branch -a` | See all available branches | :+1: +`git checkout -b ` | Create a new branch | :wavy_dash: +`git switch ` | Switch between branches | :+1: + +### :large_blue_diamond: Adding files to a branch (not master) +Command | Description | Frequently used? +------------ | ------------ | :------------: +`git add -i` | Interactive menu | :+1: +`git status` | Files tracked by Git | :+1: +`git restore --staged ` | Unstage unwanted file(s) | :wavy_dash: +`git commit -m ""` | Record changes to the
repository | :+1: +`git push --set-upstream origin ` | Push staged files in to
a branch | :+1: + +### :red_square: Deleting branches +Command | Description | Frequently used? +------------ | ------------ | :------------: +`git branch -d ` | Delete local branch | :wavy_dash: +`git push origin --delete ` | Delete remote branch | :wavy_dash: + +### :white_medium_square: Merging branches +note: merging directly to master or main is not generally recommended, always do a pull request! ! ! +Command | Description | Frequently used? +------------ | ------------ | :------------: +`git add -i` | Interactive menu | :+1: +`git commit -m ""` | Record changes to the repository | :+1: +`git switch master` | Switch to master | :+1: +`git merge --no-ff` | Merges a branch into master | :-1: + +### Git Flow Strategy Cheat Sheet as in schema +[![GitFlow](https://github.com/LeDuble/Git-Etiquette/blob/main/imgs/logos_tms_orgs/GitStrategyCheatSheet.png)](https://creativecommons.org/licenses/by-sa/4.0/) (back to top) From 6bab332c8e288adb67561b468c0a9252973219b6 Mon Sep 17 00:00:00 2001 From: LeDuble Date: Tue, 28 Feb 2023 15:45:42 +0200 Subject: [PATCH 09/10] new version of table of contents added --- README.md | 35 +++++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index 8095681..437d0f4 100644 --- a/README.md +++ b/README.md @@ -40,23 +40,34 @@ Features

- + Table of Contents

    -
  1. Introduction
    2. -
  2. Bedrock Rules
    3. -
  3. Formatting Rules
    4. -
  4. How to Create a Branch (via Git)
    5. -
  5. Merging Branches
    6. -
  6. Deleting Branches Locally & Remotely
    7. -
  7. .gitignore
    8. -
  8. Adding .gitignore into already existing repository
    9. -
  9. Cheat Sheet
    10. -
  10. Authors
    11. +
  11. Introduction
    12. + +
  12. Getting Started
    13. + + + + + + +
  13. Git strategy and usage
    14. + + + +
  14. Useful Git Commands
    15. + + + + + +
  15. Cheat Sheet
    16. +
  16. Featured organizations, teams, and projects that utilize the Git Etiquette
  17. How to Contribute
    18. +
  18. Authors
  19. License
    20. -
  20. Future Updates
--- From 4f0e327b0fe915f124d8064f5222d2ba8df4cb49 Mon Sep 17 00:00:00 2001 From: LeDuble Date: Tue, 28 Feb 2023 15:54:11 +0200 Subject: [PATCH 10/10] hotfixed the typos, as described in the issue #51 --- README.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/README.md b/README.md index 437d0f4..36870d8 100644 --- a/README.md +++ b/README.md @@ -52,7 +52,6 @@ Table of Contents -
  • Git strategy and usage
    • @@ -103,7 +102,6 @@ Getting started
  • Issues forms and pull request template
  • Workflow file setup
  • Base tree for repository
    • -
    • (back to top)