GitHub

• Both, GitLab and GitHub are web-based Git repositories.

Now, we’re taking it a step further to unite development and operations in one user experience.
GitLab is a repository manager which lets teams collaborate on code. Written in Ruby, GitLab offers some similar features for issue tracking and project management as GitHub.

Authentication Levels
With GitLab you can set and modify people’s permissions according to their role. In GitHub, you can decide if someone gets a read or write access to a repository.
With GitLab you can provide access to the issue tracker (for example) without giving permission to the source code. This is obviously great for larger teams and enterprises with role-based contributors.

Built-in CI / CD & going Beyond CD
One of the big differences between GitLab and GitHub is the built-in Continuous Integration/Delivery of GitLab
GitLab offers their very own CI for free.
And if you are already used to an external CI, you can obviously integrate with Jenkins, Codeship and others.
offering a operations dashboard that lets you understand the dependencies of your development and DevOps efforts.

https://usersnap.com/blog/gitlab-github/

• There are two main types of development models with which you'd use pull requests. In the fork and pull model, anyone can fork an existing repository and push changes to their personal fork without needing access to the source repository.

This model is popular with open source projects as it reduces the amount of friction for new contributors and allows people to work independently without upfront coordination.

In the shared repository model, collaborators are granted push access to a single shared repository and topic branches are created when changes need to be made.
This model is more prevalent with small teams and organizations collaborating on private projects.
https://help.github.com/articles/about-collaborative-development-models

• Use GPG keys to sign your work locally and verify work from trusted collaborators.

You can generate a GPG key and add the public key to your GitHub account

Using GPG, you can sign and verify tags and commits. With GPG keys, tags or commits that you've authored on GitHub are verified and other people can trust that the changes you've made really were made by you.

https://help.github.com/articles/signing-commits-with-gpg/

• Now, what we need to do is create "profiles" for each of our keys.

Host bluffington
  User git
  HostName github.com
  IdentityFile ~/.ssh/doug.funnie@bluffington.edu

Host beets
  User git
  HostName github.com
  IdentityFile ~/.ssh/doug.funnie@beets.fm

First, notice that we're creating two hosts bluffington and beets, each one mapped to a separate IdentityFile which...points to the private keys we created earlier
Remember that earlier we learned this enables us to use a different user per-repo by setting our remote URLs to use the appropriate profile. Following that logic, we should get URLs like these with the two profiles above

we're suggesting that we're authenticating against two Github accounts.
The first, blufftech has a repo bluffbot that we're working on. The next, beetsrock has a repo beetbox.

git@bluffington:blufftech/bluffbot.git
git@beets:beetsrock/beetbox.git

By pointing to git@bluffington and git@beets respectively, we point to the appropriate IdentityFile value.


Using an SSH config file can save a lot of time when working with Git.
Using SSH is slightly more secure because it doesn't require you to physically enter a username and password.
SSH keys can be deleted and regenerated, just like a password. If your private key accidentally leaks, just delete it from the respective site and generate a new one!

https://themeteorchef.com/tutorials/setting-up-an-ssh-config-file

• Who Has Multiple SSH Keys?

A freelancer with multiple clients is likely to face this problem if several clients each run their own GitHub.com projects and only want users to use a company-issued email address registered. As such, your existing GitHub user couldn’t simply be added to their projects and you need to register for a new GitHub account to access each.
https://medium.com/@trionkidnapper/ssh-keys-with-multiple-github-accounts-c67db56f191e

• Understanding ~/.ssh/config entries

    Host : Defines for which host or hosts the configuration section applies. The section ends with a new Host section or the end of the file. A single * as a pattern can be used to provide global defaults for all hosts.
    HostName : Specifies the real host name to log into. Numeric IP addresses are also permitted.
    User : Defines the username for the SSH connection.
    IdentityFile : Specifies a file from which the user’s DSA, ECDSA or DSA authentication identity is read. The default is ~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for protocol version 2.
    Port : Specifies the port number to connect on the remote host.
https://www.cyberciti.biz/faq/create-ssh-config-file-on-linux-unix/

• This post is for people who need to work on repositories owned by different GitHub accounts, for example their personal one and their “work account” part of their company’s team

In order to use git config --local we need to be inside a repository directory: the keys will be written to the ./.git/config file rather than ~/.gitconfig (used when configuring with --global). These config values will only apply to that specific repo, but they will also override any property already set at the higher --global or --system levels.
So, while the --local configuration usually only contains repo-specific stuff like the remotes’ URLs or the branch names, we can execute this to add extra keys:

cd repo_dir
git config --local user.name "Name Surname"
git config --local user.email "name.surname@company.com"
http://tommaso.pavese.me/2014/07/08/git-config-for-multiple-github-accounts/

• Github offers another useful service called Gist that developers often use to dump their code snippets but Gists aren’t just for geeks and coders — they offer something for everybody. If you have ever heard of web apps like Pastebin or Pastie, Gist are similar but more polished, they are free of advertising and loaded with more features

You can choose to have a secret Gist that will not be visible to search engines but only to those who know the URL of that secret Gist.
https://www.labnol.org/internet/github-gist-tutorial/28499/

• With gists, you can share single files, parts of files, and full applications with other people. Directories can't be shared. You can access your gists at https://gist.github.com.

Public gists
Public gists show up in Discover, where people can browse new gists as they're created. They're also searchable, so you can use them if you'd like other people to find and see your work. After creating a gist, you cannot convert it from public to secret.
Secret gists
Secret gists don't show up in Discover and are not searchable. Use them to jot down an idea that came to you in a dream, create a to-do list, or prepare some code or prose that's not ready to be shared with the world. After creating a gist, you cannot convert it from public to secret.

https://help.github.com/articles/about-gists/

• .gitignore

Git sees every file in your working copy as one of three things:
    tracked - a file which has been previously staged or committed;
    untracked - a file which has not been staged or committed; or
    ignored - a file which Git has been explicitly told to ignore.

Ignored files are usually build artifacts and machine generated files that can be derived from your repository source or should otherwise not be committed. Some common examples are:

    dependency caches, such as the contents of /node_modules or /packages
    compiled code, such as .o, .pyc, and .class files
    build output directories, such as /bin, /out, or /target
    files generated at runtime, such as .log, .lock, or .tmp
    hidden system files, such as .DS_Store or Thumbs.db
    personal IDE config files, such as .idea/workspace.xml

https://www.atlassian.com/git/tutorials/saving-changes/gitignore

• Pros vs Cons

Monolithic Repo Pros:
    A single repo can contain all the related applications.
Most of the available CI services won't distinguish / makes difficult to run tests for a particular app in a monolithic repository
https://github.com/IcaliaLabs/guides/wiki/Monolithic-vs-Micro-Repos

• The question is whether we should create a new repository for each new module or try to keep as much as possible in a single so-called "monolithic" repo. Market leaders, like Facebook and Google, advocate the second approach

https://dzone.com/articles/monolithic-repos-are-evil