#GitWorkflows | Explore Tumblr posts and blogs

codingquill · 2 months ago

Text

Welcome back, coding enthusiasts! Today we'll talk about Git & Github , the must-know duo for any modern developer. Whether you're just starting out or need a refresher, this guide will walk you through everything from setup to intermediate-level use. Let’s jump in!

What is Git?

Git is a version control system. It helps you as a developer:

Track changes in your codebase, so if anything breaks, you can go back to a previous version. (Trust me, this happens more often than you’d think!)

Collaborate with others : whether you're working on a team project or contributing to an open-source repo, Git helps manage multiple versions of a project.

In short, Git allows you to work smarter, not harder. Developers who aren't familiar with the basics of Git? Let’s just say they’re missing a key tool in their toolkit.

What is Github ?

GitHub is a web-based platform that uses Git for version control and collaboration. It provides an interface to manage your repositories, track bugs, request new features, and much more. Think of it as a place where your Git repositories live, and where real teamwork happens. You can collaborate, share your code, and contribute to other projects, all while keeping everything well-organized.

Git & Github : not the same thing !

Git is the tool you use to create repositories and manage code on your local machine while GitHub is the platform where you host those repositories and collaborate with others. You can also host Git repositories on other platforms like GitLab and BitBucket, but GitHub is the most popular.

Installing Git (Windows, Linux, and macOS Users)

You can go ahead and download Git for your platform from (git-scm.com)

Using Git

You can use Git either through the command line (Terminal) or through a GUI. However, as a developer, it’s highly recommended to learn the terminal approach. Why? Because it’s more efficient, and understanding the commands will give you a better grasp of how Git works under the hood.

GitWorkflow

Git operates in several key areas:

Working directory (on your local machine)

Staging area (where changes are prepared to be committed)

Local repository (stored in the hidden .git directory in your project)

Remote repository (the version of the project stored on GitHub or other hosting platforms)

Let’s look at the basic commands that move code between these areas:

git init: Initializes a Git repository in your project directory, creating the .git folder.

git add: Adds your files to the staging area, where they’re prepared for committing.

git commit: Commits your staged files to your local repository.

git log: Shows the history of commits.

git push: Pushes your changes to the remote repository (like GitHub).

git pull: Pulls changes from the remote repository into your working directory.

git clone: Clones a remote repository to your local machine, maintaining the connection to the remote repo.

Branching and merging

When working in a team, it’s important to never mess up the main branch (often called master or main). This is the core of your project, and it's essential to keep it stable.

To do this, we branch out for new features or bug fixes. This way, you can make changes without affecting the main project until you’re ready to merge. Only merge your work back into the main branch once you're confident that it’s ready to go.

Getting Started: From Installation to Intermediate

Now, let’s go step-by-step through the process of using Git and GitHub from installation to pushing your first project.

Configuring Git

After installing Git, you’ll need to tell Git your name and email. This helps Git keep track of who made each change. To do this, run:

Master vs. Main Branch

By default, Git used to name the default branch master, but GitHub switched it to main for inclusivity reasons. To avoid confusion, check your default branch:

Pushing Changes to GitHub

Let’s go through an example of pushing your changes to GitHub.

First, initialize Git in your project directory:

Then to get the ‘untracked files’ , the files that we haven’t added yet to our staging area , we run the command

Now that you’ve guessed it we’re gonna run the git add command , you can add your files individually by running git add name or all at once like I did here

And finally it's time to commit our file to the local repository

Now, create a new repository on GitHub (it’s easy , just follow these instructions along with me)

Assuming you already created your github account you’ll go to this link and change username by your actual username : https://github.com/username?tab=repositories , then follow these instructions :

You can add a name and choose wether you repo can be public or private for now and forget about everything else for now.

Once your repository created on github , you’ll get this :

As you might’ve noticed, we’ve already run all these commands , all what’s left for us to do is to push our files from our local repository to our remote repository , so let’s go ahead and do that

And just like this we have successfully pushed our files to the remote repository

Here, you can see the default branch main, the total number of branches, your latest commit message along with how long ago it was made, and the number of commits you've made on that branch.

Now what is a Readme file ?

A README file is a markdown file where you can add any relevant information about your code or the specific functionality in a particular branch—since each branch can have its own README.

It also serves as a guide for anyone who clones your repository, showing them exactly how to use it.

You can add a README from this button:

Or, you can create it using a command and push it manually:

But for the sake of demonstrating how to pull content from a remote repository, we’re going with the first option:

Once that’s done, it gets added to the repository just like any other file—with a commit message and timestamp.

However, the README file isn’t on my local machine yet, so I’ll run the git pull command:

Now everything is up to date. And this is just the tiniest example of how you can pull content from your remote repository.

What is .gitignore file ?

Sometimes, you don’t want to push everything to GitHub—especially sensitive files like environment variables or API keys. These shouldn’t be shared publicly. In fact, GitHub might even send you a warning email if you do:

To avoid this, you should create a .gitignore file, like this:

Any file listed in .gitignore will not be pushed to GitHub. So you’re all set!

Cloning

When you want to copy a GitHub repository to your local machine (aka "clone" it), you have two main options:

Clone using HTTPS: This is the most straightforward method. You just copy the HTTPS link from GitHub and run:

