One of most common technology that new professional developers struggle with is
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:
This downloads entire git repo from a remote server, usually. You will get all revision history and branches.
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.
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
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.
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.
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.
This is where things get a bit confusing new developers. There are likely 3 different cases when you merging:
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.
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.
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