This
tutorial is exactly the same as the previous one, except that now dev1 and dev2 are more familiar with Git, and realized that
branches in Git are really just pointers, they are not as precious as in SVN.
So now once they push their changes to the remote repository, they delete their
local branches; and if they want to work on new things, they create new branches.
Day 1 end
This is the
end of day 1, dev1 is ready to
call a day, he is happy with this changes, and ready to push his changes to the
remote (we will assume dev1 is
almost the lucky one, and simplify his actions, in reality, everyone should take
similar actions as dev2) :
git checkout master
git merge t1
git push -v --tags --set-upstream origin
master:master
dev1 then deletes branch t1.
dev2 wants to do the same thing, he
first syncs up his local master with the remote master:
git checkout master
git pull origin master
Bad luck, dev2 finds out his branch t2 has deviated from master. He needs to get his changes
into master, so he merges t2
into master, and when he does
this, he runs into the dreaded conflict:
git checkout master
git merge t2
Git tries to
be smart, and performs an auto-merge, but it fails. Note, upon automerging
failure, Git has changed your file in the working directory, here is the
content of testf:
dev2 will need to manually resolve
this conflict (and delete those markers
<<<<<<< HEAD, =======, >>>>>>> t2),
he can signal to Git that the conflict has been resolved, and commit again (you
don’t need to do merge again, because you are still in the merge process):
git add testf
git commit
dev2 is happy and pushes his changes
to remote:
git push -v --tags --set-upstream origin
master:master
dev2 then deletes branch t2.
Day 2
dev1 syncs his local branch with the
remote master and creates a new branch t3:
git checkout master
git pull origin master
git checkout t3
And then he
commits 2 changes to t3,
echo 't3-c1' >> testf; git add testf;
git commit -m 't3-c1'
echo 't3-c2' >> testf1; git add testf1;
git commit -m 't3-c2'
And merges t3 into local master and pushes his
changes to the remote master:
git checkout master
git pull origin master
git merge t3
git push -v --tags --set-upstream origin
master:master
And then
delete t3:
git branch --delete t3
In our
script, dev2 is always the
unlucky one. He doesn’t realize his local master is behind, and he checks out t4 from the old master:
git checkout master
git checkout -b t4
echo 't4-c1' >> testf; git add testf; git commit -m 't4-c1'
Now he
realizes his local master is
behind, so he syncs up his local master
with the remote, and then anxious to make sure his changes are based on the latest
code, he merges master into his
local t2 and runs into a confict:
git checkout master
git pull origin master
git checkout t4
git merge master
Running git status
shows you:
So again dev2 needs to carefully resolve the
conflict (be sure to check out each marked lines). He then commits again:
git add testf
git commit
dev2 thinks his work is not finished
and is not ready to push to remote master,
so he keeps working on t2:
echo 't4-c2' >> testf; git add testf; git commit -m 't4-c2'
Day 3
The sun always smiles on dev1,
and he checks out t5, works on t5, and pushes to the remote master:
git checkout master
git pull origin master
git checkout -b t5
echo 't5-c1'>> testf; git add testf;
git commit -m 't5-c1'
git checkout master
git pull origin master
git merge t5
git push -v --tags --set-upstream origin
master:master
git branch --delete t5
Back to our
unlucky dev2, he is ready to
push his changes. First, he syncs his local master to remote, and then merges t5 into local master and runs into a conflict:
git checkout master
git pull origin master
git merge t4
Poor dev2, he needs to resolve the conflict
again.
git add testf
git commit
because he
has spent so much time on resolving the conflict, before he pushes his local master to remote, he syncs up his
local master with the remote just to be sure there are no changes made that
overlap his changes:
git checkout master
git pull origin master
git push -v --tags --set-upstream origin
master:master
Resulting
diagram looks like this which is exactly the same as in the previous tutorial:
Lessons
learned:
- Deleting a local branch after its changes are pushed into the remote repository makes the life of a developer much easier.
- And it is still true that it is much harder to use Git than SVN.
No comments:
Post a Comment