학교수업/Git

[Git] 8. Collaboration with Github

hwijin97 2022. 5. 25. 15:42

Github

The single largest host for Git repositories - The central point of collaboration for millions of developers and projects

 

Github and Git

- Github is as remote repository of our project

- By using Git commands, we can work for the project on our local computing machines

 

Github workflow for a private project

Gentralized workflow

- one central hub can accept code and everyone synchronizes their work with it

    - Assumption : all team members have read + write permissions to the shared repository

 

1. Create a remote repository

 - Organize a project (The repository contains folders, files, README, a license file, ... , anything our project needs

2. Clone the remote repository ( to local machine )

 - Create a envrioment to work for the project ( The local repository has a full copy of the remote one )

3. Do some works with the local repository

 - Create a branch for solving issues, make changes, commit the changes, and merge branches ( Changes on the new branch don't affect the "master" branch

4. Synchromize the changes on the local repository with the remote one

 

1. Create a reote repository

git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin remote_repository_url
git push -u origin main

git branch -M main -> default master remain to main

git remote add origin url -> add remote repository as origin

git push -u origin main -> make relation of remote main branch and local main branch

 

2. Do some works with CLI

git  brnach issue1
git checkout issue1
echo "*.a" > .gitignore
git add .gitignore
git commit -m ".gitignore is created"
git branch -vv
issue1 c486bf1 .gitignore is created
* main cda17b [origin/main] first commit

git branch -vv -> can see branch status , issue1 is not related by remote branch, main is related by remote origin/main

git checkout main
git merge issue1
git branch -vv
issue1 c486bf1 .gitignore is created
* main c486bf1 [origin/main : ahead 1] .gitignore is created

now local main branch points commit c486bf1, remote main branch is not changed

git push origin main
git branch -vv
issue1 c486bf1 .gitignore is created
* main c486bf1 [origin/main] .gitignore is created

git push origin main -> now share local commit to remote repository.

 

 

Q: How to contribute to existing porjects

Through forking! - we can create a copy of the projects on a remote repository

: Fokring a repository -> Create a branch -> Adding commits -> opening a pull request

-> Reviewing the code -> Deploying / merging -> Synching

 

Forking vs Cloning

Clone : clone to our local repository. if we clone other developer's Github repository, there is no way to merge our changes...

Forking : clone to our remote repository and can clone, push... and pull request to developer's Github repository, If we fork other developer's Github repository, we can open a pull request for merging our changes

 

Intergration - Manager work flow

A common workflow with hub-based tools like Github - it is good for team-mbased works

Main repository <- Integration manager

Integration manager <(pull request)- Developer public (forked) ... <-> Developer private (local)

 

Distribued workflows

Dictator and Lieutenants (hierarachical) workflow - A variant of a multiple-repository workflow used by huge project

- Developer 1 (D1) can contribute as follows

   -> D1 work on their topic branch

   -> Lieutenant 1(L1) merges the D1's topic branch into his master branch

   -> The dictator merges the L1's master branch into her master branch

   -> The dictator pushes the master branch to the main repository

   -> Other developers pull down

 

Contributing to existing projects

1. Forking projects ( full copy into our remote repositpry, relation with Forked projects )

2. Cloning the forked projects and doing some works ( clone in local repository and some work, )

3. Opening a new pull requset to the original project ( description as detail as possible )

4. Mergin the pull request (by auther or maintainer )

 

Issue tracking

Github's task, enhancement, bug tracking system for our projects

Opening an issue

Assignees - Persons who are responsible for handling the issue

Lables - Categorize different types of issues (issues can have as many labels as you want)

Mentions (@username ) and refferences (#issues_number/#pull_request_number)

- Mentions : the way that we reference other Github users inside of Github issues/pull requests

- Reference : the way that we reference other issues or pull requests related with thecurrent issue

 

 

Documentations for Collaboration

Why should we create documents?

To tell other people

- why your projects is useful

- what other people can do with your project

- How other people can use it

- Who maintains an contributes to your project

- How other people can contribute to your project

 

Documentations

- README

- LICENSE

- CODE_OF_CONDUCT

- CONTRIBUTING

- ISSUE_TEMPLATE

 

README

The first item a visitor will see when visiting your repository

- Github automatically makes a space for showing a README file

 

A README file usually includes

- Project's title that describes the whole project in one sentence

- Project description ( the most important component)

    > what this project does

    > why you use this project

- How users can get started with a project (how users can use a project)

- How to contribute to this project

- Additional information ( development status, lincnse ) for this project

 

LICENSE

You need to license your repository so that others are free to use, charge, and distribute your SW

- Github automatically creates a license file once you choose a lincense for your repository ( LICENSE in the root of the reopsitory )

How to add a license to your repository??

 > visit to https://choosealicense.com  and choose the right license for your project

 > Choose the license when you create the repository for your project

 > Or, create a new file with a file name of "LICESNSE" and choose the corresponding license template

 

CODE_OF_CONDUNT

Establishes expectations for behavior for your projects' participants - It empowers you to facilitate heathy, constructive community behavior

A code of conduct describes

> where the code of conduct takes effect - only on issues and pull requests, or all kinds of community activities

> Whom the codes of conduct applies to - community members, maintainers

> What happens if someone violates the code of conduct

> How someone can report violations

 

How to add a code of conduct to your repository?

- create a new file with a file name of "CODE_OF_CONDUCT" and choose the corresponding code of conduct template (mark down)

 

Other Materials :

> release notes

Describe what changes made on each version update - it is important to thanks to contributors!

> contribution guidelines

Describe rules that contributors should follow to contribute to this project - you can provide a template for an issue or a pull request

> unit test guidelines

Write tests for this project - By providing code examples and how to run them