-
Notifications
You must be signed in to change notification settings - Fork 31
/
chap9.tex
147 lines (113 loc) · 11.4 KB
/
chap9.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
% chap9.tex - Week 9
\cleardoublepage
%\phantomsection
\chapter{A little extra help}
\section{Taking things further}
We have completed our journey through eight weeks of intensive version control usage at Tamagoyaki Inc.
However, there are probably still many questions that you have regarding Git and its usage.
This chapter focusses on taking a few of the topics that were discussed a little further but does not go into as much detail as was presented in the rest of the book.
The reason for this is purely that as the tasks you are trying to achieve become more complex, they often require greater knowledge about the implementation details
and are often heavily customised to fit a particular scenario.
Also, some of the topics are rather specialised and are not of use to everybody, so taking a large amount of time discussing them may be a little redundant for the majority of the people reading the book.
If you have read through weeks 1-8, and supplemented it with the After Hours sections, you should have a very good understanding of the Git system.
As with most things practice makes perfect and it is important to play with any new system before using it in earnest.
If you are planning to migrate away from an existing version control system, take some time to test your current processes and procedures in Git to ensure that it will fit your needs.
Always keep in mind that no matter which system you try to introduce, there will nearly always be resistance from someone.
So let us touch on a few more topics and just wrap up a few loose ends.
\subsection{Collaborating with a larger audience}
We looked at a few tools within the Git system to allow access to a Git repository, but what if you want to share your repository with a larger audience.
As stated earlier, the implementation of the tools in our testing was suitable for merely that, testing.
In a production environment one would should never use the instaweb tool for a providing a permanent setup where people can browse a repository over HTTP.
There are two distinct methods for handling the distribution of Git repositories to larger audiences.
Generally people will either, set up the server themselves or use a third party system to host their repositories.
\subsubsection{GitHub}
No book on Git would be complete without at least a small section on GitHub.
GitHub is a third party site for hosting and interacting with Git repositories.
All of the information about GitHub is correct at the time of going to print.
GitHub offers the ability to host both public and private repositories.
Public repositories can be hosted for free, whereas private repositories require a subscription fee, however the pricing is tiered to allow you to start small and gradually grow your usage.
Repositories can be pulled via HTTPS, SSH and Git protocols which allows you to be entirely flexible in the methods you use to keep up to date.
Pushing to the repositories can be achieved via HTTPS or SSH, which again is rather flexible.
The real beauty of GitHub is how it is presented.
GitHub has a tagline of \emph{Social Coding} and it really does live up to that name.
People can fork your project, which basically means they have cloned it to their account in GitHub.
Whenever they make commits to their fork, you can see these changes pop up in a section of the site called Network.
GitHub also allows you to edit files directly on the site and commit them.
This means that wherever you are, as long as you have a connection to the Internet and a browser, you can edit files in your repository and commit them.
When you return home, you can issue a pull and the changes will appear on your local system.
For open source projects, GitHub really does offer a wealth of features for collaborative coding.
When a collaborator has made enough changes to fix a bug or a feature, they can issue a pull request.
This sends a notification to you that Person X would like you to merge their changes into your branch.
If there are no conflicts these pull requests can be manage straight from GitHub, without requiring you to checkout the remote branch, merge it and push it back again.
You can also comment on lines in the diff and many more features.
Indeed during the writing of this book, several contributors used GitHub to make pull requests containing spelling mistakes and design suggestions.
\subsubsection{Hosting yourself}
Many people choose to host themselves, be it for security or control reasons.
Sometimes people do not want to have their data \emph{online} and prefer to keep it internal to the company, this may be due to IP, license or other restrictions.
However, it should be noted that this option does not pose a problem to the implementation of Git.
Though you may not have access to the fancy interface features of GitHub, you still get the raw power of Git in your workplace.
Apache is a common implementation of Git for companies as it is a robust webserver which offers the ability to serve and receive data through HTTP and HTTPS with a Git repository.
We are not going to go into the implementation details of such a set up as each one is different.
There are many tutorials on the Internet that deal with such set ups in different situations and for different purposes.
SSH is also a good choice for implementing a Git repository and there are several means of securing the Git repository to allow only certain users access to certain paths etc.
Git by default does not really have a security access control layer but then that is realy by design more than anything else.
Git was intended to be used by open source projects to share and collaborate on code.
However, this does not mean it can not be used on closed source projects, just that sometimes some modifications need to be made if more advanced features like access control are required.
Many people rely on the work flow processes to ensure that things are done in a secure manner.
If you have a blessed repository and have some dictators who are responsible for integrating code into it, it should be up to them to ensure that Developer X does not try to commit changes to Module Y.
\subsection{Taking out the garbage}
Something that we glossed over is the subject of garbage collection.
Git handles this for us, routinely deleting objects that are older than a certain time period from the object database, as long as they are no longer referenced by any branches.
So by this we mean that an object that exists only in one branch will only remain imune to garbage collection whilst that branch is alive.
As soon as we delete the branch, all objects that are not longer referred to in any tree are left in a \emph{dangling} state and may be deleted when garbage collection runs.
Of course as stated earlier, Git holds on to objects for a period of time for you, to make sure you do not do anything silly, like delete a branch you actually really wanted.
You can invoke a garbage collection manually, but it is often better to let Git handle these things for you, unless you have a specific reason for doing so.
\subsection{But how do you really know....you know?}
When obtaining source code via an insecure means, over the Internet for example,
there are times when you would really like to be as sure as possible that someone has not tampered with it.
Let us take an example of someone distributing their content using a Git repository.
An attacker takes control of the repository, puts in some malware and tags the commit as release version 1.0.
People start do download it and as you can imagine all hell breaks loose.
It does not have to be this way.
Many developers and Internet users use GPG to encrypt and sign their emails and documents.
GPG is a tool which can be employed to both encrypt files so that they can only be read by the intended recipient, or to sign documents and files, such that you can be reasonably sure that document is the same as when the person signed it.
The private GPG \emph{key} of the signing party is used along with the file to generate a code which is sent along with the email.
When it reaches the recipient a check can be made against the users public key and the content of the email, to validate that said user did actually sign that particular document or file.
Git allows you to use GPG signing for tags.
This gives people piece of mind that unless an attacker has gained access to both the repository and the developers private GPG key, if the sign a tag, that tag is exactly as it was intended.
To use Git in this way, you must first set up a GPG key, which is out of scope of this book.
Once you have this key, you can change your config like the example below, to tell Git to use a particular key when signing.
\begin{code}
git config user.signingkey 0xABCDEFG
\end{code}
Then when you want to sign a tag, simply append the \texttt{-s} parameter to the \texttt{git tag} command.
You can also verify someone elses signed tag by running \texttt{git tag -v <tagname>}
\section{The end of the journey}
Well we have reached the end of our journey.
We have taken a look at many of the aspects of both Git and the mechanisms by which it can be used.
As the workflow of actually using Git is so open, you will have to decide for yourself how you want to collaborate with others.
Do not worry if you do not get it right first time.
Try a test repository and make up scenarios, just like we have in the book, to test your workflows.
Using a version control system is not an exact science and should never be something that people dislike so much that they resent using it.
A good implementation of a version control system invents minimal work for the users, whilst giving themall the benefits we have desribed throughout.
Remember if your users dislike the system, the chances are they will not use it properly and sometimes will try at every stage to avoid it.
Help them to understand why you are using a version control system and get them onside early.
You will find the procedure will be much less painless.
Before we sign off for good, let us take one more trip back to the trenches to see how things panned out.
\begin{trenches}
``Well I have to say guys there were points during this project that I didn't think we'd ever complete it'' said Markus with a grin on his face.
The rest of the team all smiled, including Klaus.
``It wasn't the easiest thing we've ever done,'' started John, ``but it sure has helped us out in so many ways.''
Markus grinned, ``Well ya big bunch of gits, hows about we head off early today and take a trip to the pub. First round is on me.''
The room roared with shouts and cheers as they began to file out of the room, gather their things and head towards the Dog and Duck.
\thoughtbreak
The team had been in the pub for well over two hours and several of Tamagoyaki Inc's were beginning to feel the effects of the consumption of alcohol.
Martha and John had broken away from the rest of the pack and were sat on a table on their own.
It hadn't been intentional, but their conversation hadn't seemed to fit with the rest of the team.
``Thanks for all the help John,'' started Martha, ``You've been really good to me.''
``Hey! I'm just glad you're on my team.'' he replied. ''We certainly couldn't have done it without you.''
At that point the effects of the alchopop were too much for Martha.
Her cheeks began to flush a bright shade of red, and in a totally out of character manouver she leant across the table and kissed John.
The rest of the team caught a glimpse of the events taking place in the isolated environment and cheered loudly.
``Geee, it's about time,'' jeered Klaus.
\end{trenches}