-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathcollaboration.html
More file actions
367 lines (310 loc) · 20.1 KB
/
Copy pathcollaboration.html
File metadata and controls
367 lines (310 loc) · 20.1 KB
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
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Working with Others — Git & GitHub Handbook</title>
<meta name="description"
content="Add collaborators to a private repo, open and review pull requests, resolve merge conflicts, use Issues and Projects, and contribute to open source.">
<link rel="stylesheet" href="style.css">
</head>
<body>
<button id="navToggle" class="nav-toggle" aria-label="Toggle table of contents">☰ Contents</button>
<div id="navOverlay" class="nav-overlay"></div>
<div class="app">
<nav class="sidebar" id="sidebar" aria-label="Table of contents">
<div class="sidebar-inner">
<a href="index.html" class="brand">
<span class="brand-mark">git</span>
<span class="brand-sub">& github</span>
</a>
<p class="sidebar-tagline">A no-nonsense guide for people who've never touched a terminal.</p>
<div class="site-nav">
<p class="site-nav-label">Guides</p>
<ul class="site-nav-list">
<li><a href="index.html">Home</a></li>
<li><a href="git-basics.html">1. Git Basics</a></li>
<li><a href="github-guide.html">2. GitHub Essentials</a></li>
<li><a href="collaboration.html" class="current">3. Working with Others</a></li>
<li><a href="profile.html">4. Profile & Portfolio</a></li>
<li><a href="tips-tricks.html">5. Tips & Tricks</a></li>
</ul>
</div>
<p class="toc-label">On this page</p>
<ul class="toc-list">
<li><a href="#collaborators">Adding Collaborators</a></li>
<li><a href="#orgs">Organizations & Teams</a></li>
<li><a href="#pr">Pull Requests</a></li>
<li><a href="#review">Reviewing & Merging</a></li>
<li><a href="#conflicts">Merge Conflicts</a></li>
<li><a href="#opensource">Contributing to Open Source</a></li>
<li><a href="#issues">Issues & Projects</a></li>
<li><a href="#protect">Protecting main</a></li>
<li><a href="#cheat3">Cheat Sheet</a></li>
</ul>
<a class="sidebar-footer-link" href="https://www.linkedin.com/in/muhammad-hamza-naqi-569741403/"
target="_blank" rel="noopener noreferrer">Connect with the author →</a>
</div>
</nav>
<main class="main" id="top">
<div class="content">
<header class="hero">
<p class="eyebrow">Part 3 of 5 · Beginner's Handbook</p>
<h1>Working with Others</h1>
<p class="lede">Once more than one person touches a repo, Git and GitHub earn their keep. This
part covers giving people access, proposing and reviewing changes with pull requests, and
untangling the merge conflicts that come with teamwork.</p>
</header>
<hr>
<div class="note-card">
<p><b>Jumping in here?</b> This chapter assumes you've already got a repo pushed to GitHub and
know your way around branches. If not, <a href="git-basics.html#branches">branches are
covered in Part 1</a> and <a href="github-guide.html">pushing your first repo is in Part
2</a>.</p>
</div>
<section id="collaborators">
<h3><span class="num">01</span> Adding Collaborators to a Private Repo</h3>
<p>For a small project — you and a few friends or teammates — direct collaborator access is the
simplest option:</p>
<ul>
<li>Open the repo on GitHub → <b>Settings</b> → <b>Collaborators</b>.</li>
<li>Click <b>Add people</b> and search by their GitHub username or the email on their
account.</li>
<li>They'll get an invite email or notification, which they need to accept before they get
access.</li>
<li>Once accepted, they can clone the repo with their own GitHub login and push directly —
no forking needed.</li>
</ul>
<div class="note-card">
<p><b>Permission levels</b> when adding a collaborator: <b>Read</b> (view and clone only),
<b>Triage</b> (manage issues/PRs but not code), <b>Write</b> (push code — the usual
choice for a teammate), <b>Maintain</b> (Write plus some repo settings), and
<b>Admin</b> (full control, including deleting the repo). Give people the lowest level
that lets them do their job.
</p>
</div>
</section>
<hr>
<section id="orgs">
<h3><span class="num">02</span> Organizations & Teams</h3>
<p>For anything bigger than a handful of people, create a GitHub <b>Organization</b> instead of
adding collaborators one by one to each personal repo:</p>
<ul>
<li>From the <b>+</b> menu top-right → <b>New organization</b> — free plans cover most
student and small-team needs.</li>
<li>Repos live under the organization (<code>github.com/your-org/project</code>) instead of
a single person's account, so the project survives even if someone leaves.</li>
<li>Create <b>Teams</b> inside the org (e.g. "frontend", "backend") and grant a team access
to specific repos at once, instead of managing each person individually.</li>
<li>The same permission levels from above (Read → Admin) apply per team, per repo.</li>
</ul>
</section>
<hr>
<section id="pr">
<h3><span class="num">03</span> Pull Requests — Proposing Changes</h3>
<p>Even with push access, the standard workflow on a team is to never commit straight to
<code>main</code>. Instead, you work on a <a href="git-basics.html#branches">branch</a> (a
separate copy of the project to work in safely) and open a <b>Pull Request</b>, or
<b>PR</b> for short — a request asking for your branch to be merged into main — this is what
gives teammates a chance to review before anything lands.</p>
<h4>Opening a PR from the GitHub website</h4>
<ul>
<li>Push your branch: <code>git push -u origin feature/login-page</code></li>
<li>GitHub shows a yellow banner on the repo page: <b>"Compare & pull request"</b> — click
it.</li>
<li>Write a clear title and description of what changed and why, then click <b>Create pull
request</b>.</li>
</ul>
<h4>Opening a PR from the terminal (GitHub CLI)</h4>
<div class="term">
<div class="term-bar"><span class="dot dot-r"></span><span class="dot dot-y"></span><span
class="dot dot-g"></span><span class="term-title">terminal</span></div>
<div class="term-body">
<div class="line"><span class="prompt">$</span><span class="cmd">git push -u origin
feature/login-page</span></div>
<div class="line"><span class="prompt">$</span><span class="cmd">gh pr create --fill</span>
</div>
</div>
</div>
<p><code>--fill</code> uses your branch name and commit messages to auto-fill the title and
description, so you can skip typing them out again.</p>
</section>
<hr>
<section id="review">
<h3><span class="num">04</span> Reviewing & Merging</h3>
<ul>
<li>On the PR page, click <b>Reviewers</b> and pick a teammate — they get notified.</li>
<li>A reviewer can leave inline comments on specific lines, then <b>Approve</b>,
<b>Request changes</b>, or just <b>Comment</b>.
</li>
<li>From the terminal, a reviewer can pull down the PR's branch to test it locally before
approving: <code>gh pr checkout 42</code> (where 42 is the PR number).</li>
</ul>
<p>When it's approved, you'll get three merge options on GitHub:</p>
<ul>
<li><b>Merge commit</b> — keeps every individual commit plus a merge commit tying them
together. Full history, a bit noisy.</li>
<li><b>Squash and merge</b> — combines all the branch's commits into a single clean commit
on main. Most teams default to this for tidy history.</li>
<li><b>Rebase and merge</b> — replays the branch's commits onto main individually, no merge
commit at all. Keeps history linear.</li>
</ul>
</section>
<hr>
<section id="conflicts">
<h3><span class="num">05</span> Resolving Merge Conflicts</h3>
<p>A conflict happens when two people change the <i>same lines</i> of the <i>same file</i>
differently. Git can't guess which version you want, so it stops and asks you. This is
normal — it doesn't mean anything is broken.</p>
<p>After a <code>git pull</code> or <code>git merge</code> that hits a conflict, the affected
file will contain markers like this:</p>
<div class="file">
<div class="file-bar">app.js</div>
<div class="file-body">
<<<<<<< HEAD<br>
const greeting = "Hello there";<br>
=======<br>
const greeting = "Hey!";<br>
>>>>>>> feature/login-page
</div>
</div>
<ul>
<li>Everything between <code><<<<<<< HEAD</code> and
<code>=======</code> is <i>your</i> current version.
</li>
<li>Everything between <code>=======</code> and <code>>>>>>>></code> is
the incoming version.</li>
<li>Edit the file by hand to keep whichever line (or a mix of both) is correct, then delete
all three marker lines completely.</li>
</ul>
<p>Once every conflicted file is cleaned up:</p>
<div class="term">
<div class="term-bar"><span class="dot dot-r"></span><span class="dot dot-y"></span><span
class="dot dot-g"></span><span class="term-title">terminal</span></div>
<div class="term-body">
<div class="line"><span class="prompt">$</span><span class="cmd">git add app.js</span>
</div>
<div class="line"><span class="prompt">$</span><span class="cmd">git commit -m "resolve
merge conflict in app.js"</span></div>
</div>
</div>
<div class="note-card">
<p><b>Avoiding conflicts in the first place:</b> pull often, keep branches short-lived, and
avoid two people editing the same file at the same time when you can help it.</p>
</div>
</section>
<hr>
<section id="opensource">
<h3><span class="num">06</span> Contributing to Someone Else's Project</h3>
<p>If you don't have write access to a repo — most open-source projects — the workflow is fork
first, PR last. (<b>Forking</b> means making your own copy of someone else's repo under your
own account — <a href="github-guide.html#clonefork">covered fully in Part 2</a> if you
haven't done it before.)</p>
<ul>
<li>Click <b>Fork</b> on their repo to get your own copy under your account.</li>
<li>Clone <i>your fork</i> locally and create a branch for your change.</li>
<li>Commit and push to your fork, then open a PR — but this time GitHub targets it
<i>from your fork's branch</i> back <i>to the original project's main branch</i>.
</li>
<li>Keep your fork in sync with the original as it moves on, so your PR doesn't fall too far
behind. <code>upstream</code> here is just a common nickname for "the original repo I
forked from" — not a special Git keyword, you could name this remote anything:
<div class="term">
<div class="term-bar"><span class="dot dot-r"></span><span
class="dot dot-y"></span><span class="dot dot-g"></span><span
class="term-title">terminal</span></div>
<div class="term-body">
<div class="line"><span class="prompt">$</span><span class="cmd">git remote add
upstream https://github.com/original-owner/project.git</span></div>
<div class="line"><span class="prompt">$</span><span class="cmd">git fetch
upstream</span></div>
<div class="line"><span class="prompt">$</span><span class="cmd">git merge
upstream/main</span></div>
</div>
</div>
</li>
</ul>
</section>
<hr>
<section id="issues">
<h3><span class="num">07</span> Issues & Projects</h3>
<p><b>Issues</b> are GitHub's built-in ticket system — use them to track bugs, feature requests,
or tasks. Anyone with access can open one from the <b>Issues</b> tab, assign it to someone,
label it, and reference it directly from a commit or PR by writing <code>#12</code> (issue
number) — GitHub auto-links it. Write <code>Closes #12</code> in a PR description and
merging that PR will close the issue automatically.</p>
<p><b>Projects</b> is a Kanban-style board (To do / In progress / Done) you can attach issues and
PRs to, giving the whole team a visual overview of what's being worked on — find it under the
<b>Projects</b> tab on a repo or organization.</p>
</section>
<hr>
<section id="protect">
<h3><span class="num">08</span> Protecting the Main Branch</h3>
<p>Once a team is pushing regularly, it's worth stopping accidental direct pushes to
<code>main</code>. Under <b>Settings → Branches → Add branch protection rule</b>, you can
require:
</p>
<ul>
<li>At least one approving review before a PR can be merged.</li>
<li><b>Status checks</b> to pass first — automated checks (usually tests) that run on every
push, often set up with GitHub Actions (see <a href="tips-tricks.html#actions">Part
5</a>). A red ✗ next to a PR means a check failed and it can't be merged yet.</li>
<li>No one — including admins — to push directly, forcing everything through a PR.</li>
</ul>
<p>This is usually the first setting a team enables once more than two people are pushing to the
same repo.</p>
</section>
<hr>
<section id="cheat3">
<h3><span class="num">09</span> Collaboration Cheat Sheet</h3>
<table class="git-cheat-sheet">
<tr>
<td class="command">gh pr create --fill</td>
<td>Open a pull request from your current branch</td>
</tr>
<tr>
<td class="command">gh pr checkout <number></td>
<td>Pull down someone else's PR branch to test locally</td>
</tr>
<tr>
<td class="command">gh pr view --web</td>
<td>Open the current branch's PR in the browser</td>
</tr>
<tr>
<td class="command">gh pr merge --squash</td>
<td>Squash-merge an approved PR from the terminal</td>
</tr>
<tr>
<td class="command">git remote add upstream <URL></td>
<td>Link the original repo you forked from, so you can pull in its updates</td>
</tr>
<tr>
<td class="command">git fetch upstream && git merge upstream/main</td>
<td>Sync your fork with the original project</td>
</tr>
<tr>
<td class="command">git diff</td>
<td>See exactly what changed before you add or commit it</td>
</tr>
</table>
</section>
<hr>
<div class="note-card">
<p><b>Working solo but want a stronger GitHub presence?</b> Head to
<a href="profile.html">Part 4 — Profile & Portfolio</a> to set up a profile README and
pin your best work.
</p>
</div>
<hr>
<footer class="page-footer">
<p>Prepared by <b>Muhammad Hamza Naqi</b></p>
<a class="linkedin-btn" href="https://www.linkedin.com/in/muhammad-hamza-naqi-569741403/"
target="_blank" rel="noopener noreferrer">Connect on LinkedIn</a>
</footer>
</div>
</main>
</div>
<button id="backTop" class="back-top" aria-label="Back to top">↑</button>
<script src="script.js"></script>
</body>
</html>