Skip to content

Latest commit

 

History

History
323 lines (213 loc) · 18.1 KB

README.md

File metadata and controls

323 lines (213 loc) · 18.1 KB

Welcome

Hey!
Beginner? Do not worry you have came to the correct place.
Here we will give you a brief idea on how to kick start opensource development with github and git.

Table of contents

  1. What is Github?
  2. Lets Begin
    1. Step 1. Create a Repository
    2. Step 2. Create a Branch
    3. Step 3. Make and commit changes
    4. Step 4. Open a Pull Request
    5. Step 5. Merge your Pull Request
  3. Forking Projects
  4. What is Git?
  5. Install Git
  6. Create A New Repository
  7. Clone A Repository
  8. Add & Commit
  9. Pushing Changes
  10. Branching
  11. Update & Merge
  12. Replace Local Changes

Go Resources

Learn

Learn Go Online

Learning resources for specific topics:

Further reading:

  • Newspaper is a topic based newsfeed for slack. Built on Go

What is GitHub?

GitHub is a code hosting platform for version control and collaboration. It lets you and others work together on projects from anywhere.

This tutorial teaches you GitHub essentials like repositories, branches, commits, and Pull Requests. You’ll create your own Hello World repository and learn GitHub’s Pull Request workflow, a popular way to create and review code.


Lets Begin

Step 1. Create a Repository

A repository is usually used to organize a single project. Repositories can contain folders and files, images, videos, spreadsheets, and data sets – anything your project needs. We recommend including a README, or a file with information about your project. GitHub makes it easy to add one at the same time you create your new repository. It also offers other common options such as a license file.

To create a new repository :

  • In the upper right corner, next to your avatar, click and then select New repository.
  • Name your repository say "hello-world".
  • Write a short description.
  • Select Initialize this repository with a README.
  • Click Create repository.

Step 2. Create a Branch

Branching is the way to work on different versions of a repository at one time.

By default your repository has one branch named master which is considered to be the definitive branch. We use branches to experiment and make edits before committing them to master.

When you create a branch off the master branch, you’re making a copy, or snapshot, of master as it was at that point in time. If someone else made changes to the master branch while you were working on your branch, you could pull in those updates.

This diagram shows:

  • The master branch
  • A new branch called feature (because we’re doing ‘feature work’ on this branch)
  • The journey that feature takes before it’s merged into master

To create a new branch :

  • Go to your new repository hello-world.
  • Click the drop down at the top of the file list that says branch: master.
  • Type a branch name, readme-edits, into the new branch text box.
  • Select the blue Create branch box or hit “Enter” on your keyboard.

Now you have two branches, master and readme-edits. They look exactly the same, but not for long! Next we’ll add our changes to the new branch.

Step 3. Make and commit changes

Now, you’re on the code view for your readme-edits branch, which is a copy of master. Let’s make some edits.

On GitHub, saved changes are called commits. Each commit has an associated commit message, which is a description explaining why a particular change was made. Commit messages capture the history of your changes, so other contributors can understand what you’ve done and why.

Make and commit changes :

  • Click the README.md file.
  • Click the pencil icon in the upper right corner of the file view to edit.
  • In the editor, write a bit about yourself.
  • Write a commit message that describes your changes.
  • Click Commit changes button.

These changes will be made to just the README file on your readme-edits branch, so now this branch contains content that’s different from master.

Step 4. Open a Pull Request

Nice edits! Now that you have changes in a branch off of master, you can open a pull request.

Pull Requests are the heart of collaboration on GitHub. When you open a pull request, you’re proposing your changes and requesting that someone review and pull in your contribution and merge them into their branch. Pull requests show diffs, or differences, of the content from both branches. The changes, additions, and subtractions are shown in green and red.

As soon as you make a commit, you can open a pull request and start a discussion, even before the code is finished.

You can even open pull requests in your own repository and merge them yourself. It’s a great way to learn the GitHub Flow before working on larger projects.

Open a Pull Request for changes to the README :

  • Click the Pull Request tab, then from the Pull Request page, click the green New pull request button.

  • In the Example Comparisons box, select the branch you made, readme-edits, to compare with master (the original).

  • Look over your changes in the diffs on the Compare page, make sure they’re what you want to submit.

  • When you’re satisfied that these are the changes you want to submit, click the big green Create Pull Request button.

  • Give your pull request a title and write a brief description of your changes.

  • When you’re done with your message, click Create pull request!

Step 5. Merge your Pull Request

In this final step, it’s time to bring your changes together – merging your readme-edits branch into the master branch.

If you are contributing to projects owned by others , then this step will be done by them after reviewing your PR(pull request).

  • Click the green Merge pull request button to merge the changes into master.
  • Click Confirm merge.
  • Go ahead and delete the branch, since its changes have been incorporated, with the Delete branch button in the purple box.

