git checkout -b \"branching_blog_post\"<\/code><\/pre>\n\n\n\nThe above command will do two things. First it will create a new branch locally called branching_blog_post, and secondly will switch my local git to make all changes to that directory.<\/p>\n\n\n\n
Now, we’ll do some work in that branch. I’ll create a new directory, and add a README.md file.<\/p>\n\n\n\n
Now, we can use the git status<\/code> command to show us what the difference is between what is on my file system and what is checked in to git.<\/p>\n\n\n\ngit status\nOn branch branching_blog_post\nUntracked files:\n (use \"git add <file>...\" to include in what will be committed)\n\n branching\/\n\nnothing added to commit but untracked files present (use \"git add\" to track)<\/code><\/pre>\n\n\n\nNow, we can use the git add<\/code> command to add those folders and files to our repo.<\/p>\n\n\n\ngit add branching\ngit status\nOn branch branching_blog_post\nChanges to be committed:\n (use \"git reset HEAD <file>...\" to unstage)\n\n new file: branching\/README.md<\/code><\/pre>\n\n\n\nNow that we have changes to be committed, we can commit those to our local branch.<\/p>\n\n\n\n
git commit -m \"added README.md\"<\/code><\/pre>\n\n\n\nNow, an important remark here. All changes are still local to my local git repo. They haven’t been pushed up to github.com yet. Commiting locally can help you keep track of the work you’ve actually done and give you the ability to rollback. To make our changes appear in github.com, we’ll need to use git push. However, out github repo doesn’t have this branch yet. When executing a simple git push, git will give you a command explaining how to make and push those changes to github.com<\/p>\n\n\n\n
git push --set-upstream origin branching_blog_post<\/code><\/pre>\n\n\n\nNow, we have our branch in github.com. We can switch to that branch to actually see that branch in github.com – and we can create a pull request on github.com to compare code and try to merge into master.<\/p>\n\n\n\nOur branch on github.com.<\/figcaption><\/figure>\n\n\n\nWe’ll now use the github.com website to make a pull request and merge into master. We’ll git the Compare & pull request button in the visual interface to do this. The interface is self-explanatory. You give the right level of information, and you create the pull request.<\/p>\n\n\n\n
Now, in our example this is just text. In real projects you typically see a PR build happening now to make sure that your PR succeeds a build definition and can pass certain tests. You can also assign mandatory code reviews on a PR, to ensure your code is up to standards. But in our demo, nothing of that is implemented.<\/p>\n\n\n\nThe visual interface will help in giving the right information for the pull request.<\/figcaption><\/figure>\n\n\n\nAnd finally, we can do the actual merge. Again, in real life people can make comments and ask you to make changes to your PR, but in our demo we’ll simply merge.<\/p>\n\n\n\nAnd now we are ready to merge.<\/figcaption><\/figure>\n\n\n\nNow, your branch is merged into master. Typically, you would now go ahead and delete the branch. For new work, you’ll create a new branch anyway.<\/p>\n\n\n\nYou can now go ahead and delete the branch.<\/figcaption><\/figure>\n\n\n\nConclusion<\/h2>\n\n\n\n Branching in git enables you to make changes to code without impacting your colleagues and keeps you code clean. In this post, we walked through a simple example of doing git branching. We used the command line to create and push the branch, and used github.com to merge the branch into master.<\/p>\n","protected":false},"excerpt":{"rendered":"
I am not a developer. I’m more of an infrastructure person, who delves into development sometimes. As part of a hackathon last week, my team and I ended up needing to do branches in git, and I had to shamefully admit that I always check-in to master. Most developers will be shooting me the same […]<\/p>\n","protected":false},"author":1,"featured_media":510,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,5,31],"tags":[54,52,53,55],"class_list":["post-507","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops","category-open-source","category-software-development","tag-branching","tag-devops","tag-github","tag-software-development"],"jetpack_featured_media_url":"https:\/\/nillsfblog.blob.core.windows.net\/media\/2019\/11\/image-19.png","_links":{"self":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/507","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/comments?post=507"}],"version-history":[{"count":1,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/507\/revisions"}],"predecessor-version":[{"id":512,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/507\/revisions\/512"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/media\/510"}],"wp:attachment":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/media?parent=507"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/categories?post=507"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/tags?post=507"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"\"](\"\/wp-content\/uploads\/2019\/11\/image-17.png\")
![\"\"](\"\/wp-content\/uploads\/2019\/11\/image-18.png\")
![\"\"](\"\/wp-content\/uploads\/2019\/11\/image-19.png\")
![\"\"](\"\/wp-content\/uploads\/2019\/11\/image-20.png\")