Yesterday I had the pleasure of speaking at the “Technica 2020 Hackathon” by Machine Learning at IIT about Git workflow. It’s time we revisited Git and how important it is to master in order to advance in our careers. Mastering Git will make a huge difference in how you manage code and your own day-to-day workflow. So, here I come with a few things that I know about when using ‘GitHub’.
As you already know, a version control system like Git 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. Using Git has significant benefits for individuals, teams, and businesses.
1.Git lets developers see the entire timeline of their changes, decisions, and progression of any project in one place.
2. With Git, collaboration can happen at any time while maintaining source code integrity. Using branches, developers can safely propose changes to production code.
3. Git makes it possible to align experts across a business to collaborate on major projects.
How GitHub works?
GitHub builds collaboration directly into the development process. Work is organized into repositories, where developers can outline requirements or direction and set expectations for team members. Then, using the GitHub flow, developers simply create a branch to work on updates, commit changes to save them, open a pull request to propose and discuss changes, and merge pull requests once everyone is on the same page.
Woah, that was a lot of things to absorb. So, Let me start by telling you about each term I mentioned above.
What’s a repository?
A repository, or Git project, encompasses the entire collection of files and folders associated with a project, along with each file’s revision history. The file history appears as snapshots in time called commits, and the commits exist as a linked-list relationship and can be organized into multiple lines of development called branches. Working in repositories keeps development projects organized and protected.
There are two primary ways people collaborate on GitHub:
1. Shared repository: With a shared repository, individuals and teams are explicitly designated as contributors with read, write, or administrator access. This simple permission structure, combined with features like protected branches and Marketplace, helps teams progress quickly when they adopt GitHub.
2. Fork and pull: For projects to which anyone can contribute, managing individual permissions can be challenging, but a fork and pull model allows anyone who can view the project to contribute. A fork is a copy of a project under a developer’s personal account. Every developer has full control of their fork and is free to implement a fix or new feature. Work completed in forks is either kept separate or is surfaced back to the original project via a pull request.
The GitHub flow
The GitHub flow has six steps, each with distinct benefits when implemented:
1. Create a branch: Each team member creates a branch of the master project and on completion, perform the merging of the two branches (i.e. one created by him and the master branch).
Create a branch in Git –
git checkout -b sample_branch
In the command, git checkout -b sample_branch, -b tells Git to create a new branch and name it sample_branch, and checkout switches us to the newly created branch.
2. Add commits: The git commit command captures a snapshot of the project’s currently staged changes. Committed snapshots can be thought of as “safe” versions of a project — Git will never change them unless you explicitly ask it to.
git addgit commit -m “Commit message”
Prior to the execution of git commit, the git add command is used to promote or ‘stage’ changes to the project that will be stored in a commit. These two commands git commit and git add are two of the most frequently used.
3. Open a pull request: Pull requests let you tell others about changes you’ve pushed to a GitHub repository. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.
4. Discuss and review code: Teams participate in code reviews by commenting, testing, and reviewing open pull requests. Code review is at the core of an open and participatory culture.
5. Merge: The git merge command lets you take the independent lines of development created by git branch and integrate them into a single branch.
git checkout mastergit merge sample_branchgit push origin master
6. Deploy: Teams can choose the best release cycles or incorporate continuous integration tools and operate with the assurance that code on the deployment branch has gone through a robust workflow.
Some Basic Git commands
The git init command creates a new Git repository. It can be used to convert an existing, unversioned project to a Git repository or initialize a new, empty repository. Most other Git commands are not available outside of an initialized repository, so this is usually the first command you’ll run in a new project.
2. git clone
If a project has already been set up in a central repository, the git clone command is the most common way for users to obtain a development copy. Like git init, cloning is generally a one-time operation. Once a developer has obtained a working copy, all version control operations and collaborations are managed through their local repository.
git init vs. git clone
A quick note: git init and git clone can be easily confused. At a high level, they can both be used to “initialize a new git repository.” However, git clone is dependent on git init. git clone is used to create a copy of an existing repository. Internally, git clone first calls git init to create a new repository. It then copies the data from the existing repository, and checks out a new set of working files.
3. git add
The git add command adds a change in the working directory to the staging area. It tells Git that you want to include updates to a particular file in the next commit. However, git add doesn’t really affect the repository in any significant way — changes are not actually recorded until you run git commit.
4. git status
The git status command is used to examine the current state of the repository and can be used to confirm a git add promotion.
5. git commit
The git commit command is used to Commit a snapshot of the staging directory to the repositories commit history.
Sets the commit’s message. Make sure to provide a concise description that helps your teammates (and yourself) understand what happened.
6. git push
The git push command is used to upload local repository content to a remote repository. Pushing is how you transfer commits from your local repository to a remote repo.
git push <remote> <branch>
7. Git Pull
The git pull command is used to fetch and download content from a remote repository and immediately update the local repository to match that content.
Git Pull assumes that any change that has occurred in the repository requires merging.
8. Git Fetch
When you do a git fetch, it fetches all the changes from the remote repository and stores it in a separate branch in your local repository. You can reflect those changes in your corresponding branches by merging. So basically, git pull = git fetch + git merge.
Make smaller pull requests
Write useful descriptions and titles
Have on-point commit messages
Add comments on your pull request to help guide the reviewer
Anyone can be good, but awesome takes teamwork. GitHub provides the facility for a team to work efficiently on a project. You can use this tool to adapt them to the needs of your team. I have written this blog with an intention to help those who are new to the programming world and have a little or no idea about what Git and Github actually is. I’d love to hear how your team handles your repository! Please feel free to comment on my work. Hopefully, together we can work and create better experiences for everyone.