In this movie, we will look at an example workflow showing how to use Git to collaborate with another user.
My hope is that this kind of real-world example will help to give you a big picture and will
pull together all the different pieces that we have learned.
But we are not going to actually make the changes, that would take more time and would
also keep you from seeing the workflows clearly.
For this example, I am going to collaborate with my coworker Lynda on adding a new feature
to the Explore California web site and our new feature will be a feedback form, so the
customers of Explore California can share their comments and feedback.
Let's start by looking at what my work would look like.
Now this is an ongoing project.
I've already got my repositories set up, and I have already pushed at least the master
branch up to the remote repositories.
So let's assume that we have already done that ahead of time, I am just logging in today
to create this new feature.
I am already on my master branch, if I'm not, then I will check out the master branch that
I start there at master.
And then the very first thing that we want to do every day, every time we start work,
every time we have been away from the computer for a few hours, we want to do a git fetch.
We want to find out what new commits have been made and pushed to the repository since
the last time we checked in.
So I do my git fetch, and it turns out that there was work done overnight by some of my
coworkers. Their commits are unrelated to the feature that I'm about to add, but I still
want to make sure that I have to master.
So the next thing I want to do is I want to merge those changes which are in origin/master
into my master branch.
Now at this point, my branch of master is totally in sync with what's on the remote
repository, and I am ready to start my work.
I am going to do the work on my new feature in the separate branch, and that way it won't
interfere with anything that's going on with master.
And if in the end we decide not to do the feature for some reason, it's easy to just throw it away.
So the next thing I want to do is create that branch, and I will do that using checkout
-b that will check it out as a new branch, or create the branch and switch to it.
So now even though the contents of my working directory are the same as master, I've
switched to my new feedback form branch.
So I open up my working directory, I make the changes that I want there, in this case
I am going to be adding a page called feedback.html, and I go in, and I edit the form and get it
all look exactly like I want.
When I am done, then I am ready to make my commit.
So I add it to the staging area, and then I commit it.
At this point, my changes are now on my local repository inside my feedback form branch.
I am not ready to merge them into master just yet, I want my coworker Lynda to have a look at them as well.
So I need to put them on the remote repository for her to see them.
Before I push them up there though, I want to do a git fetch again and find out if there
been any more commits that have come in that I need to take into consideration.
If there have been, then I want to take a look at those and see whether I need to bring
them into my feedback branch or not.
In this example there were no other commits on master.
I can go ahead, and I can push my branch up to origin, and I am pushing the whole branch,
not just to commit.
The branch doesn't exist up on the remote server until I push it.
So I use git push, origin feedback_form, and then I also use that -u option.
You will remember that makes it a tracking branch, so now in the future, I will continue
to track changes from feedback_form, and it will save me some typing, because git will
know where I want to push to without having to tell at each time.
So when that's done, my work is now on the remote repository, now my coworkers can all see it.
So I send an email to Lynda saying hey Lynda, remember that discussion we had last night
about adding the feedback form? Well I did a draft of it, and I put it up on the remote.
Can you take a look and let me know what you think?
So now let's switch over, and let's look at things from Lynda's point of view.
So Lynda also already has the repository, she has been working on it for couple of weeks.
If she hadn't been, we know that she would do a git clone, in order to get the repository,
and she is also going to be on the master branch, if not we will go ahead and just switch
to make sure that she is there.
The very first thing that Lynda is going to do, she needs to do a git fetch. Always the
first thing. Until she does that fetch, she can't even see the branch that I pushed up there.
Her computer hasn't sunk up so it doesn't have that information about all of the other
branches that might be available.
After the git fetch though, now git branch -r will show her that new branch, and she can see it.
There were changes that came in over night from other coworkers, so she will probably want
to incorporate those into her master branch to just to make sure that master is always
brought up to date.
It's not strictly necessary, but it's a good practice.
After she has done that, she will be ready to take a look at my work.
So she will want to check out the branch that I pushed up there.
Again she will use check out with the -b option.
This time she won't just say feedback form which would take it from the branch that she's
currently on, her version of master, instead she will say feedback form and the source
from that is going to be origin feedback form, the one that I put up there.
It will also make it a tracking branch at the same time, so she wants to see what I
did, she is going to use git log and she can find the commit that I made or added feedback.form.html.
She can also take a look at the actual commit itself, she will use the SHA probably. She
could also use HEAD if that was still the last commit and see what that said. She could
also use the branch name, git show feedback_form, and as long as it's the last commit that's
the one she would see.
After looking at my commit and bringing it up in the browser to take a look there, Lynda
decides that we should add a select option to the form so that customers can pick which
tour they took and include that with the feedback, and that way we will know which tour they
are referencing when they talk about the tour that they took.
So she makes that change and then she commits it and she does that using the -a option so
that it both adds it to staging and commits it all at the same time.
Now she has got that change on her local machine, she needs to put it on the remote where I
can see it. So she does a git fetch to make sure no new changes have come in, they haven't
so she does a git push.
At this point Lynda is done.
So she sends me back an email saying, it looks great I just made one quick change.
On my side again, I want to see what change she has got, so the very first thing I do
is fetch, so I can see the change.
Before I merge it in though, I want to take a look at it, so I am going to using git log.
I am going to use the -p option which is for patch, and it will show each of the log entries
with a diff of all the changes that were made in that log entry.
And I am going to ask it to show me everything from feedback form, my copy, up to where origin
feedback form is. That's the difference between the state of mine and the state of what Lynda
pushed up to the repository.
So I can look at those, and I can take a look at all the changes that she made, those changes
look fine, I like them.
So I am going to now go ahead and merge them into my feedback branch.
So at this point now, the feedback_form branch is in sync between me, the remote repository
and Lynda. We all have the same things.
In this case the merge was a fast-forward merge, so there is really nothing to commit,
but if I had made other changes in the mean time that I needed to merge in, well then
I would merge those together, and we will push the result back up to the remote.
But since I didn't, since it was a simple fast-forward merge, I am ready to now call
this feature finished and to fold it back into the master branch.
So I am going to switch back to the master branch, after I switch branches, I want to
do a git fetch and find out if there were any changes that came in, while I was looking
at Lynda's changes.
If there were new changes that came in, I am going to merge those back into origin/master.
At this point now, master is completely up to date. I definitely want to make sure I
have got master as up to date is possible before I do this next step.
Then next step is that I am going to merge in the changes from feedback form.
I am going to take the new work and merge it into the most recent possible state of master.
I did a merge from feedback_form but I could have just as easily done a merge from origin feedback_form.
They both point to the exact same commit and then after I have made that merge, and I've
resolved any kind of merge conflicts that might have come up, then I do git push, and
now my work is on the remote in the master branch where all of my coworkers can see it,
where it can eventually be deployed on the Explore California web site.
That gives an idea of the process which you go through when you're collaborating with the coworkers.
It may change because you may be collaborating with three or four different people, you may
all be checking in and out things, but it's the same basic kind of process over and over again.
It may seem like a lot to remember when you're a beginner, but it becomes second nature very quickly.