{"id":418,"date":"2021-09-19T13:10:00","date_gmt":"2021-09-19T21:10:00","guid":{"rendered":"http:\/\/spacefold.com\/colin\/morethanfour\/?p=418"},"modified":"2021-09-19T13:31:20","modified_gmt":"2021-09-19T21:31:20","slug":"learning-git-2-branching","status":"publish","type":"post","link":"https:\/\/spacefold.com\/colin\/morethanfour\/2021\/09\/19\/learning-git-2-branching\/","title":{"rendered":"Learning Git – 2: Branching"},"content":{"rendered":"\n

(Previously: Part 1 – The Basics<\/a>)<\/p>\n\n\n\n

Remember that a Git repository is a sequence of commits, where each commit includes a pointer to its “parent”.<\/p>\n\n\n\n

A branch<\/strong> in Git is just a pointer to one of those commits. There is a default branch typically called “master”. As we make commits, the master branch pointer moves forward along the sequence.<\/p>\n\n\n\n

We can create a second branch pointer named, say, “secundo”:<\/p>\n\n\n\n

$ git branch secundo<\/pre>\n\n\n\n
Now we have a new named pointer (branch), which currently also points to the same commit as “master”.<\/p>\n\n\n\n
Switching branches<\/h3>\n\n\n\n
We can switch to this branch, and continue making commits on it:<\/p>\n\n\n\n
$ git checkout secundo\n$ git switch secundo<\/pre>\n\n\n\n
Either of these commands will change the current branch to be “secundo” instead of “master”. switch is more recent syntax and I think it is clear in intent.<\/p>\n\n\n\n
As we make more commits, the “secundo” branch pointer advances to keep up. Meanwhile, “master” remains unchanged. We can switch back to it:<\/p>\n\n\n\n
$ git switch master<\/pre>\n\n\n\n
When we do this, the source files revert to what they were at the commit point that the “master” branch is pointing to. Any commits made now will advance the “master” branch pointer independently from the “secundo” branch: they will be pointing to different commit points in the repository history tree.<\/p>\n\n\n\n
Note:<\/strong> Git refers to the current state of the source directory as “HEAD”. It marks the current branch, and advances forward as commits are made on the current branch.<\/p>\n\n\n\n
So, when we switch back to “secundo”, HEAD is moving to that branch, and (naturally) the source files are restored to reflect the latest state of “secundo”.<\/p>\n\n\n\n
If you have files open in an editor, be alert for “file has changed outside the editor; reload?” warnings. And if your editor isn’t smart enough to warn you about file system changes, I recommend you find another editor.<\/p>\n\n\n\n
Important<\/strong>: any staged files are discarded when you switch branches. Also, any edits in the working tree will be discarded as the version from the switched-to branch is placed into the working tree.<\/p>\n\n\n\n
Branch management<\/h3>\n\n\n\n
Creating branches in Git is a very low impact operation. We can create and switch to a new brand in one step:<\/p>\n\n\n\n
$ git switch -c temp_stuff<\/pre>\n\n\n\n
Delete it when we’re done experimenting (you can’t delete the currently checked-out branch):<\/p>\n\n\n\n
$ git switch master\n$ git branch -d temp_stuff<\/pre>\n\n\n\n
Or rename it, if it turns out our experiments are worth keeping for later:<\/p>\n\n\n\n
$ git branch --move temp_stuff keep_stuff<\/pre>\n\n\n\n
Merging<\/h3>\n\n\n\n
So, I’ve made some changes in my “secundo” branch and I want to keep them and move them into the “master” branch. I could do this manually but one of the powerful features of using Git is that it can do this for us: Merging<\/strong> combines source file changes made in one branch with existing and possibly different changes made in another branch.<\/p>\n\n\n\n
First, we need to switch to the target branch, and then perform the merge:<\/p>\n\n\n\n
$ git switch master\n$ git merge secundo<\/pre>\n
Updating 82c55cb..fba73e5\nFast-forward\n README.md     |  4 ++--\n cow_tipper.py | 14 +++++++++++++-\n 2 files changed, 15 insertions(+), 3 deletions(-)<\/pre>\n\n\n\n
The source files in the directory have been updated, and contain the changes from the “secundo” branch. We end up with changes made in both branches.<\/p>\n\n\n\n
I could now delete the “secundo” branch if I wanted.<\/p>\n\n\n\n
Resolving conflicts<\/h3>\n\n\n\n
What happens if different changes are made to the same section of code in both branches? Let’s try it:<\/p>\n\n\n\n
$ git merge secundo<\/pre>\n
Auto-merging cow_tipper.py\nCONFLICT (content): Merge conflict in cow_tipper.py\nAutomatic merge failed; fix conflicts and then commit the result.<\/pre>\n\n\n\n
We can get some more advice from git status:<\/p>\n\n\n\n
$ git status<\/pre> \n
On branch master \nYou have unmerged paths.\n  (fix conflicts and run \"git commit\")\n  (use \"git merge --abort\" to abort the merge) \n\nUnmerged paths: \n  (use \"git add <file>...\" to mark resolution) \n     both modified: cow_tipper.py \n\nno changes added to commit (use \"git add\" and\/or \"git commit -a\")<\/pre>\n\n\n\n
Git is telling us that it couldn’t perform the merge automatically, and that we’ll have to correct it manually. Here’s what cow_tipper.py<\/strong> looks like in the “master” branch now:<\/p>\n\n\n\n
<<<<<<< HEAD\noutput_text = \"Cow Tipping For Beginners\"\nprint( output_text )\n=======\nfirst_cut = \"Cow Tipping: A Beginners Guide\"\nprint( first_cut )\n>>>>>>> secundo<\/pre>\n\n\n\n
I’ll have to decide which variable name is best, and which output text string is correct, and make the edits, and then commit the changes into “master”.<\/p>\n\n\n\n
How do I…?<\/h3>\n\n\n\n
Return to the previously checked-out branch<\/h4>\n\n\n\n
$ git switch -<\/pre>\n\n\n\n
Retrieve files by tag<\/h4>\n\n\n\n
Probably the best way is to use a temporary branch and then checkout the tag:<\/p>\n\n\n\n
$ git branch tmp_v0_0_0\n$ git switch tmp_v0_0_0\n$ git checkout v0.0.0<\/pre>\n\n\n\n
Further reading<\/h4>\n\n\n\n
There’s a whole chapter on this and it is worth digging into:<\/p>\n\n\n\n