In my previous note, I documented a few simple use cases for someone who is getting started with using git and github. In this note I am going to focus on a few more use cases particularly around: clone, branch, merge and rebase.For all the use cases below, I am going to assume that git for windows is installed
UseCase: How do I download code from a remote git repo to work on that?
A lot of times you’d want to work or maybe just review a code base that already exists (for e.g. in github). While you can always review the code in github but if you have to update the code that is already there you’d want the code downloaded onto your local computer. This is known as clone. Say we want to work on a code base: https://github.com/kunduso/TestProjects.git Lets get back to our command prompt and create a folder where we want to clone the git repo and call it “FirstGitProject-Clone” followed by a git clone command.
This will download the latest code base from github to your local folder from where the clone command was executed and you are ready to make changes to the code base and work on it as any other code base. Once your changes are in place, its the same sequence:
git pull
git add .
git commit "${enter your comments}"
git push
Now you should be able to view your comments on github along with history of how the codebase has evolved/changed.
UseCase: How do I create a branch in my local git repo?
Branching is a mid level feature in git. You might not have to use it if your code base is new and not yet released to production. However after your first release, you’d want master branch to be as close to production as possible. Alternatively, you might have a pretty updated code base in master and instead of committing your changes to master you feel comfortable to make them in a local branch and once the feature/user story/bug you were working on looks good, you are ready to merge your changes to master. In this case it is a good idea to create a branch (copy) of your code from master and work (make commits) there. There are two ways to create a new git branch.
Option 1:
git branch ${NewBranchName}
git checkout ${NewBranchName}Option 2:
git checkout -b ${NewBranchName}-b in git checkout command tells Git to create a new branch before checking it out.
git branch -a is also a good command to review which branch you are working on. The * will be against the branch that is checked out (you are currently working on it).
Now that we are have the NewBranch checked-out let me make a couple of commits there to create some history.
With history, I can now push my changes to github
..and we can review this on github
UseCase: How do I merge?
After branch we work on merge. There have been a lot of stackoverflow questions of what is the right way to merge and I will be pointing to one such that I found informative: https://stackoverflow.com/questions/5601931/what-is-the-best-and-safest-way-to-merge-a-git-branch-into-master
In our case, we first move to master as our active branch and then issue a git merge command from there. Git merges the specified branch to its current active branch. The format is:
git checkout master
git merge ${NewBranchName}If there are no merge conflicts, these changes are committed to master and you can do a git -log to check commit history
Once merge is done, upload the code to your github using the command
git push origin master
And this is how we merge. There is also something known as squash where the command looks like:
git merge --squash NewBranchThis command is followed by a git commit to commit the changes to master branch. As you have noticed in this example, when changes from NewBranch are merged to master, all the commits in the NewBranch are now logged under master branch -commit by commit. What if I do not want to see all the changes from the NewBranch? What if I am interested only in the final version of NewBranch rather than the individual commits in the branch. We use the squash option. Using this, you are combining all the commits into one commit which also makes it easier to cancel out the noise of individual commits.
There are different scenarios when you’d want to use squash and when not. When merging from my individual branch to master, I prefer adding –squash option because that way, the commit history in master looks clean …and then out of habit, I like to save this work in github.
git push origin master
There is also something known as rebase and it is different than merge. Ideally you’d not want to rebase your master branch from any other branches but rebasing your feature/local branch from master should be totally okay. I’ll try to list a few good urls that I used to understand this concept.
Reference:
https://git-scm.com/docs/git-branch
https://git-scm.com/docs/git-merge
https://git-scm.com/docs/git-rebase
https://www.youtube.com/watch?v=CRlGDDprdOQ
My Devops Journal 