Attention: : Confluence is not suitable for the storage of highly confidential data. Please ensure that any data classified as Highly Protected is stored using a more secure platform.
If you have any questions, please refer to the University's data classification guide or contact ict.askcyber@sydney.edu.au

3. Extending the development timeline

Owned by Stephen Kolmann
Last updated: Nov 03, 2017
4 min read

Branch

  • Nearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects.
  • The branch operation is what you use when you want your development process to fork off into two different directions. For example, when you release version 3.0, you might want to create a branch so that development of 4.0 features can be kept separate from 3.0.x bug-fixes.


  • Create a branch for developing the README feature, and call the branch "readme"

$ git branch readme

  • Show available branches

$ git branch
* master
  readme


  • Switch to the new branch

$ git checkout readme
Switched to branch 'readme'


  • Add new content to our README.txt file

$ echo "This is our README feature being created on a different branch" >> README.txt
$ cat README.txt
This is my readme file
This is our README feature being created on a different branch

$ git status
On branch readme
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified: README.txt

no changes added to commit (use "git add" and/or "git commit -a")



  • Save the changes to our Branch

$ git commit -a -m "New Version of our README Feature"

[readme 0a3a250] New Version of our README Feature
 1 file changed, 1 insertion(+)

We've saved our changes, but would our branch be available on the remote repository too?

Lets Check

$ git remote show origin
* remote origin
  Fetch URL: https://github.com/rafaelpossas/git_tutorial.git
  Push  URL: https://github.com/rafaelpossas/git_tutorial.git
  HEAD branch: master
  Remote branch:
    master tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)


The only remote Branch is master, therefore, we need to push our README branch to our remote repository

  • Push our branch to the remote repository

$ git push origin readme:readme  # local_branch_name:remote_branch_name

Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 386 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/rafaelpossas/git_tutorial.git
 * [new branch]      readme -> readme


Lets check whether our branch is available in the remote repository

$ git remote show origin
* remote origin
  Fetch URL: https://github.com/rafaelpossas/git_tutorial.git
  Push  URL: https://github.com/rafaelpossas/git_tutorial.git
  HEAD branch: master
  Remote branches:
    master tracked
    readme tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local refs configured for 'git push':
    master pushes to master (up to date)
    readme pushes to readme (up to date)


Merge

  • Typically when you have used branches to enable your development to diverge, you later want it to converge again, at least partially. For example, if you created a branch for 3.0.x bug-fixes, you probably want those bug-fixes to happen in the main line of development as well. Without the merge operation, you could still achieve this by manually doing the bug-fixes in both branches. Merge makes this operation simpler by automating things as much as possible.
  • Suppose our feature README is done and we no longer need a separate branch. The merge operation will get all the files from the separate timeline and put them back into our master branch. The user can choose to keep the branch or remove it if it is no longer used.
  • When merging we always start at the branch we want to merge to. In this case we want to merge from README to master

$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

$ git merge readme
Updating 8ac8493..0a3a250
Fast-forward
 README.txt | 1 +
 1 file changed, 1 insertion(+)


  • Our master branch now has being "fast-forwaded" with all the commits from our branch, lets check how our timeline history looks now

$ git log
commit 0a3a2509b7efe7a6f0e79ed3f9108850f0150cae
Author: Rafael Possas <rafael.possas@sydney.edu.au>
Date: Fri May 26 12:08:51 2017 +1000

    New Version of our README Feature

commit 8ac84931c3671d115cb8297612c7b7eb9b691653
Author: Rafael Possas <rafael.possas@sydney.edu.au>
Date: Fri May 26 11:22:05 2017 +1000

    My first commit & Understanding Diff & Add Readme.txt


The commit created in our README BRANCH is now merged back into our master branch


  • Push our changes to the remote repository

$ git push origin master

Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/rafaelpossas/git_tutorial.git
   8ac8493..0a3a250 master -> master

$ cat README.txt
This is my readme file
This is our README feature being created on a different branch