git shortlog seçeneği

Örnek 

Top contributor kişiyi görmek için şöyle yaparız

> git shortlog -s -n
  830  Ali ...
  506  Ayşe ...
  460  Hakan ...

git remote seçeneği

Giriş

Açıklaması şöyle.

origin refers to the source repository from where it was cloned.

add

git remote add yazısına taşıdım

rename - rename remote repository

Örnek

Şöyle yaparız

$ git remote rename <old_name> <new_name>

set-url - change the address of a remote

Örnek

Şöyle yaparız

$ git remote set-url <name> <new_url>

remove seçeneği

Örnek

Şöyle yaparız

git remote remove origin

show seçeneği

Örnek

Şöyle yaparız

git remote show origin

-v seçeneği

Örnek

Şöyle yaparız

$ git remote -v
ocolak	git@github.com:orcunc/hazelcast.git (fetch)
ocolak	git@github.com:orcunc/hazelcast.git (push)

git reset seçeneği - Staging Area İçin Undo

Giriş
Şeklen şöyle

Şu anki branch'in daha önceki hallerinden birisine geri gelmek içindir. Açıklaması şöyle

git reset —mixed is used to undo changes made in the working directory and staging area.
git merge —abort helps stop the merge process and return back to the state before the merging began.

head seçeneği

-- file veya ~N seçeneği ile kullanılır

Örnek

Commit'lenmiş bir dosyayı silmek için şöyle yaparız.

$ git reset HEAD -- <file>

Örnek

Açıklaması şöyle

It also very common to accidentally push a few changes/files that were not supposed to be committed. Let’s say you had some config files or credentials files like AWS secrets or .pem files. These should not be pushed in the repository. One thing that many people might try in order to remove the pushed .pem from the remote repo is following:

Pull the latest code from the repo.

Delete the .pem file

Create another commit with the deleted .pem file

Push the changes back to remote repo

However in the above approach we haven’t completely removed the .pem from git. You see git keeps a track of all the files that you commit. So anyone can dig into the history of git commits and access the .pem file.

But git allows you to actually modify history. So the solution would be to move back to your safe commit and force push.

git reset HEAD~n is a command that lets you move back to your previous n commits. So git reset HEAD~2 will take you back two commits and will show you the changes of the last two commits.

git reset HEAD --hard will clean all those changes. So for example lets say you have the following commits

Now let’s say you want to remove the last two commits i.e (commit ‘Add aws secrets’ and ‘Add .pem file’)

First you will go back two commits by running the following command:

git reset HEAD~2

Now you can remove those two commits by using the following command:

git reset HEAD -- hard

Now for push the code to remote and your .pem files will be deleted from history as well.

--hard seçeneği

Örnek

Commitlenmiş her şeyi silmek için şöyle yaparız.

git reset --hard HEAD

Örnek - undo commit

Şöyle yaparız

$ git reset HEAD~ //Bir önceki commite gel
$ nano <file> //Dosyayı düzelt
$ git add <file> //Dosyayı tekrar ekle
$ git commit -c ORIG_HEAD //Commitle

git --version seçeneği

Giriş

git sürümünü gösterir

Örnek

Şöyle yaparız

> git --version
git version 2.33.0.windows.2

GitHub CI/CD

Giriş

Kavramlar şöyle

1. Workflow : YAML ile tanımlanır

2. Jobs : Workflow içinde Jobs bulunur

3. Steps : Jobs içinde Steps bulunur

4. Actions : Steps içinde Actions bulunur

5. Events : Workflow nesnesi Events ile tetiklenir

Örnek

Burada bir örnek var. jobs içinde steps var. Her step ise name + uses + with veya name + run ile tanımlı

name: CI Workflow

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
        
      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: 14
          
      - name: Install dependencies
        run: npm install
        
      - name: Build and test
        run: npm run build && npm run test

Workflow

Bir workflow seçilir. Şeklen şöyle

Uses

Bazı hazır gelen şeyler şöyle

actions/checkout@v3

actions/setup-java@v3

actions/cache@v1

Secret

Şeklen şöyle. Settings sekmesinde Security menüsüne gidilir ve altındaki Actions menüsüne tıklanır

Kullanmak için şöyle yaparız

- name: Code Scan Analysis - SonarQube
      env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
      run: ./gradlew sonarqube -Dsonar.projectKey=android-demo-app

Örnek - To Jira

Şöyle yaparız. Github issue'ya "to-jira" diye label verince otomatik olarak Jira issue'su yaratır.

name: Create Issue in Jira when to-jira label added

on:
  issues:
    types: labeled


jobs:
  jira1:
    if: ${{ github.event.label.name == 'to-jira' }}
    runs-on: ubuntu-latest
    steps:
      - name: Test composite one
        uses: hazelcast/github-jira-tool-action@v2
        with:
          JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
          JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}
          JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}
          TARGET_JIRA_PROJECT: HZ
          JIRA_LABEL: from-gh
  

java with maven

GitHub maven yazısına taşıdım

java with gradle

Örnek

Şöyle yaparız

name: Android CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: set up JDK 11
      uses: actions/setup-java@v3
      with:
        java-version: '11'
        distribution: 'temurin'
        cache: gradle

    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
    - name: Build with Gradle
      run: ./gradlew build

Açıklaması şöyle

name : The name of the workflow as it will appear in the “Actions” tab of the GitHub repository. Like here it is “Android CI”

on: Specifies the trigger for this workflow. So here the workflow will be triggered when there is a push event in “main” branch and pull_request event in “main” branch

jobs: A workflow job is a set of steps that execute on the same runner. We can have multiple jobs in a single workflow yml file. Groups together all the jobs that run in the Android CI workflow. Here, in the example there is a single job whose name is build

runs-on: Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. You can use windows and macOS runner too.

steps: Groups together all the steps that run in the build job. Each item nested under this section is a separate action or shell script.

uses: actions/checkout@v3 : The uses keyword specifies that this step will run v3 of the actions/checkout action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will run against the repository's code.

uses: actions/setup-java@v3 : This step uses the actions/setup-java@v3 action to install the specified version of the JDK (this example uses v11) of distribution: 'temurin'

run: chmod +x gradlew: The run keyword tells the job to execute a command on the runner. In this case, you are granting execute permission for gradlew

run: ./gradlew build: In this case you are building the code using gradle

git fetch seçeneği

Giriş

Bu komut ile remote repository'deki değişiklikler bizim repository'e getirilir ama çakışma varsa merge edilmez. 

Örnek
Şöyle yaparız

git fetch origin

SOI-3 Verification Review

Giriş

Gerçek doğrulama yapılır. Sonra test prosedürleri ve test raporlarına bakılır. Bu SOI öncesinde kaynak kod mutlaka konfigürasyon yönetimi altına alınmış olmalıdır. DER beraber test koşturmayı talep edebilir. Ya da zamanlama ile ilgili testleri nasıl yapıyorsun örnek ver diyebilir. Açıklaması şöyle

If you’re only thinking about software verification towards the end of your DO-178C project, you’re doing it wrong.

SOI#3 (Stage Of Involvement) is the verification stage.

Within DO-178C during SOI#3:

  - you will need to provide evidence that you have produced compliance artifacts for each of the verification activities you need to comply with

  -  this is based on your software’s DAL (see my previous post on Design Assurance Levels).

Because of this, it makes sense to begin your verification activities early and not leave verification activities until late in your project life cycle.