All about the Git
I’ve recently started working with a team at a non-profit organization which has forced me to pay better attention to proper Git work flow. Git add/git commit/git push no longer does the trick when you’re working with others on a project. So I thought, why not take this time refresh/add to my knowledge of Git and Github.
Git is an open source software that serves very effectively for version control amongst teams of software developers. The software package was created in April 2005 by Linus Torvald (of Linux fame) during a dispute with Bitkeeper (another version control software, or VCS), and was specifically created to be faster and safer than Bitkeeper and other VCSs, as well as free/open source. Junio Hamano, also a major contributor, was tasked with maintaining Git very soon after it was released.
Torvald is a pretty funny guy. Here are his initial comments on his first revision of git, “the information manager from hell”:
Github as most of us know is one of several platforms that host individual repositories (or repos) which can be set as private or public, and is a very convenient tool for teams of developers to utilize for accessing code bases. I think of it as Google Drive but for coders. Github was created in 2008 using Ruby on Rails and was acquired by Microsoft in 2018. As per Wikipedia: “As of January 2020, GitHub reports having over 40 million users and more than 190 million repositories (including at least 28 million public repositories), making it the largest host of source code in the world.”
Github (the platform) uses Git (the VCS) to manage work flow via various commands and, if used correctly, protects the main branch of a repo from bugs that may break your code while you “try stuff out” (aka add features) on any given feature branch. I am going to assume that you the reader know how to create a repo and do the basic git init &/or git add/commit/push, and that you know the difference between a main branch and a feature branch. Here are some common CLI commands that you can use on your local machine:
- git pull: pulls down all updates from corresponding (origin) branch that you are on. If you are on a feature branch and have pushed that branch to Github, say to work on it with a team, git pulling will pull from that branch but not pull anything from any other branch. If you are on the main, of course this command will pull from the main branch.
- git fetch origin: will fetch and show all branches from the origin. After this you can git checkout <feature branch name> to work on a particular feature branch that someone else has created/pushed.
- git add: git add . will stage all previously unstaged updates, whereas git add <file-name> will only stage updates from the specified file.
- git commit -am “message goes here”: shortcut to add and commit in a single command.
- git branch: checks to see which branches have been created/are available to work on from your local machine. Additionally, running git branch will tell you which branch you are currently on:
- git checkout <branch-name>: switches to the specified branch
- git checkout -b <branch-name>: creates a new branch and then switches to that branch in a single command. This is a shortcut for git branch <branch-name> & git checkout <branch-name>
Note: remember that branch names should be descriptive to make clear what is being worked on on a given feature branch.
- git status: tells you whether you have changes staged to commit, i.e., if you’ve run git add, and where your branch stands in commits as compared to the origin.
- git push -u origin <branch-name>: this sets up & pushes initial branch commits to the origin <branch-name>. After this first push from a feature branch you should be able to do a simple git push to send additional commits to that origin feature branch (i.e., git knows where to send the updates).
- git merge <branch-name>: merges updates on two branches, usually a main and a feature branch. i.e., git checkout main, git merge <feature-branch>
- git branch -d <branch-name>: deletes that branch
- git rebase <branch-name>: is an alternative to merging. This will show your commits in a cleaner way than merging does.
- git remote -v: will show you the fetch and push urls (which are usually the same).
- Commonly for git flow with a team, we will git add/commit/push on a feature branch and then make a pull request for someone else to review the changes before they are edited and/or merged.
- As an alternative if you are working on a feature branch and need to continue working on that branch but also require the main branch updates, you can run these commands: git checkout <feature-branch-name>, git merge main. Now your feature branch will have the main branch updates. But don’t forget to FIRST git checkout main and git pull so if there are any main branch updates, you’ll have pulled those as well.
Note: it is important to remember the difference between fork and clone. Forking a repo brings an entire copy of that repo to your Github account. If you need to work on a repo with a team, you’ll want to *skip* the fork command and clone down directly from that repo. This way when you make commits, you are sending them to the team’s repo, not to your personal/copied one.
Remember that if you’re working on a feature branch and find that you need to switch back to your main branch, you should first git add and commit your changes before switching to main. Git *does not like* unstaged and/or uncommitted changes.
There is so much to learn about Git, this is just the tip of the VCS iceberg! Feel free to browse more here:
Git - Basic Branching and Merging
Switch to your production branch. Create a branch to add the hotfix. After it's tested, merge the hotfix branch, and…
A version control system, or VCS, tracks the history of changes as people and teams collaborate on projects together…
Git - Wikipedia
Git () is software for tracking changes in any set of files, usually used for coordinating work among programmers…