Skip to main content

Commands

Skipped for now
https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols

Authenticating with Git

If you don’t want to authenticate  every time you push, you can set up a “credential cache”. The simplest is just to keep it in memory for a few minutes, which you can easily set up by running git config --global credential.helper cache.
https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage#_credential_caching

Pushing

If we run ... git push <remote> serverfix
Git automatically expands the serverfix branchname out to refs/heads/serverfix:refs/heads/serverfix
Where the general sytax is local:remote..

You can use this format to push a local branch into a remote branch that is named differently. If you didn’t want it to be called serverfix on the remote, you could instead run git push origin serverfix:awesomebranch to push your local serverfix branch to the awesomebranch branch on the remote project.

*You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared. This being said, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s -

  1. The project maintainer pushes to their public repository.
  2. A contributor clones that repository and makes changes.
  3. The contributor pushes to their own public copy.
  4. The contributor sends the maintainer an email asking them to pull changes.
  5. The maintainer adds the contributor’s repository as a remote and merges locally.
  6. The maintainer pushes merged changes to the main repository.
Commit Guidelines

Before you commit, run git diff --check, which identifies possible whitespace errors and lists them for you.

Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
or "Fixes bug." This convention matches up with commit messages generated
by commands like git merge and git revert.

Use git add --patch to partially stage files (covered in detail in https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging#_interactive_staging )

The project snapshot at the tip of the branch is identical whether you do one commit or five, as long as all the changes are added at some point

As a general rule, your commit messages should start with a single line that’s no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation

git log --pretty=oneline shows a terse history mapping containing the commit id and the summary

git rebase --interactive or git rebase -i provides the summary for each commit in the editor it invokes

You may want to use rebase -i <commit hash> to squash your work down to a single commit, or rearrange the work in the commits to make the patch easier for the maintainer to review
https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_rewriting_history

If the config option merge.summary is set, the summaries from all merged commits will make their way into the merge commit message

git shortlog uses summary lines in the changelog-like output it produces -
git format-patch, git send-email, and related tools use it as the subject for emails.

Reflogs, a local history accessible with git reflog, is intended to help you recover from stupid mistakes by providing the hashes along with output similar to git shortlog.

Pull / Merge

The --squash option takes all the work on the merged branch and squashes it into one changeset producing the repository state as if a real merge happened, without actually making a merge commit.

Also the --no-commit option can be useful to delay the merge commit in case of the default merge process.

*
https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project

Patching

To apply a patch generated by format-patch, you use git am (the command is named am as it is used to "apply a series of patches from a mailbox").

If you run a mail client that can save several emails out in mbox format, you can save entire patch series into a file and then use git am to apply them one at a time.

git diff --check, which identifies possible whitespace errors and lists them for you.

 

##

Lutris

##

https://github.com/CVEProject/cvelist

https://github.com/ComplianceAsCode/content


https://github.com/OpenSCAP/openscap-daemon/blob/master/README.md#rest-api

https://github.com/OpenSCAP/openscap-daemon/blob/master/README.md#evaluate-something-else-than-local-machine

 

 

Back to top