bastelfreak/GIT.md Secret

## GIT.md

      
    Raw
  

              GIT.md
            
          
    GIT

Documentation


https://git-scm.com/book/en/v2/Getting-Started-Git-Basics
https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control

Initialize a new repository

git init
Check the status

git status

Check for changes

git diff

Adding files to the staging area

git add bla

Commit all staged files

git commit

Commit all changes in tracked files

git commit -a

Commit all changes in tracked files + supply a commit title

git commit -am 'blablub'

Pretty log (requires a configured alias)

git lg

Show all branches

git branch -av

Switch to an existing branch

git checkout branchname

Create a new branch

Create a new branch, based on the current one, and switch to it
git checkout -b bla

Create a new branch, based on the supplied one, and switch to it
git checkout -b mynewbranchname myexistingbranchiwanttouseasabase

Merge a branch

merges branch bla into the current branch
git merge bla

Remotes

Listing all remotes
git remote -v

Adding one
git remote add nameoftheremoteiwanttouse urloftheremote

Fetching infos from the remote
git fetch nameoftheremoteiwanttouse

Rename a remote
git remote rename nameoftheremoteiwanttouse mynewawesomename

Change the url of a remote
git remote set-url mynewawesomename git@github.com:jenkinsci/puppet-jenkins.git

Delete a remote
git remote remove mynewawesomename

commit messages

Notes about changes and commit messages:

Every change has to be tested and developed in our testing infrastructure
The deployment has to be automated
Changes will be tracked in Git
Changes are provided as pull requests from a feature/bugfix branch

Each PR should not exceed 200 changed lines (explanation)
Make commits of logical units
Check for unnecessary whitespace with "git diff --check" before committing
Commit using Unix line endings (check the settings around "crlf" in git-config(1))

core.autocrlf = input for linux git clients
core.autocrlf = true for windows git clients


Do not check in commented out code or unneeded files
The first line of the commit message should be a short description (50 characters is the soft limit)
The body should provide a meaningful commit message, which:

uses the imperative, present tense: "change", not "changed" or "changes"
includes motivation for the change, and contrasts its implementation with the previous behaviour
Make sure that you have tests for the bug you are fixing, or feature you are adding
Make sure the test suites passes after your commit (if such a suite exists)


When introducing a new feature, make sure it is properly documented
Each change has to be provided as a Pull Request from a feature/bugfix branch and process a peer review
Add a proper newline to each file as described in the POSIX standard


Read this article

This is based on the VirtAPI-Stack CONTRIBUTING.md. Here is also a note about the commit message (please read also the details here):
Three stages of git


Working directory (untracked files)


Staging area (stuff that will be committed)


.git (commits are stored here)


git config

you can use this file as ~/.gitconfig
[push]
  default = simple
[user]
  name = Tim Meusel // Please replace this
  email = tim@hosteurope.de // Please replace this
  signingkey = BF1C4CC0 // Please replace this with your key id
[merge]
  tool = kdiff3
[alias]
  # Usage: git signoff-rebase [base-commit]
  signoff-rebase = "!EDITOR='sed -i -re s/^pick/e/' sh -c 'git rebase -i $1 && while test -f .git/rebase-merge/interactive; do git commit --amend --signoff --no-edit && git rebase --continue; done' -"
  # Ideally we would use GIT_SEQUENCE_EDITOR in the above instead of EDITOR but that's not supported for git < 1.7.8.
  # See http://cat.pdx.edu/~hunner/git-lg.png for an example
  lg = "log --pretty=format:'%C(yellow)%h%C(reset) %C(blue)%an%C(reset) %C(cyan)%cr%C(reset) %s %C(green)%d%C(reset)' --graph --date-order"

[commit]
  gpgsign = true

This configures your git client to always sign commits and to use the correct username + email address
vim config

It is a good idea to use an editor that tells you about the state of the git repo (unstaged files, outdated...). One example is https://github.com/bastelfreak/scripts/blob/master/vimrc
You need to execute the commands in line 3-5 to use it (they are not in the correct order, fiddle that out by yourself)
Git workflow

For new files and scripts:


Open an issue on the Jira board


Put it on team review


Team will review it in a daily standup


Put it on progress, add some notes about the standup if something was discussed


Use Jira to create a new branch in the correct repo, tag it properly with Issue/Bugfix/Whatever


Open a pull request as soon as you have code to review


Label the pull request with [WIP] (work in progress) if you're still developing it


Put the issue on Code review if you think you're done, than somebody will review this


People will approve this once it is done


You should be able to merge your own pull request when it got approved