Skip to main content

GitHub- how it works

GitHub:

GitHub is a platform for hosting and collaborating on projects. We don’t have to worry about losing data on our hard drive or managing a project across multiple computers — sync from anywhere.

GitHub Essentials: Repositories, Branches, Commits, Issues and Pull Requests.
A repository is the basic unit of GitHub, most commonly a single project. 

Repositories can contain folders and files, including images – anything our project needs.

Repository = single project = single folder which contains subfolders and files.

Sometimes GitHub users shorten this to “repo.”


Branching is the way to work on different parts of a repository at one time.
When we are working on a project, we are going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. Branching exists to help we manage this workflow.
When we create a branch in our project, we are creating an environment where we can try out new ideas.
When we create a repository, by default it has one branch with the name “master” (production) branch.

A new branch is a copy of master branch, initially.

If the original branch changes while we are working on our new branch, no worries, we can always pull in those updates.

Changes we make on a branch don't affect the master branch, so we are free to experiment and commit changes, safe in the knowledge that our branch won't be merged until it's ready to be reviewed by someone we are collaborating with.
On GitHub, saved changes are called commits. Commits are pretty glorious, because a bunch of them together read like the history of our project.
Each commit has an associated commit message, which is a description explaining why a particular change was made. Thanks to these messages, we and others can read through commits and understand what we’ve done and why. By writing clear commit messages, we can make it easier for other people to follow along and provide feedback.
After committing our changes in the new branch, now there are changes those are not in the master branch.

When we make a pull request, we are proposing our changes and requesting that someone pull in our contribution - aka merge them into their branch.
GitHub’s Pull Request feature allows us to compare the content on two branches.
The changes, additions and subtractions, are shown in green and red and called diffs(differences).
As soon as we make a change, we can open a Pull Request. People use Pull Requests to start a discussion about commits (code review) even before the code is finished. This way we can get feedback as we go or help when we are stuck.
By using GitHub’s @mention system in our Pull Request message, we can ask for feedback from specific people or teams, whether they’re down the hall or 10 time zones away.
If we're using a Shared Repository Model, Pull Requests help start code review and conversation about proposed changes before they're merged into the master branch.
An Issue is a note on a repository about something that needs attention. It could be a bug, a feature request, a question or lots of other things. On GitHub we can label, search and assign Issues, making managing an active project easier.
We’ve got a repository now, but it’s pretty bare. It could use a README with more information in it so that people know what is going on. Open an Issue!

 Deploy
Once our pull request has been reviewed and the branch passes our tests, we can deploy our changes to verify them in production. If our branch causes issues, we can roll it back by deploying the existing master into production.

 Merge
Now that your changes have been verified in production, it is time to merge our code into the master branch.
Once merged, Pull Requests preserve a record of the historical changes to our code. Because they're searchable, they let anyone go back in time to understand why and how a decision was made.
By incorporating certain keywords into the text of our Pull Request, we can associate issues with the code. When our Pull Request is merged, the related issues are also closed. For example, entering the phrase Closes#32 would close issue number 32 in the repository.

Git-Specific Commands:

Since Git was designed with a big project like Linux in mind, there are a lot of Git commands. However, to use the basics of Git, you’ll only need to know a few terms. They all begin the same way, with the word “git.”
git init: Initializes a new Git repository. Until you run this command inside a repository or directory, it’s just a regular folder. Only after you input this does it accept further Git commands.
git config: Short for “configure,” this is most useful when you’re setting up Git for the first time.
git help: Forgot a command? Type this into the command line to bring up the 21 most common git commands. You can also be more specific and type “git help init” or another term to figure out how to use and configure a specific git command.
git status: Check the status of your repository. See which files are inside it, which changes still need to be committed, and which branch of the repository you’re currently working on.
git add: This does not add new files to your repository. Instead, it brings new files to Git’s attention. After you add files, they’re included in Git’s “snapshots” of the repository.
git commit: Git’s most important command. After you make any sort of change, you input this in order to take a “snapshot” of the repository. Usually it goes git commit -m “Message here.”The -mindicates that the following section of the command should be read as a message.
git branch: Working with multiple collaborators and want to make changes on your own? This command will let you build a new branch, or timeline of commits, of changes and file additions that are completely your own. Your title goes after the command. If you wanted a new branch called “cats,” you’d type git branch cats.
git checkout: Literally allows you to “check out” a repository that you are not currently inside. This is a navigational command that lets you move to the repository you want to check. You can use this command as git checkout masterto look at the master branch, or git checkout catsto look at another branch.
git merge: When you’re done working on a branch, you can merge your changes back to the master branch, which is visible to all collaborators. git merge cats would take all the changes you made to the “cats” branch and add them to the master.
git push: If you’re working on your local computer, and want your commits to be visible online on GitHub as well, you “push” the changes up to GitHub with this command.
git pull: If you’re working on your local computer and want the most up-to-date version of your repository to work with, you “pull” the changes down from GitHub with this command.
TIC-TAC-TOE:

Comments

Post a Comment

Popular posts from this blog

Effective Scrum Meeting

Overview: The Daily Scrum Meeting is held every day through the sprint. At the meeting, the Scrum team gathers to review and synchronize about the project status. In theory, each team member should provide his/her status based on three (03) Q: What did you do yesterday? What do you intend to do today? Is there any issues that blocks your work? # The participants should come prepared: Stop participants that don't come prepared and waste the meeting time. The team members should come prepared to share their updates. You should describe how to answer these questions effectively to increase the synchronization among the team members. The team members should know what is your expectations from them while answering these questions. # Validate that each individual describe the full picture: Validate that each individual can answer the 3 questions (Do not continue until you get the answers or the reasons for why he can't provide them). Validate that each tea...
Post a Comment
Read more

Verification and Validation (V&V)- a software testing approach

Verification: It focuses on PROCESS related activities to ensure that the Products and deliverables meet a specific requirement before the final testing. Can be done through: A. Technical review B. Business review C. Management review Simply: Are we building the product in the right way?  that is, does the software conform to its specification verification  is the process of checking that the software meets the specification. Verification is an example of QA Validation: It focuses on PRODUCT related activities, that attempt to determine if the system or project deliverables meet the customer or client's expectations. Will be done by: Testing. Simply: Did we build the right product?  that is, is the software doing what the user really requires. Validation  is the process of checking whether the specification captures the customer's needs. According to the Capability Maturity Model(CMMI-SW v1.1) we can also define validation as The process ...
Post a Comment
Read more