forked from RamblingCookieMonster/Git-Presentation
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathDemoNotes.txt
208 lines (178 loc) · 11.9 KB
/
DemoNotes.txt
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
****************
EXPLORING GITHUB
****************
Front page
- What’s going on with your stuff
- What’s going on with people you follow and repos you watch
*Repository:
- All the version control fun for a particular project
- You decide what goes in. A bunch of random powershell scripts? A module? A single script?
- The Readme provides a handy 'front page' for your project.
I like to include an overview, instructions, and examples at the very least.
Issue - Not Git. Part of GitHub
- Bug tracking, feature requests, etc.
- Great way to get started working on a project, even if you aren’t comfortable working with the code itself yet.
- Specific to GitHub and similar solutions, not Git.
- Remember the golden rule. Would you want someone submitting a vague issue saying "it's broken?" Provide details about what you're running, specific error messages, your environment, and other notes you would expect in a bug report.
*Commit
- A point in time snapshot of a project. Central to Git.
*Fork - not part of Git
- ‘Copy someone else’s repository to my GitHub account!’
- Basically… clone, but to your GitHub account. Server side clone. Terminology specific to GitHub and other solutions (e.g. BitBucket, Stash)
- Why? Collaboration and sharing. I can fork anyone’s repo and make my own modifications. I can collaborate with the author and send my changes, or just keep them in my own account (See RabbitMqTools example)
- We're going to fork Demo-To-Fork for later. All we do is click the fork button!
- https://github.com/DemoGitHubUser/Demo-To-Fork - You can do the same thing with the DSC Resources!
New Repository!
- Name - Demo
- Optional Description
- Add a license
- Don't ignore this! Some folks won’t use your code or contribute to it if no license or a certain license.
For example, Microsoft employees might not contribute to a project under GPL.
*Clone
- ‘Copy a repository to this path!’
- Usually refers to a remote repo (e.g. on GitHub)
- Clone in Desktop button, if it's easier
- Note the clone URL. You'll need this if you clone with git.exe
*********************
GitHub Windows client
*********************
Assuming you've installed GitHub for Windows
- Username and password for your GitHub account
- Username and mail for commits
Public. To keep it private: [email protected]
This configures your gitconfig. For more info, check the links in the notes:
http://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration
e.g. http://nickberardi.com/gitconfig/
Clone
- Let's clone our new repository
- + (Plus) > Clone > Pick a repo to clone
- Pick the Demo repo we created
- This is the same whether you are cloning your own repository, or a repository you forked.
You usually clone down the repository once. Let's walk through an example day-to-day workflow in the GitHub client.
- Add a file (Join-Object)
- Notice the check box next to join-object.
- Long story short, need to know that there's the working directory (file system you see), a staging area (the check box), and the repository itself (everything in change control). Git only tracks changes you tell it to track via that the staging area. Checkbox is the GitHub clients' way of showing that stage.
-We'll go into more detail when we look at the command line.
- Commit - You've decided you want to take a snapshot in time of your project. Something you can revert to or review in the future.
- A clear, concise message is helpful. Add further details in the description
Adding Join-Object
- This only affects your local repository! https://github.com/RamblingCookieMonster/Demo
- Make some minor changes in Join-Object
- Notice the diff from GitHub. Very handy to see what changed!
- Commit the change - Minor help updates
- Notice the Sync button?
- This basically says 'sync up this repository between my local and GitHub copies!'
- First, it runs git pull --rebase to pull changes from GitHub to your local repo
- Second, if there are local changes, it runs git push to send them to the GitHub repo
- Now we can check GitHub and see that it is up to date!
- If you work on multiple computers, you can hit the sync button if you get out of date from the GitHub repo, continue working
- Hint: Try to keep your local copy up to date. Changing the same file from two places can lead to merge conflicts. Typically trivial to fix for small PowerShell projects, outside the scope of this session.
- Simple workflow!
- Make changes
- Commit
- Optionally sync to GitHub when appropriate
- Want to work locally, not worry about GitHub? git init creates a new repository.
************************
Using Git from the shell
************************
- GitHub for Windows Client includes msysgit, posh-git
- Some folks have worked on getting this into the ISE, I stick to powershell.exe still (http://virtualengine.co.uk/2015/git-and-the-powershell-ise/)
- Windows 10 makes this a bit more pleasant to use. Try ConEmu for a handy shell alternative
- We're going to be using Git.exe. That means all the handy conventions and shared knowledge of PowerShell get thrown out the door. git --help
- Some folks from the virtual powershell user group, including Joel Bennet and Justin Rich, are working on PowerShell-izing git commands, and have a repository out on GitHub - https://github.com/PoshCode/PSGit
- Let's run the same workflow as above. Watch the prompt as we go. + is new ~ is change - is removed. Red means unstaged/untracked, green means staged
- Create a new file:
New-Item .\Test.ps1
# Notice the red prompt. This is saying we have +1 new files
# For more info on the prompt, hit up https://github.com/dahlbyk/posh-git#the-prompt
- Stage that file:
Git add -A
# http://stackoverflow.com/questions/572549/difference-between-git-add-a-and-git-add Case sensitive...
# This says stage any changes I've made.
- Commit that file:
git commit -m "added test.ps1"
- Any updates from GitHub? Optionally run
git pull --rebase
- Push updates up to GitHub:
git push
Branches!
- Think of each commit as a snapshot of your project. Similar to a VM snapshot.
- A branch is just a named pointer to one of these commits, like a post-it note.
- By default, when you create a new repository, git creates a 'master' branch, that nearly everyone uses.
- Basically like having an entire separate copy of your project, which you can work on without breaking other copies. Try a new feature that will break existing stuff. Create a new version of your project that breaks down level compatibility. Etc.
- Branches might seem complicated if you haven't worked with them before. Try the demo we're walking through at home, the interactive branching tutorial in the references for this presentation, or consider spending a few minutes with on chapter in the Pro Git book: http://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-Is
- Obnoxious terminology time! Git also needs to know what you want to work on. This is called 'HEAD'. It's literally just a file that points to one of these branches! If you don't use any of this, you have a master branch and HEAD always points at it.
get-content .\.git\HEAD
- Let's give this a shot. It's much easier than it sounds.
- Clone Demo-To-Fork. Open explorer.
- We can flip back and forth. Important to note that this changes your working directory (file system)
- Look at existing branches (use -a to include remotes):
git branch
- Move HEAD to Dev branch. Working on MSFT DSC Resources? They want you to use Dev.
git checkout Dev # Case sensitive...
- Let's add a new file, add some content to a file, commit
New-Item "SomeDevCode.ps1"
"## Some major change!!" | Add-Content .\Get-Something.ps1
git add -A
git commit -m "added dev file, updated readme"
- Okay! now we have two branches, master and Dev. Let's move back and forth to illustrate
- Open explorer...
git checkout master
dir
git checkout Dev # Case sensitive....
dir
- You won't need to do this for DSC resources, but no git presentation is complete without mentioning merge
git checkout master
git merge Dev # merges into the branch we're in.
- Finally, let's send our changes back to GitHub. by default, it only pushes the current branch, so we do --all
git push --all
- GitHub Windows client has a drop down for branches as well.
- We won't do it here, but it's simple to create a new branch
This creates a branch from wherever our HEAD is pointing:
git branch CrazyTest
git checkout CrazyTest
new-item Crazy.ps1
git add -A
git commit -m "added crazy"
git push --all -u # Push all branches, and set up upstream tracking for this new branch...
At this point, we're good to go! We've made some changes the the DSC resource, and we want to submit them up to Microsoft. Let's log onto GitHub and quickly run through that workflow.
*************
COLLABORATION
*************
Browse to our fork
Click green 'Compare & pull request' button!
Pick the branch we care about
Base = the original repo
Head fork = our changes
Make sure we're picking Dev!
Type in a friendly pull request message. Remember the golden rule - treat others as you would like to be treated - would you want someone asking to reformat the syntax in your project? Would you want a request changing 500 lines of code with no details on what changed?
Create pull request. You can now chat with the author and others.
While this is open, we can keep making changes and pushing them as DemoGitHubUser. They get added to the pull request automatically.
Just to re-iterate the workflow:
- Fork someone elses repository
- Clone your fork to your desktop
- Make some changes
- Commit your changes
- Push to github
- Submit a pull request!
Log in as the author!
Notifications
I can view changes, commits, and I can comment, maybe ask for minor changes. If I don't like it, I can close it out.
When I'm ready, I hit merge. Most use cases in the PowerShell world won't get much more complicated than this. If they do, google is your friend!
That's about it. I'd highly recommend getting involved with the PowerShell community on GitHub. Contribute to an existing project, or create your own project. Once you start using this you might start wishing you had something similar at work...
If you end up contributing to the DSC Resources, check out Microsofts contribution guidelines
Guide to getting started with GitHub (From MSFT): https://github.com/PowerShell/DscResources/blob/master/GettingStartedWithGitHub.md
DSC Contributions guide: https://github.com/PowerShell/DscResources/blob/master/CONTRIBUTING.md
DSC Resource Style Guidelines: https://github.com/PowerShell/DscResources/blob/master/StyleGuidelines.md
- Oh shoot! the repo you forked was updated on the author's end. How do we update?
A bit of a pain: http://stackoverflow.com/questions/7244321/how-to-update-github-forked-repository
Copy Clone URL : https://github.com/psCookieMonster/Demo-To-Fork.git
git remote add upstream https://github.com/psCookieMonster/Demo-To-Fork.git
git fetch upstream
git checkout master
git merge upstream/master
- All my commits look so messy! Can I consolidate them down?
Danger zone. This is absolutely possible, and might be easy, but use caution.
Long story: Consider the logic here: http://justinhileman.info/article/git-pretty/git-pretty.png
Short story: If you haven't pushed to GitHub, consider git rebase -i
Example reference: https://help.github.com/articles/about-git-rebase/