As we saw earlier,
it is eminently possible to be able to go ahead and revert our code,
but ideally we don't present our development code to the main repository,
we don't want to use this downloading code that's not currently tested.
So we develop our code within branches, and once we're finished with that,
we can take a look at merging our code back.
So we can move back to our project directory, whatever we've called it.
We can check out a brand‑new branch by implementing the ‑b switch.
We can go in and edit our script however we want.
Once we're ready,
we can go through and commit those changes and push them back to the server.
Here we have to push then to the origin the development branch,
rather than the master branch.
That's where we've made our changes.
Ideally, we don't check our own code, we have another developer.
Now that might be a senior developer or a developer at the same level,
but they can then go through and delete their originally downloaded project.
They can clone if they like just a specific branch,
so clone with ‑b and the branch name of dev.
They can move into their project directory.
Obviously,
checking the status is just going to tell them that
they are working in the dev branch.
We can execute the script and make sure that it runs the way that it should.
If we're happy with the code,
we can then go through and check out the master and
we can merge with the dev branch.
At this stage, our dev branch and our master branch are now going to be the same,
but we haven't risked the integrity of our master
branch by making changes directly in it.
Come on, I think we need a demonstration,
and that's exactly what we're going to get.
We're going to take a look at how we develop our code by creating a new branch,
developing in that, and then look at how we merge our branches back.
And here we are at our glorious command line, and I do emphasize the term we.
I want you to be following along so you really do gain the experience.
Now we've seen before that we can edit our master branch directly.
When we look in git status, we can see that we're working on our master branch.
So we're going to create ourselves a new development branch,
so git checkout, ‑b so we can create a new branch,
and I'm just going to call it dev.
We can see now that I've switched to the new branch.
I can go ahead now and edit my Python script,
so I can log in at python and my.py.
We might decide that rather than printing datetime.datetime.now,
we create a variable first.
So I can easily go through and change this.
Again, we're not really learning Python here,
but if I go through and set my date variable equals,
I don't need the closing parentheses, that was for print,
so I can clear that off, and then we can go through and print the date variable.
Now they're very simple changes, so I'll be quite happy that that's working,
but it's been developed in my development branch.
So, again, I can go through and look at my git status.
We can see that I'm on the branch dev, we can see my modified file,
so everything is the same.
I go through and do a git add.
We can run then our git commit ‑m "tidy code".
We could probably put a better message than that,
but that is fine for us at the moment.
And now we're ready to push it back,
but we go git push to the origin and the dev branch.
So, again, now we've pushed that up to our remote repository,
and presumably we're going to ask somebody to work with it.
I might for safety's sake go through and just move back to my
master branch so I'm back on the production code,
not the development code, but that's down to personal preference.
On our senior developer, or at least our colleague who's going to check our code,
we can go ahead and remove our play and project1 directory.
Technically,
we could move into that directory and just switch to the
development branch with the checkout,
but we want to show you that you can clone using the ‑b option.
So we can move into our play directory, we can run our git clone ‑b.
We want the dev branch,
so we can just bring down the branch that we need to check.
And we can then go through and, of course,
specify that we're looking in our git and project1.
So if I move into our project1 directory,
representing then what we've downloaded,
when we look at git status, we're already in our dev branch.
We can check the code, it is working perfectly well,
so we can go through and execute then from our python directory, my.py.
So, of course, it's working exactly the same way as we saw before,
but if I go through and cat that out,
we can see then it's got the change where we're implementing the date variable,
so the code is probably just a little easier to read.
Once we're happy with our change, then we can go through and git checkout master.
With that done,
we are now working on our master branch and we can then go
through and do a git merge and then dev.
At this stage, our master now has the new code,
but we haven't had that risk of having the master having unverified code that
hasn't really been signed off by our main development team.
Now we're ready to do that, our master code now is up to date.
We still have master and dev,
but we've just synchronized our master through to the current commit in dev.
So we're all up and running with this.
If I look at my git status, then we can see then that we're on the master.
There's nothing to commit, nothing to save,
but we then have to go through and push back to our master.
So I can go through and do a git push.
So we sent the information from my local master to the remote master,
our remote server now is up to date.
But there you go, you are a Git expert.
Do practice this, but you're going to find this useful even if you're just using it yourself.