It's simple, doesn’t require extra setup, and works well for most users. But each time you push or pull, GitHub may ask for your username and password (or personal access token if you've enabled 2FA).

But if you wanna clone using ssh , you’ll need to know a bit more about ssh keys , so let’s talk about that.

Clone using SSH (Secure Shell): This method uses SSH keys for authentication. Once set up, it’s more secure and doesn't prompt you for credentials every time. Here's how it works:

So what is an SSH key, actually?

Think of SSH keys as a digital handshake between your computer and GitHub.

Your computer generates a key pair:

A private key (stored safely on your machine)

A public key (shared with GitHub)

When you try to access GitHub via SSH, GitHub checks if the public key you've registered matches the private key on your machine.

If they match, you're in — no password prompts needed.

Steps to set up SSH with GitHub:

Generate your SSH key:

2. Start the SSH agent and add your key:

3. Copy your public key:

Then copy the output to your clipboard.

Add it to your GitHub account:

Go to GitHub → Settings → SSH and GPG keys

Click New SSH key

Paste your public key and save.

5. Now you'll be able to clone using SSH like this:

From now on, any interaction with GitHub over SSH will just work — no password typing, just smooth encrypted magic.

And there you have it ! Until next time — happy coding, and may your merges always be conflict-free! ✨👩‍💻��‍💻

93 notes · View notes

nedyaj-blog · 11 years ago

Text

Examples of Git Workflows

According to Wikipedia, Git is a distributed revision control and source code management system that supports distributed, non-linear workflows. Each workplace has its favorite git workflow, and in this post we'll be covering the most common workflows for development teams.

Centralized Workflow

Centralized Workflow uses a central repository to serve as the single point-of-entry for all changes in the project - the master branch. Developers in a team clone this repository to their machines in which they can commit localized changes to the system without affecting the central repository. To make changes to the project, developers push their changes to the central master branch. However, before a develop can push any changes, they need to fetch the updated central commits and rebase changes on top of the updated project. Git handles conflicts between local and central commits by pausing the rebase process and giving the developer a chance to manually resolve the conflicts before continuing. While this is a perfectly capable workflow, Centralized Workflow does not utilize some powerful features that Git has to offer. For a more streamlined process, let's look into another workflow.

Feature Branch Workflow

Feature Branch Workflow adds feature branches into the mix which encourages collaboration and communication between developers. In this workflow, developers create feature branches to work on instead of the master branch. In doing so, multiple developers can work on a single feature without altering the main codebase. Because Git doesn't make a technical distinction between master and feature branches, developers can stage and commit changes to feature branches like they do in the Centralized Workflow. Once a feature is complete, a developer can push the branch onto the central server and submit a pull request to have the branch merged with master. Pull requests encourage developers to discuss and review the changes being made before it is a part of the main codebase. Once the pull request has been accepted, publishing the feature is very much the same as it is in Centralized Workflow - make sure that local master is synchronized with the upstream master, merge the feature branch into master and then push the updated master to the central repository. The Feature Branch Workflow is an incredibly flexible way to develop a project; however, sometimes it offers too much flexibility when it comes to larger teams. For a more organized way to managing feature development, release preparation, and maintenance, let's talk about the Gitflow Workflow.

Gitflow Workflow

Gitflow Workflow defines a strict branching model designed around project release that provides a powerful framework for managing larger projects. This workflow does not introduce anything new in terms of concepts and commands beyond what we've already covered, but it does assign specific roles to branches and how they interact. Like the previous workflows, Gitflow Workflow also utilizes a central repository and developers work locally to push branches to it. The difference lies in the specific branch structures of the project.

Historical Branches

Instead of one master branch, there are now two branches to record the history of the project - master and develop branches. The master still serves as the official release history while the develop branch serves as an integration branch for features. The rest of the workflow revolves around these two branches.

Feature Branches

Exactly like Feature Branch Workflow, each feature resides in its own branch which is pushed to the central repository once complete. The only difference is that instead of pushing changes to master, they are pushed into the develop branch. Feature branches never directly interact with master.

Release Branches

Once the develop branch has enough features for a release, a release branch is forked from develop. The creation of this branch indicates that a release is being prepared so no new features can be added after this point. Once the release is ready, it is merged into master and tagged with a version number. The release branch should also be merged with the develop branch, which may or may not be ahead since the release was initiated. Using release branches allows for one section of the team to polish the features of this particular release, while another team can be working on features for the next release. It also promotes well-defined phases of development when tagging each release with version numbers.

Maintenance Branches

Maintenance or "hotfix" branches are used to quickly patch and fix bugs in releases. Maintenance branches are the only type of branches that are allowed to branch directly off master. These branches should be merged into both master and develop and master should be tagged with an updated version number. The benefit of these branches is that it lets the team focus on fixing issues without interrupting the rest of the workflow.

Conclusion

In this post, we've covered three common workflows: Centralized Workflow, Feature Branch Workflow, and Gitflow Workflow. These workflows are just examples of what is possible, and are not strict rules for using Git with projects. The goal is to adopt or develop a Git workflow that works for you and your team so it is perfectly acceptable to adopt some parts of a workflow and disregard others. For a more in-depth discussion of Git workflows, as well as awesome examples and illustrations for better understanding, visit this article here.

#apprenticeship #gitworkflows

0 notes