Git Simplified

One of most common technology that new professional developers struggle with is git.

Many junior developers are eager to start using all of the powerful commands of git and usually end up getting more confused.

Here are a few commands that I recommend to anyone learning git for the first time:

clone

This downloads entire git repo from a remote server, usually. You will get all revision history and branches.

init

This initialize new empty git repo in current directory. As a junior developer you are unlikely to do this. Most likely you will be cloning an existing project.

Another caveat here is that when you initialize a git repo, you will need to set remote destination to push your code changes. But let’s not worry about it yet.

checkout

Once you have cloned a repo on your machine, you can checkout a specific branch. By default when you clone, master branch is checked out. Most likely you will be working in some other branch. So you will check it out by typing git checkout branch-name

pull

This command pulls changes from remote server into your local copy of repo. If you are working a branch that another developer created then that developer needs to push that branch to remote server, then you can pull it. And finally you can check it out. I see many junior developers not pulling before checking out a new branch.

commit

This is simple make your changes and commit your code to repo. When you issue this command, your changes are stored in your local copy of repo. You will need to issue push command before your changes are pushed to remote server and only then other developers can pull your changes.

push

This pushes your local repo with all local to changes to remote server.

Many times you will need to merge changes from remote in your local repo before you can push.

merge

This is where things get a bit confusing new developers. There are likely 3 different cases when you merging:

2 or more developers are working on same branch

This is simplest case. You can simply issue git pull command and it will fetch and merge remote changes. Now this can result in conflicts, which will need to be resolved manually. I will talk about conflicts later.

New release went out

It is recommend to merge master (or default) branch into your branch often especially right after any major release. This avoids any conflicts later during Continuous Integration pipeline.

You need a feature from another branch

This is probably the worst scenario to deal with because now your branch is dependent on another branch. I prefer to avoid this scenario unless the feature is in master. The reason for avoiding this scenario are two folds, first code reviews get hard as it is hard to tell what was changed in your branch and what was pulled in from the other branch. And then many times my code got delayed because I was waiting on other branch.

You may have to issue pull command before merging

git pull
git merge other-branch my-branch
Published on

Previous post: Tools of Trade

Next post: More research on choosing dev stack for game dev