As specified in the previous tutorial git is A tool for tracking changes over time on your project! You can utilize this approach in your own local repository, but doing so will make it impossible to share your work with others or even collaborate on a project with a team. As a result, it requires an external or remote repository.
Github is a hosting service for Git-based projects. We may publish a local project repository to an external GitHub repository. We may also engage with other developers’ public repositories.
GitHub functions similarly to a social network for programmers, allowing them to share their code openly or privately and learn from one another’s experiences.
If you’re not familiar with Git, I suggest you read the previous article carefully before you start reading this one. It’ll give you a good foundation to build on.
Getting started with GitHub
As previously stated, GitHub lets developers store their projects on an external server (in the cloud!). This means they can work on their projects from any computer they want, and easily share their work with the rest of the team.
If you want to start using GitHub, you’ll need to create an account. Just click the sign-up link and get started!
1. Create the first repository
Once you’ve made your account and logged in, just hit the + button on the top right menu and choose “New Repository” option from the menu that will show up:
Ok, so once you’re on the “Create a new repository” page as you can see in the pic below, you need to add a unique name and maybe a little description for your repo. You can also decide if you want to keep it to yourself (private) or make it public.
If you make it public, it’ll be visible to anyone. Just remember, if you’re sharing your code, make sure there isn’t any personal or important info you don’t want others to see. If you keep it private, you can pick who gets to access it.
So, as you can see, there are some other options like gitignore (which we learned about in a previous article), a README (a markdown file that gives extra info about the repo), and a license, these are in most public project. If you choose any of these options it means you’re just starting to work and there’s nothing on your local machine yet. In that case, you need to do one more step — pulling — which I’ll explain later.
But now we are going to push (a term used for submitting our local codes to a github repo) the simple project that we worked on in the previous article and moving it to a repository on our GitHub. So, don’t choose any of those options for this situation.
Before we get our hands dirty, let me give you another important tip. If you push a local repo, everything on your local history will be public and anyone can see it. So, it’s always a best practice to remove any sensitive or personal information from your git history. (We discussed it in the prior article you can find it here)
2. Push to github
After creating your repository, you will be taken to a page like the one below:
As you can see, Github has given us a guide on this page. Since we want to send the project on our computer to the external repository that we just created, we need to follow the instructions explained in the second part. I gonna tell you what this steps means:
first you need make a connection between local to external one with following command:
git remote add <name> <github-repo-url>
This tells your git system that you have another repository outside of your computer and you want to link it up. You can name it whatever you want, but it’s usually called “origin”.
To upload your repository to GitHub, we’ll need to use the git push command. But first of all you need to identify yourself and your machine for github!
Well, first you need to Generating GitHub SSH Keys:
Then you need to copy this key and add a new ssh key inside your github setting account and in ssh-keys
That’s it! Now you are ready to do your first push into the remote repository you just created.
Let’s run it for our project which we work on in the this article:
As you see at the end of my push command I add some details which is determine what
When you use the git push command, you're telling Git to send your local changes to a remote repository. As you noticed the last part of my push command, specifies which branch of the remote repository you want to push your changes to, and you need to set it at your first push.
As git push description is telling you the local master branch is being tracked through the master branch in remote Github repository. This means that any changes I make to my local master branch will be synced with the master branch on Github.
Once you’ve pushed your changes to Github, you should see your project remote repo updated on the Github page. This means that your changes have been successfully pushed and are now live on Github.
On this page, other developers can see your code. Download it and run it on their own system, and if they have a problem or even an idea, they can share it with others in the issues section, and they can get a lot of other information from older versions and previous commits!
3. Pushing again
After the first push, all you need to do is commit the changes locally and then push them to the remote repository. This tells Git to apply the changes you made to the remote repository.
For example, let’s say we add a html file into the project and remove index.js file in last commit. And then simply just commit those changes and push them to the remote repository:
Well done! Now if you go through your commits list by clicking commits in top right corner in your repo page:
Here, you can view the history of your commits. If you look through some of the earlier commits, you find that the index.js file exists. This can be a cause for concern if the file contains sensitive data, and it is best practice to prevent it from being tracked by Git. You can achieve this by adding the file to the .gitignore file at the beginning of the project initialization. but sometimes maybe it happens that you need to remove a file from all history!!!
Please note that this solution is potentially risky. Therefore, before implementing it in your project, it is highly recommended that you create a backup of your project.
Remove a file from all history
To remove a file from all git history, you can use the git filter-branch command with the --tree-filter option. Here are the steps:
git filter-branch --tree-filter 'rm -f path/to/file' HEAD
Replace path/to/file with the path to the file you want to remove. This command will remove the file from all commits in the repository's history.
Then force push the changes to the remote repository:
git push --force
The --force option overwrites the remote repository's history with your local changes. If others are collaborating on the repository, make sure to communicate with them before using --force.
So let me do it with index.js file in our example:
If you check the commit history for the commit where index.js was added, you will notice that the file is no longer present there.
4. Cloning
Now, it’s time to clone a repository from GitHub and work on it on our own system. To do this, we need to create a new directory on our system and download or clone the desired repository.
To get started, go to the GitHub repository you want to clone and click on the “Clone” button. From the drop-down menu, click on the copy button shown in the image (although it’s also possible to download the repository directly, we’ll be using Git here).
Next, navigate to the desired directory on your system and use the following command to clone the repository:
git clone <repository url>
This will download the repository to your local system and create a new directory with the same name as the repository. You can now make changes to the files in the directory and push those changes back to the remote repository on GitHub.
I would like to point out that if you follow the cloning steps as above, you will notice that the project contents are placed in a folder git-tutorial
Of course, transferring the contents of the project is not very difficult! I know! But let don’t even do that by add a simple . at the end of your command 😉:
git clone <github-repo-link> .
5. Publish a new Branch
As a general rule, the master/main branch of a repository should always contain stable and executable code. When working with remote repositories, it is not recommended to directly push any code that is still under development and may contain bugs onto the master branch. Instead, it is best to work on a separate branch and merge it with the master branch after it has been thoroughly tested by the project manager.
Therefore, when making changes to the code or developing new features locally, it is usually best practice to create a new branch for those modifications in the remote project repository. This way, the master/main branch, which should only contain stable versions, remains untouched.
Creating a new branch was covered in the previous article. You can find out here, As you see in following pic I just add a file in our example and push it :
As you can see, the new local branch has been added to our GitHub repository. However, if we reload the project page, we will notice that the new branch is added!
After creating your branch, you need to propose your changes to the other team members by creating a pull request in order for them to review and merge your changes:
6. Submit a pull request on GitHub
As depicted in the picture above, you can submit your request by clicking on the “Compare & Pull Request” button. This action will lead you to a page where you are required to fill in the application form with a suitable title and a necessary description. On this page, you can also view a detailed list of changes that you have made, line by line:
Once you have submitted the request, other team members can review your commits and provide their feedback on the same request page. Finally, the manager of the development team, who has created the repository or has access to merge branches, will merge your changes into the main branch.
In addition, on the right-hand side column, you can add various details to your PR. This includes assigning Assigners and Reviewers, adding Labels, and linking to specific issues.
7. Branch protection rule
Another thing you may notice when push your new branch at the first time is this message:
> “Your master branch isn’t protected”
This message appears when you are the owner of the repo and tell you can add certain rules to protect the master/main branch as a manager from any direct push. When you click on this message, you will be directed to another page where you can set up rules to protect the branch.
GitHub has several branch protection rules that can be used to manage and regulate the development process within a repository. Here are some of the branch protection rules available on GitHub:
- Require a pull request before merging: This means that any changes to a branch that matches this rule must be made through a pull request. This ensures that changes are reviewed and approved by the appropriate people before they are merged into the branch.
- Require status checks to pass before merging: This setting allows you to choose which status checks must pass before a branch can be merged into a branch that matches this rule. When enabled, commits must first be pushed to another branch, then merged or pushed directly to a branch that matches this rule after status checks have passed. This ensures that the changes have been properly tested and verified before they are merged.
- Require conversation resolution before merging: When enabled, all conversations on code must be resolved before a pull request can be merged into a branch that matches this rule. This ensures that any discussions or reviews related to the code changes have been completed before the changes are merged.
- Require signed commits: Commits pushed to matching branches must have verified signatures. This ensures that the changes are authentic and have not been tampered with.
- Require linear history: Prevent merge commits from being pushed to matching branches. This setting ensures that the branch history remains linear, with no merge commits. This can be useful for teams that want to maintain a clean and simple branching history.
- Require deployments to succeed before merging: Choose which environments must be successfully deployed to before branches can be merged into a branch that matches this rule. This ensures that the changes have been properly deployed and tested in the specified environments before they are merged.
- Lock branch: Branch is read-only. Users cannot push to the branch. This setting prevents anyone from modifying the branch, ensuring that it remains in a stable state.
- Do not allow bypassing the above settings: The above settings will apply to administrators and custom roles with the “bypass branch protections” permission. This ensures that even users with elevated permissions cannot bypass the protection rules.
There are several details here, and covering all of them is beyond the scope of this article. You can learn more about them from the official explanation here. If you have any suggestions or preferred settings, please feel free to share them with us in the comments section. It would be very helpful.
8. Pull changes from GitHub
In team projects, it is common to encounter a situation where the remote repository on GitHub does not match the local repository on your computer, especially after making changes or merging branches through pull requests. To resolve this issue, you can use the “git pull” command to fetch the most recent changes from the GitHub repository and update your local repository accordingly.
9. Forking a repo (Joining to the Community)
GitHub is home to a vast number of public and private projects. If you are looking to start a project, you can use someone else’s repository as a starting point. Alternatively, you may want to join the development of an existing open source project and contribute to the team, which can provide valuable experience and enhance your resume.
To begin, you can fork someone else’s GitHub repository and create a copy of it in your own account. If you are also interested in contributing to the project, you can create new pull requests from your forked repository to submit your changes to the main repository owners.
There is a sample repository called Spoon-Knife that was created for testing purposes, and I have used it to demonstrate the fork process in this tutorial. When you visit the repository’s page, you will see a “Fork” button at the top. Clicking on it will create a copy of the Spoon-Knife project repository in your GitHub account. This forked repository is linked to your account and does not affect the main repository.
To obtain a local version of the forked repository, you can use the same procedure as you would for your own repository. Simply use the “git clone” command and make any desired changes.
10. Suggest changes to the original project
Once you have made changes to the code, you can submit a pull request to the owner of the original project that you forked and contribute to the project. The process for submitting a pull request is similar to that of your own repository. When you click on the “Pull Request” button in your forked repository, you will be directed to a page where you can fill out a request form and send it to the owner of the main project along with a description of your changes.
It is important to provide a detailed description of the changes you made when contributing to a project owned by someone you do not know. Based on this description, the owner of the original project can decide whether to implement your changes in their project or not. By following this process, you can easily fork other people’s open source projects, learn from others, and contribute to the community.
As mentioned before, Git and GitHub are absolute must-haves for programmers these days, and it’s crucial for every developer to know how to use them. In these two educational articles, I’ve tried my best to cover everything you need to know in the simplest way possible. But, of course, there’s always more to learn about Git and GitHub!
If you’re interested in delving deeper into the powerful features of GitHub, I recommend checking out the resources and documentation available on Git itself. There’s a ton of helpful stuff out there!
And with that, we’ve come to the end of this course. If you enjoyed the tutorial and want to stay in the loop with my work, feel free to follow me. And if you have any questions or comments about this tutorial, please don’t hesitate to ask in the comments section.
Top comments (0)