Git Commands I’ve Learned to Use Part 2
Last week I talked about some of the basic Git commands that a programmer should know to work on projects on their own. I talked about starting a repo and connecting it to GitHub, adding and committing changes, then pushing those changes to GitHub, and using git status to see where you stand. But the great thing about Git that I didn’t really talk about is how it lets you work on projects that other people have started and continue to add to.
One thing that I mentioned I’d talk about in this post is branching. There are a few Git commands I use in relation to branching:
// ♥ > git branch
# lists all the branches you have and highlights the one you're on// ♥ > git checkout -b <branch-name>
# creates a new branch called "branch-name" and switches to it// ♥ > git checkout <branch-name>
# switches to branch "branch-name"
The main purpose of making different branches in a project is so that you can work on a new piece of functionality without affecting the main branch of your project. For example, if you wanted to make a major change to some piece of your project, and you weren’t sure it will work, you can work on that change on a different branch. That way, if the change doesn’t work, you can go back to your main branch, which hasn’t been changed. It’s especially good to use branches when working on a project that has reached MVP (minimum viable product), so you don’t have to worry that any changes you make might break the application when it already works just fine.
But if the functionality you added in a branch ends up working, you need to add it to the main branch. This is done by merging; to merge, switch to your main branch, then run this command:
// ♥ > git merge <other-branch-name>If there are no problems, Git will automatically make a commit in the main branch with all the changes from the merged branch. But if you’ve added anything to your main branch since you started working on the other one, you might have something called merge conflicts. These happen when you made changes around the same place in the same file. When there are merge conflicts, Git will tell you what files the conflicts are in. When you open these files, whatever editor you are working in should show you the change from your main branch and the one from the merged branch side by side so you can choose which one you want.
Another thing I said I’d talk about in this post is cloning. Before, I talked about the way to get a project you are building onto GitHub. Cloning is the way to get an existing repository on GitHub onto your local machine. When you want to work with someone else repo, you should first fork it using the fork button in the upper right side of the repo’s page on GutHub. Once you’ve forked it, click on the clone button and copy what’s listed under clone, either an HTTPS address, or an SSH with a password-protected SSH key. Then you run this command with the copied url in the folder you want the project to be in:
// ♥ > git clone <copiedURL>This cloned repo will automatically have a git repo initialized and be hooked up to your forked version on GitHub, so you can use Git right away.
Any changes you make to this cloned version and push to GitHub will only show up on the version you forked, not in the original; this is so that you don’t mess up the original version. But it also means that anything new added to the original will not show up in your code. The way to deal with this is by adding the original repo as a remote. After you have cloned a repo, you should only have one remote, and to see what remotes you have, you can run this command:
// ♥ > git remote -v
origin git@github.com:<githubUsername>/<repo-name> (fetch)
origin git@github.com:<githubUsername>/<repo-name> (push)Even though there are two lines here, there is only one remote, named origin. Origin is the standard name for the remote of your repo, and the two lines show that you can both push to it and fetch or pull from it. To add another remote you use this command:
// ♥ > git remote add <remote-name> <original-repos-copied-URL>Here, upstream is the name of the remote. With this, whenever you want to update your repo with anything new that’s been added to the original, you can use this command on your main branch:
// ♥ > git pull upstream <branch-name>This will work very similarly to merging, so there might be merge conflicts you need to fix. Another thing to pay attention to is that, if you have been working in a different branch, when you go back to it after pulling from the upstream repo, make sure to merge your main branch in, so you are working with an up-to-date version of the repo.
Now one last thing to mention. When you have multiple remotes, there is something else you should know about pushing changes. Last week, I gave the command to push to GitHub as git push, but this is just a shorthand. The full command is:
// ♥ > git push <remote-name> <branch-name>As a general rule, you should only be pushing to the origin remote, and if you try to push to the upstream remote, it probably won’t let you because you don’t have permission. You can push any branch you have made in your local repo, and if the branch doesn’t exist on GitHub yet, it will be created from this push.
There are still many other things that Git can do, like show you your commit history, or revert changes when you do something wrong. But with all of the commands I’ve talked about in these last two posts, I have been able to work on projects for my bootcamp, and even some open source projects. Knowing these commands has been enough for me to use Git with the projects I’ve worked on, and I think they are a good start to using Git and GitHub to help you build coding projects.