Forking Projects

After using GitHub by yourself for a while, you may find yourself wanting to contribute to someone else’s project. Or maybe you’d like to use someone’s project as the starting point for your own. This process is known as forking.

Creating a “fork” is producing a personal copy of someone else’s project. Forks act as a sort of bridge between the original repository and your personal copy. You can submit Pull Requests to help make other people’s projects better by offering your changes up to the original project. Forking is at the core of social coding at GitHub.

Fork the repository

To fork the repository, click the Fork button in the header of the repository.

Sit back and watch the forking magic. When it’s finished, you’ll be taken to your copy of the repository.

After Forking make the required changes and commit the changes.

Making Pull Request

At last, you’re ready to propose changes into the main project! This is the final step in producing a fork of someone else’s project, and arguably the most important. If you’ve made a change that you feel would benefit the community as a whole, you should definitely consider contributing back.

To do so, head on over to the repository on GitHub.com where your project lives. For this example, it would be at https://www.github.com/your_username/RepoName . You’ll see a banner indicating that you’ve recently pushed a new branch, and that you can submit this branch “upstream,” to the original repository:

Clicking on Compare and Pull Request sends you to a discussion page, where you can enter a title and optional description. It’s important to provide as much useful information and a rationale for why you’re making this Pull Request in the first place. The project owner needs to be able to determine whether your change is as useful to everyone as you think it is.

When you’re ready typing out your heartfelt argument, click on Send pull request. You’re done!


What’s a version control system?

A version control system, or VCS, tracks the history of changes as people and teams collaborate on projects together. As the project evolves, teams can run tests, fix bugs, and contribute new code with the confidence that any version can be recovered at any time. Developers can review project history to find out:

Which changes were made? Who made the changes? When were the changes made? Why were changes needed?

What’s a distributed version control system?

Git is an example of a distributed version control system (DVCS) commonly used for open source and commercial software development. DVCSs allow full access to every file, branch, and iteration of a project, and allows every user access to a full and self-contained history of all changes. Unlike once popular centralized version control systems, DVCSs like Git don’t need a constant connection to a central repository. Developers can work anywhere and collaborate asynchronously from any time zone.

Without version control, team members are subject to redundant tasks, slower timelines, and multiple copies of a single project. To eliminate unnecessary work, Git and other VCSs give each contributor a unified and consistent view of a project, surfacing work that’s already in progress. Seeing a transparent history of changes, who made them, and how they contribute to the development of a project helps team members stay aligned while working independently.

Lets Begin

Install Git

Linux : sudo apt-get install git
Windows: Download Link

Create A New Repository

create a new directory, open it and perform a git init to create a new git repository.

Clone A Repository

create a working copy of a local repository by running the command git clone "url"

NOTE : workflow :
your local repository consists of three "trees" maintained by git. the first one is your Working Directory which holds the actual files. the second one is the Index which acts as a staging area and finally the HEAD which points to the last commit you've made.

Add & Commit

You can propose changes (add it to the Index) using git add <filename> for particular file and git add * for all the changed files.
This is the first step in the basic git workflow. To actually commit these changes use git commit -m "Commit message" .
Now the file is committed to the HEAD, but not in your remote repository yet.

Pushing Changes

Your changes are now in the HEAD of your local working copy. To send those changes to your remote repository, execute git push origin master .

Change master to whatever branch you want to push your changes to.

If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it with git remote add origin <server> Now you will be able to push your changes to the selected remote server

Branching

Branches are used to develop features isolated from each other. The master branch is the "default" branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion.

create a new branch named "feature_x" and switch to it using

git checkout -b feature_x

switch back to master

git checkout master

delete the branch again

git branch -d feature_x

a branch is not available to others unless you push the branch to your remote repository

-git push origin <branch>

Update & Merge

to update your local repository to the newest commit, execute

git pull

in your working directory to fetch and merge remote changes. to merge another branch into your active branch (e.g. master), use

git merge "branch"

in both cases git tries to auto-merge changes. Unfortunately, this is not always possible and results in conflicts. You are responsible to merge those conflicts manually by editing the files shown by git. After changing, you need to mark them as merged with

git add "filename"

before merging changes, you can also preview them by using

git diff "source_branch" "target_branch"

Replace local changes

In case you did something wrong, which for sure never happens ;), you can replace local changes using the command

git checkout -- "filename"

this replaces the changes in your working tree with the last content in HEAD. Changes already added to the index, as well as new files, will be kept.

If you instead want to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it like this

git fetch origin git reset --hard origin/master

Need any help?

@mubaris , @aswinzz , @aswanthkoleri , @Anupam-Dagar