From 6e6eb56ccaf7fb4d32f6ffa5e1961683ca05cb5e Mon Sep 17 00:00:00 2001 From: jsms90 Date: Mon, 20 Feb 2017 03:14:18 +0000 Subject: [PATCH 01/14] remove content covered in prereqs, precourse & research topics --- README.md | 163 +++++++++--------------------------------------------- 1 file changed, 27 insertions(+), 136 deletions(-) diff --git a/README.md b/README.md index c939d6f..3b665bb 100644 --- a/README.md +++ b/README.md @@ -1,108 +1,51 @@ -# Introduction to Git and Version Control +# Learn git -This tutorial is targeted towards the students of courses at [Founders & Coders](http://foundersandcoders.org/). Feedback or Suggestions in the format of an issue or contributions as a pull request are appreciated. - -As a student, if you get stuck at any point, please open an issue and I will try to get back to you as soon as possible. If you would prefer, feel free to contact me on Gitter. When the issue is solved, do think about making a pull request to the project. - -The introduction to Git is aimed at the first week of the full time Founders & Coders course, or to those just starting out with git. The hope is that this introduction will cover all you need to know to start collaborating on code with your fellow teammates. - -Git for Collaboration is aimed at the second week students of the course, or those that have mastered the first section. Even though most of the advice in this tutorial will take a while to digest - and practise is essential. A good goal is to understand all these concepts, and implement at least most of these tips in your collaborative projects before finishing your time as a student at Founders & Coders. +This workshop is designed for collaborative learning, so grab a partner and use one computer. It has been made for students of [Founders and Coders](www.founderandcoders.com), and therefore assumes that you have: ++ created a one-page website before (as part of the [prerequisites](www.founderandcoders.com/apply)) ++ completed lesson 1 of [Udacity's Git and GitHub course](https://www.udacity.com/course/how-to-use-git-and-github--ud775) (as part of the [precourse material](https://github.com/foundersandcoders/master-reference/tree/master/coursebook/precourse)) ++ created issues on each other's website (as part of [this accessibilty workshop](https://github.com/jsms90/web-accessibility/blob/master/putting-yourself-in-someone-elses-shoes.md#exercises) on [day 1](https://github.com/foundersandcoders/master-reference/tree/master/coursebook/week-1) of the course) +**All contributions to this workshop are very welcome!** If you have any suggestions for improvements, please raise an issue. Pull requests are also very much appreciated, but please follow the [contributing guidelines](./CONTRIBUTING.md). # Contents -#### [Introduction](#introduction) -1. [Need to Know Terminology](#terminology) -2. [Why Version Control](#version-control) -3. [Tutorial](#tutorial) - * [Getting Started](#getting-started) - * [Branching](#branching) - * [Making Changes](#changes) - * [Merging with Master](#merging) - * [Merge Conflicts](#conflicts) - * [Changing File Structure](#changing-file-structure) -4. [Introducing Github Flow](#github-flow) - -#### [Git for Collaboration](#git-collaboration) -1. [Further terminology](#further-terminology) -2. [The Timeline](#timeline) -3. [Committing](#commits) - * [When should you commit](#when-commit) - * [Commit messages](#commit-message) - * [Merging commits](#merging-commits) +1. [Introducing Github Flow](#github-flow) +2. [Tutorial](#tutorial) +* [Getting Started](#getting-started) +* [Branching](#branching) +* [Making Changes](#changes) +* [Merging with Master](#merging) +* [Merge Conflicts](#conflicts) +* [Changing File Structure](#changing-file-structure) + +3. [Git for Collaboration](#git-collaboration) +* [Further terminology](#further-terminology) +* [The Timeline](#timeline) #### [Resources](#resources) + +## GitHub Flow +Start by brushing up on the basic [GitHub workflow](https://guides.github.com/introduction/flow/) - - -# Introduction - -The introduction to Git is aimed at the first week of the full time Founders & Coders course, or to those just starting out with git. The hope is that this introduction will cover all you need to know to start collaborating on code with your fellow teammates. - - - -## Terminology - -##### *Repository (repo)* -Simply put, this is your project folder. This repository can be located locally (in your file system on your computer), or remotely (on Github). Either way, it is the same repository. - -##### *Version Control* -We will use Git for this. A way of keeping track of changes in the code which makes it possible to work with multiple developers on the same repo. - -##### *Git* -A version control system. - -##### *Github* -A remote location where you can store you code, and which all the members of the team have access to. Think of it like a dropbox for code. One of the big differences however is most repositories on github are public. Anybody can see your code. - -##### *Commit* -A way of saving your code at different points along the project. Unlike many tools you may have used however, all commits are saved. This creates a project history and a way to track changes. - -##### *Branches* -As you work on a git repo the first branch you are on is usually the default branch. This is often called `master`. If you start working on a section of the website (say the footer styling), it is best practise to create your own branch for that feature. Creating your own branch is like taking a copy of `master` and renaming it. When you commit, they will now be on that new branch only. +**Branches** +As you work on a git repo the first branch you are on is usually the default branch. This is called `master`. If you start working on a section of the website (say the footer styling), it is best practise to create your own branch for that feature. Creating your own branch is like taking a copy of `master` and renaming it. When you commit, they will now be on that new branch only. In the sections below we will walk through how to do this. For the meantime, just note that you always have one default branch, and can have as many other branches as needed. - -## Why Version Control - -##### Code Base History -Git can provide you with a complete history of every commit made on a project. Benefits include: - -* Being able to see what differences to the file system you have made before you have commited. - -* Being able to see what differences exist between commits - -* Being able to move between different commits (or places in time). This is especially useful if something became broken while you were working on it, and you need to start again. - -In the introduction section of this tutorial, we won't be able to cover all these benefits in practise extensively. However, we will aim to give you all the information you will need to know by the end. - -##### Multiple people working on the same files +**Multiple people working on the same files** Version control makes this possible. If you work on one file, and then I work on the same file at the same time when we want to combine our changes git allows us to keep both versions save that we can compare. This allows us to integrate our changes more swiftly. We will practice with this later. -##### Branching -A good work flow with git always involves branching. Having branches helps organise the code, and keep track of who is working on what. - ## Tutorial -Before we begin, if you don't have a Github account, please get one. - Next please fork this repository. ![fork button on github](./img/fork.png) -On your local machine, please make sure you have git installed. - -If you are using a mac, the easiest thing is to install git with [Homebrew](http://brew.sh/). Want to learn more about Homebrew? Check out this [tutorial](http://computers.tutsplus.com/tutorials/homebrew-demystified-os-xs-ultimate-package-manager--mac-44884). - -Windows use http://git-scm.com/download/win. and Linux install using these instructions http://git-scm.com/download/linux. - - ### Getting Started The next step is to clone the forked version of this repository. On the main page of the repo, copy the url shown here: @@ -121,7 +64,7 @@ Next, it is good to get in the habit after each command to use `git status`. Let ``` git status -```` +``` Now check which branch you are on: @@ -310,22 +253,11 @@ The command also takes optional parameters. To find out more, refer to [document - -## Github Flow -Github flow is what most teams at Founders & Coders follow. It is simple and effective. - -For a visual guide, and some helpful tips: -https://guides.github.com/introduction/flow/ - -To find out why Github uses Github flow: -http://scottchacon.com/2011/08/31/github-flow.html - - # Git for Collaboration -Git for Collaboration is aimed at the second week students of the course, or those that have mastered the first section. Even though most of the advice in this tutorial will take a while to digest - and practise is essential. A good goal is to understand all these concepts, and implement at least most of these tips in your collaborative projects before finishing your time as a student at Founders & Coders. +Even though most of the advice in this tutorial will take a while to digest - and practise is essential. A good goal is to understand all these concepts, and implement at least most of these tips in your collaborative projects before finishing your time as a student at Founders & Coders. @@ -372,7 +304,7 @@ You should see something like this: Pick the second time commit that you made and copy the hash. Use `q` to exit the log and checkout to your commit. -Step 4) +Step 4) ``` git checkout git status @@ -394,47 +326,6 @@ Checkout back to `timeline-practise` and push up to Github to make a pull reques it is up to date with master locally. - -## Committing - - - -### When should you commit? - -You should aim each commit to be a "safe" version of the project. This means that if you checkout to any commit in your timeline, that should reflect where the project was at that point, and be functional. - -Given that, when you commit is very important. I have heard two very useful guidelines. - -The first, is that as you complete the task assigned to you, you make several commits at different times during that task. In the end you merge all those commits together to make one very informative commit of that task. I will talk about ways to merge commits together in a later section. - -The second method is you work through your task and complete it before adding or committing at all. Then you check the status of the repo and see all the files you have changed. The next step is selectively adding and committing - -Through my research I have come across many different methodologies, and ultimately you should try to do what seems the most natural to you. I use both of these methodologies depending on the extent of the task before me. The best thing is to always keep in mind that you and your colleagues will inevitably need to go back to your commits and it will help everyone if commits are aptly named. - -Likewise, even in pull requests, you must aim to make your commits a clear and concise summary of what tasks where completed on that branch. That way the person reviewing your pull request understands what they will be reviewing before looking at the code itself. - - - -### Commit messages - -Just like choosing when to commit, and what to commit, it is also important to think about your naming. It is always good to be as descriptive as possible with your commit messages. - -Also consider: -* Present tense for your commit messages -* If related to an issue on github, should contain issue number -* The first line should be 50 characters or less. Your message should be brief and to the point. -* Focus on why you did something, not how you did it -* Avoid `ands`. If you find yourself wanting to write `and`, you should probably break up that commit into multiple ones. - -Remember that the purpose of this commit is to be a message for future you, or your colleagues who may not have known what you are working on. Try to think about your message with this in mind. - -Many development teams take it one step further and turn their commit messages into change logs. These change logs may be used for user consumption making it all the more important to have clear messages of what was done for that commit. - -I tend to favour one line commits for simplicity, but many schools of thought out there prefer multiline commit messages. For examples of "best practice" formats for this see: -* [Commit message guidelines Angular](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format) -* [Informative guidelines, and a cute cat filled slideshow](http://www.slideshare.net/TarinGamberini/commit-messages-goodpractices) - - ### Merging Commits From 2474b2d5047687a5bf2493e50fba00e58529c23d Mon Sep 17 00:00:00 2001 From: jsms90 Date: Mon, 20 Feb 2017 03:20:00 +0000 Subject: [PATCH 02/14] fix bullet points in contents --- README.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 3b665bb..ea7459f 100644 --- a/README.md +++ b/README.md @@ -10,30 +10,30 @@ This workshop is designed for collaborative learning, so grab a partner and use # Contents 1. [Introducing Github Flow](#github-flow) 2. [Tutorial](#tutorial) -* [Getting Started](#getting-started) -* [Branching](#branching) -* [Making Changes](#changes) -* [Merging with Master](#merging) -* [Merge Conflicts](#conflicts) -* [Changing File Structure](#changing-file-structure) + + [Getting Started](#getting-started) + + [Branching](#branching) + + [Making Changes](#changes) + + [Merging with Master](#merging) + + [Merge Conflicts](#conflicts) + + [Changing File Structure](#changing-file-structure) 3. [Git for Collaboration](#git-collaboration) -* [Further terminology](#further-terminology) -* [The Timeline](#timeline) + + [Further terminology](#further-terminology) + + [The Timeline](#timeline) -#### [Resources](#resources) +4. [Resources](#resources) ## GitHub Flow Start by brushing up on the basic [GitHub workflow](https://guides.github.com/introduction/flow/) -**Branches** +**Branches** As you work on a git repo the first branch you are on is usually the default branch. This is called `master`. If you start working on a section of the website (say the footer styling), it is best practise to create your own branch for that feature. Creating your own branch is like taking a copy of `master` and renaming it. When you commit, they will now be on that new branch only. In the sections below we will walk through how to do this. For the meantime, just note that you always have one default branch, and can have as many other branches as needed. -**Multiple people working on the same files** +**Multiple people working on the same files** Version control makes this possible. If you work on one file, and then I work on the same file at the same time when we want to combine our changes git allows us to keep both versions save that we can compare. This allows us to integrate our changes more swiftly. We will practice with this later. From e6a6ef576c49108d54ca23485a5350a1945e7a7b Mon Sep 17 00:00:00 2001 From: jsms90 Date: Mon, 20 Feb 2017 03:35:10 +0000 Subject: [PATCH 03/14] correct formatting issues & change wording to be appropriate for current cohort --- README.md | 25 +++++++++---------------- 1 file changed, 9 insertions(+), 16 deletions(-) diff --git a/README.md b/README.md index ea7459f..761ddfe 100644 --- a/README.md +++ b/README.md @@ -18,7 +18,7 @@ This workshop is designed for collaborative learning, so grab a partner and use + [Changing File Structure](#changing-file-structure) 3. [Git for Collaboration](#git-collaboration) - + [Further terminology](#further-terminology) + + [Terminology](#terminology) + [The Timeline](#timeline) 4. [Resources](#resources) @@ -30,15 +30,10 @@ Start by brushing up on the basic [GitHub workflow](https://guides.github.com/in **Branches** As you work on a git repo the first branch you are on is usually the default branch. This is called `master`. If you start working on a section of the website (say the footer styling), it is best practise to create your own branch for that feature. Creating your own branch is like taking a copy of `master` and renaming it. When you commit, they will now be on that new branch only. -In the sections below we will walk through how to do this. For the meantime, just note that you always have one default branch, and can have as many other branches as needed. - **Multiple people working on the same files** Version control makes this possible. If you work on one file, and then I work on the same file at the same time when we want to combine our changes git allows us to keep both versions save that we can compare. This allows us to integrate our changes more swiftly. -We will practice with this later. - - ## Tutorial @@ -257,11 +252,8 @@ The command also takes optional parameters. To find out more, refer to [document # Git for Collaboration -Even though most of the advice in this tutorial will take a while to digest - and practise is essential. A good goal is to understand all these concepts, and implement at least most of these tips in your collaborative projects before finishing your time as a student at Founders & Coders. - - - -## Further Terminology + +## Terminology ##### Commit Hash: ![commit hash picture](./img/commit-hash.png) @@ -273,9 +265,9 @@ Simply put, the HEAD is a reference to a commit object. For more information see ## The Timeline -As discussed previously git stores all the commits on the project. You can use them as a timeline and travel back and forth in time. This section shows you a simple way of doing that which will come in handy as you work in projects with your team. +As you know from the Udacity course, git stores all the commits on the project. You can use them as a timeline and travel back and forth in time. This section reminds you how to do that, which will come in handy as you work in projects with your team. -Before we start make sure you have a terminal open located at the local copy of this repo. The same one that was used for the first tutorial is essential. Make a new branch called `timeline-practice` and navigate onto it. +Make a new branch called `timeline-practice` and navigate onto it. Step 1) Make a new directory in the project via the command line. Lets call it `time`. @@ -292,6 +284,7 @@ open time/newfile.txt Write the current time stamp, and a short message to your future self. Save it. Next add and commit your changes. Your commit message should be descriptive of what you just did. Repeat step 2 twice more, deleting the previous time and message, and adding the new time and a different message. Make sure you add and commit each time. Make sure your commit messages are unique, and you can tell which one was first, second, and third. + Step 3) Next type in this command: ``` @@ -304,6 +297,7 @@ You should see something like this: Pick the second time commit that you made and copy the hash. Use `q` to exit the log and checkout to your commit. + Step 4) ``` git checkout @@ -313,7 +307,7 @@ git status ![git detached head warning](./img/detached-head.png) -As you can see after you checkout a message appears informing your that you are in a 'detached HEAD' state, meaning your are not working on any current branch. Open up the file in the time folder and look at the time and message. It should be the 2nd one that you wrote. +As you can see after you checkout a message appears informing you that you are in a 'detached HEAD' state, meaning your are not working on any current branch. Open up the file in the time folder and look at the time and message. It should be the 2nd one that you wrote. Repeat step 4, and use the hash of the first time commit you made. Open the file and see that the time of your first commit, and your message to yourself. This is going back in time. You can easily go back as far as you like in the project and see older iterations of this tutorial! @@ -322,8 +316,7 @@ Next, we should go back to the future. The quickest and easiest way is to checko ![git reflog example](./img/git-reflog.png) Find the commit name of the last commit you did (the third time that you recorded) and copy the short hash in yellow. Checkout back to that commit, and `git diff timeline-practise` there should be no difference. -Checkout back to `timeline-practise` and push up to Github to make a pull request to master. Make sure you first check that -it is up to date with master locally. +Checkout back to `timeline-practise` and push up to Github to make a pull request to master. Make sure you first check that it is up to date with master locally. From c9a5b05189c46bb81c4da5646a6705d8d5b2ec18 Mon Sep 17 00:00:00 2001 From: jsms90 Date: Mon, 20 Feb 2017 03:49:59 +0000 Subject: [PATCH 04/14] update intro --- README.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 761ddfe..2bd1c9f 100644 --- a/README.md +++ b/README.md @@ -1,11 +1,8 @@ # Learn git -This workshop is designed for collaborative learning, so grab a partner and use one computer. It has been made for students of [Founders and Coders](www.founderandcoders.com), and therefore assumes that you have: -+ created a one-page website before (as part of the [prerequisites](www.founderandcoders.com/apply)) -+ completed lesson 1 of [Udacity's Git and GitHub course](https://www.udacity.com/course/how-to-use-git-and-github--ud775) (as part of the [precourse material](https://github.com/foundersandcoders/master-reference/tree/master/coursebook/precourse)) -+ created issues on each other's website (as part of [this accessibilty workshop](https://github.com/jsms90/web-accessibility/blob/master/putting-yourself-in-someone-elses-shoes.md#exercises) on [day 1](https://github.com/foundersandcoders/master-reference/tree/master/coursebook/week-1) of the course) +This workshop has been made for students of [Founders and Coders](www.founderandcoders.com), and therefore assumes that you have completed lesson 1 of [Udacity's Git and GitHub course](https://www.udacity.com/course/how-to-use-git-and-github--ud775) (as part of the [precourse material](https://github.com/foundersandcoders/master-reference/tree/master/coursebook/precourse)) -**All contributions to this workshop are very welcome!** If you have any suggestions for improvements, please raise an issue. Pull requests are also very much appreciated, but please follow the [contributing guidelines](./CONTRIBUTING.md). +**All contributions to this workshop are very welcome!** If you have any suggestions for improvements, please raise an [issue](https://github.com/NataliaLKB/learn-git-basics/issues). [Pull requests](https://github.com/jsms90/learn-git-basics/pulls) are also very much appreciated, but please follow the [contributing guidelines](https://github.com/foundersandcoders/master-reference/blob/master/CONTRIBUTING.md). # Contents 1. [Introducing Github Flow](#github-flow) From d757be5e67d3ff8b28655b70ffcefd4bf6bc0ac5 Mon Sep 17 00:00:00 2001 From: PiotrBerebecki Date: Mon, 20 Feb 2017 16:38:37 +0000 Subject: [PATCH 05/14] Fix typo --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 2bd1c9f..5da8be6 100644 --- a/README.md +++ b/README.md @@ -50,7 +50,7 @@ Then use the command in your terminal: git clone https://github.com/NataliaLKB/learn-git-basics.git ``` -You should now be ablle to redirect into the directory just created using the command line. +You should now be able to redirect into the directory just created using the command line. Next, it is good to get in the habit after each command to use `git status`. Let us use it now. From 72679e9934ec391544d045f6e5542cc6f53cb69f Mon Sep 17 00:00:00 2001 From: PiotrBerebecki Date: Mon, 20 Feb 2017 17:04:11 +0000 Subject: [PATCH 06/14] Fix a command --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 5da8be6..4e3c052 100644 --- a/README.md +++ b/README.md @@ -233,7 +233,7 @@ index.html In order to achieve this, `git mv` command comes in handy. Using it to move files *ensures preserving history* of the files you work on. To change file structure like above (and create new folders at the same time) use command: ``` mkdir css && git mv stylesheet.css ./css -mkdir css && git mv script.js ./js +mkdir js && git mv script.js ./js ``` (This glues `mkdir` and `git mv` commands together with `&&` operator). From 242f4710539bd1e3c9120e39549909992b7654c0 Mon Sep 17 00:00:00 2001 From: PiotrBerebecki Date: Mon, 20 Feb 2017 17:33:41 +0000 Subject: [PATCH 07/14] Fix typ: changes -> change --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 4e3c052..3a1ca2d 100644 --- a/README.md +++ b/README.md @@ -334,7 +334,7 @@ git status git log ``` -Your working directory shouldn't changes, but all the files that you changed should be in green. Your log should have the newest commit as the hash you copied. Even though all your work is still the same as before the reset, the commits are different. Then you can commit again and this is an easy way to replace 2 or more commits with one commit. +Your working directory shouldn't change, but all the files that you changed should be in green. Your log should have the newest commit as the hash you copied. Even though all your work is still the same as before the reset, the commits are different. Then you can commit again and this is an easy way to replace 2 or more commits with one commit. For more information and techiques see: From d4e72319237bf63b1cdf2ad3f5dc98a319822e39 Mon Sep 17 00:00:00 2001 From: smarthutza Date: Tue, 21 Feb 2017 12:31:50 +0000 Subject: [PATCH 08/14] adding new command in the cheatsheet --- cheatsheet.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/cheatsheet.md b/cheatsheet.md index eba705e..e6d5dad 100644 --- a/cheatsheet.md +++ b/cheatsheet.md @@ -20,4 +20,6 @@ ##### Moving files while preserving git history git mv - \ No newline at end of file + +##### Creates a branch, and moves you onto it at the same time + git checkout -b From d8c629c2f37133a70368a704e4a08c18e824b5e5 Mon Sep 17 00:00:00 2001 From: jsms90 Date: Sat, 27 May 2017 09:25:13 +0100 Subject: [PATCH 09/14] reintroduce Committing section relates #1 --- README.md | 46 ++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 44 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 3a1ca2d..f265ebd 100644 --- a/README.md +++ b/README.md @@ -313,7 +313,49 @@ Next, we should go back to the future. The quickest and easiest way is to checko ![git reflog example](./img/git-reflog.png) Find the commit name of the last commit you did (the third time that you recorded) and copy the short hash in yellow. Checkout back to that commit, and `git diff timeline-practise` there should be no difference. -Checkout back to `timeline-practise` and push up to Github to make a pull request to master. Make sure you first check that it is up to date with master locally. +Checkout back to `timeline-practise` and push up to Github to make a pull request to master. Make sure you first check that +it is up to date with master locally. + + + +## Committing + + + +### When should you commit? + +You should aim each commit to be a "safe" version of the project. This means that if you checkout to any commit in your timeline, that should reflect where the project was at that point, and be functional. + +Given that, when you commit is very important. I have heard two very useful guidelines. + +The first, is that as you complete the task assigned to you, you make several commits at different times during that task. In the end you merge all those commits together to make one very informative commit of that task. I will talk about ways to merge commits together in a later section. + +The second method is you work through your task and complete it before adding or committing at all. Then you check the status of the repo and see all the files you have changed. The next step is selectively adding and committing + +Through my research I have come across many different methodologies, and ultimately you should try to do what seems the most natural to you. I use both of these methodologies depending on the extent of the task before me. The best thing is to always keep in mind that you and your colleagues will inevitably need to go back to your commits and it will help everyone if commits are aptly named. + +Likewise, even in pull requests, you must aim to make your commits a clear and concise summary of what tasks where completed on that branch. That way the person reviewing your pull request understands what they will be reviewing before looking at the code itself. + + + +### Commit messages + +Just like choosing when to commit, and what to commit, it is also important to think about your naming. It is always good to be as descriptive as possible with your commit messages. + +Also consider: +* Present tense for your commit messages +* If related to an issue on github, should contain issue number +* The first line should be 50 characters or less. Your message should be brief and to the point. +* Focus on why you did something, not how you did it +* Avoid `ands`. If you find yourself wanting to write `and`, you should probably break up that commit into multiple ones. + +Remember that the purpose of this commit is to be a message for future you, or your colleagues who may not have known what you are working on. Try to think about your message with this in mind. + +Many development teams take it one step further and turn their commit messages into change logs. These change logs may be used for user consumption making it all the more important to have clear messages of what was done for that commit. + +I tend to favour one line commits for simplicity, but many schools of thought out there prefer multiline commit messages. For examples of "best practice" formats for this see: +* [Commit message guidelines Angular](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format) +* [Informative guidelines, and a cute cat filled slideshow](http://www.slideshare.net/TarinGamberini/commit-messages-goodpractices) @@ -334,7 +376,7 @@ git status git log ``` -Your working directory shouldn't change, but all the files that you changed should be in green. Your log should have the newest commit as the hash you copied. Even though all your work is still the same as before the reset, the commits are different. Then you can commit again and this is an easy way to replace 2 or more commits with one commit. +Your working directory shouldn't changes, but all the files that you changed should be in green. Your log should have the newest commit as the hash you copied. Even though all your work is still the same as before the reset, the commits are different. Then you can commit again and this is an easy way to replace 2 or more commits with one commit. For more information and techiques see: From a8733d37b245eef996f8949337e45a0373ad28de Mon Sep 17 00:00:00 2001 From: jsms90 Date: Sat, 27 May 2017 09:41:32 +0100 Subject: [PATCH 10/14] add 'Committing' section to contents relates #1 --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index f265ebd..05c87d2 100644 --- a/README.md +++ b/README.md @@ -17,6 +17,7 @@ This workshop has been made for students of [Founders and Coders](www.founderand 3. [Git for Collaboration](#git-collaboration) + [Terminology](#terminology) + [The Timeline](#timeline) + + [Committing](#committing) 4. [Resources](#resources) From 1d57a76a33a635a75f543acd752fc05a323f721a Mon Sep 17 00:00:00 2001 From: jsms90 Date: Sat, 27 May 2017 09:48:28 +0100 Subject: [PATCH 11/14] reword requests for students to make PRs & remove mention of jsms90 --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 05c87d2..777d197 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ This workshop has been made for students of [Founders and Coders](www.founderandcoders.com), and therefore assumes that you have completed lesson 1 of [Udacity's Git and GitHub course](https://www.udacity.com/course/how-to-use-git-and-github--ud775) (as part of the [precourse material](https://github.com/foundersandcoders/master-reference/tree/master/coursebook/precourse)) -**All contributions to this workshop are very welcome!** If you have any suggestions for improvements, please raise an [issue](https://github.com/NataliaLKB/learn-git-basics/issues). [Pull requests](https://github.com/jsms90/learn-git-basics/pulls) are also very much appreciated, but please follow the [contributing guidelines](https://github.com/foundersandcoders/master-reference/blob/master/CONTRIBUTING.md). +**All contributions to this workshop are very welcome!** If you have any suggestions for improvements, please raise an [issue](https://github.com/NataliaLKB/learn-git-basics/issues). The author will let you know whether they prefer to make the changes themselves, or whether you are welcome to submit your own PR (Pull Request). If you do make PR yourself, please follow the Founders and Coders [contributing guidelines](https://github.com/foundersandcoders/master-reference/blob/master/CONTRIBUTING.md). # Contents 1. [Introducing Github Flow](#github-flow) From 1f6e09b5a930f1a065813a9584eed9449c55cff4 Mon Sep 17 00:00:00 2001 From: jsms90 Date: Sat, 27 May 2017 10:30:43 +0100 Subject: [PATCH 12/14] improve explanation in github flow section relates https://github.com/NataliaLKB/learn-git-basics/issues/74 --- README.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 777d197..123fc1d 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ This workshop has been made for students of [Founders and Coders](www.founderand # Contents 1. [Introducing Github Flow](#github-flow) -2. [Tutorial](#tutorial) +2. [Git Basics](#git-basics) + [Getting Started](#getting-started) + [Branching](#branching) + [Making Changes](#changes) @@ -23,17 +23,16 @@ This workshop has been made for students of [Founders and Coders](www.founderand ## GitHub Flow -Start by brushing up on the basic [GitHub workflow](https://guides.github.com/introduction/flow/) +Version control makes it possible for you and I to work on one file at the same time, because we can keep both our versions saved and then compare them later, once we have each finished our work. This allows us to integrate our changes more swiftly. Most developers use git as their version control system, but different teams use different "workflows". At Founders and Coders, we generally follow something called "GitHub flow", because this flow makes it easy to deploy the latest version of your application very regularly. -**Branches** -As you work on a git repo the first branch you are on is usually the default branch. This is called `master`. If you start working on a section of the website (say the footer styling), it is best practise to create your own branch for that feature. Creating your own branch is like taking a copy of `master` and renaming it. When you commit, they will now be on that new branch only. +You will be using GitHub flow throughout your time on the course. Follow GitHub's [visual guide](https://guides.github.com/introduction/flow/) now to see the steps involved in working on a "feature branch". +Creating your own "branch" is like taking a copy of `master` and renaming it. When you commit, the changes that you make will only exist on that branch. As you work on a GitHub repo, the first branch you are on is the default branch, called `master`. If you wanted to start working on a new section of the website (say the footer styling), it is best practise to create a new branch for working on that feature. -**Multiple people working on the same files** -Version control makes this possible. If you work on one file, and then I work on the same file at the same time when we want to combine our changes git allows us to keep both versions save that we can compare. This allows us to integrate our changes more swiftly. +If you are curious about why this flow was chosen, you can find some links in the resources below. - -## Tutorial + +## Git Basics Next please fork this repository. @@ -393,6 +392,7 @@ For more information and techiques see: > Have you ***found a useful Git or GitHub resource or tutorial? Please let us know*** by creating an issue +* Why you GitHub flow? Read this article from a developer at GitHub: http://scottchacon.com/2011/08/31/github-flow.html * For generating ssh keys https://help.github.com/articles/generating-ssh-keys/ * CodeSchool "Git Real" tutorial: http://gitreal.codeschool.com/ * Atlassian (makers of *SourceTree*) Git Tutorials: https://www.atlassian.com/git/tutorials/ From 66fe50fbad11fd2f15c421dc62cb1eba16329913 Mon Sep 17 00:00:00 2001 From: jsms90 Date: Sat, 27 May 2017 10:43:30 +0100 Subject: [PATCH 13/14] break up the github flow paragraph & make the instruction to follow the link much clearer relates https://github.com/NataliaLKB/learn-git-basics/issues/74 --- README.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 123fc1d..22efdc7 100644 --- a/README.md +++ b/README.md @@ -23,13 +23,15 @@ This workshop has been made for students of [Founders and Coders](www.founderand ## GitHub Flow -Version control makes it possible for you and I to work on one file at the same time, because we can keep both our versions saved and then compare them later, once we have each finished our work. This allows us to integrate our changes more swiftly. Most developers use git as their version control system, but different teams use different "workflows". At Founders and Coders, we generally follow something called "GitHub flow", because this flow makes it easy to deploy the latest version of your application very regularly. +Version control makes it possible for you and I to work on one file at the same time, because we can keep both our versions saved and then compare them once we have each finished our work. This allows us to integrate our changes more swiftly. -You will be using GitHub flow throughout your time on the course. Follow GitHub's [visual guide](https://guides.github.com/introduction/flow/) now to see the steps involved in working on a "feature branch". +Most developers use git as their version control system, but different teams use different "workflows". At Founders and Coders, we generally follow something called "GitHub flow", because this flow makes it easy to deploy the latest version of your application very regularly. For a fuller explanation, there is a useful article in the resources section below. +To see the steps involved in working on a "feature branch", follow GitHub's [visual guide](https://guides.github.com/introduction/flow/) now. + +**What is a branch?** Creating your own "branch" is like taking a copy of `master` and renaming it. When you commit, the changes that you make will only exist on that branch. As you work on a GitHub repo, the first branch you are on is the default branch, called `master`. If you wanted to start working on a new section of the website (say the footer styling), it is best practise to create a new branch for working on that feature. -If you are curious about why this flow was chosen, you can find some links in the resources below. ## Git Basics From 991f95ebf6e715bc787b50ab68b4c6eff7791c2e Mon Sep 17 00:00:00 2001 From: jsms90 Date: Mon, 29 May 2017 18:23:33 +0100 Subject: [PATCH 14/14] add links to the github flow section relates #74 --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 22efdc7..5db1cff 100644 --- a/README.md +++ b/README.md @@ -25,7 +25,7 @@ This workshop has been made for students of [Founders and Coders](www.founderand ## GitHub Flow Version control makes it possible for you and I to work on one file at the same time, because we can keep both our versions saved and then compare them once we have each finished our work. This allows us to integrate our changes more swiftly. -Most developers use git as their version control system, but different teams use different "workflows". At Founders and Coders, we generally follow something called "GitHub flow", because this flow makes it easy to deploy the latest version of your application very regularly. For a fuller explanation, there is a useful article in the resources section below. +[Most developers use git as their version control system](https://rhodecode.com/insights/version-control-systems-2016), but different teams use different "workflows". At Founders and Coders, we generally follow something called "GitHub flow", because this flow makes it easy to deploy the latest version of your application very regularly. For a fuller explanation, there is a useful article in the [resources section](#resources). To see the steps involved in working on a "feature branch", follow GitHub's [visual guide](https://guides.github.com/introduction/flow/) now.