diff --git a/assets/img/index-1.png b/assets/img/index-1.png deleted file mode 100644 index cf4aec5..0000000 Binary files a/assets/img/index-1.png and /dev/null differ diff --git a/index.html b/index.html index 6c39917..f17ef68 100644 --- a/index.html +++ b/index.html @@ -25,72 +25,54 @@

Notes on Git and GitHub

- On this page you can find some personal notes on the use of Git - and GitHub. Though the notes themselves were created by me, the - content in them is the result of courses that I've taken on the - subject, books I've read, and countless YouTube videos, blog posts - and StackOverflow questions. These notes should not be considered - as a replacement for engaging with those resources. + On this page you can find some personal notes on the use of Git and GitHub. Though the notes themselves + were created by me, the content in them is the result of courses that I've taken on the subject, books + I've read, and countless YouTube videos, blog posts and StackOverflow questions. These notes should not + be considered as a replacement for engaging with those resources.


- Some resources that I especially recommend and whose influence can - be found all across these notes are: + Some resources that I especially recommend and whose influence can be found all across these notes are:

@@ -448,24 +430,8 @@

Jump to...

-
-
-

- Read up! Enjoy! And when things don't work...worry not, for you - are not alone... -

-
-
-
-
- -
-
- + diff --git a/pages/001/what_is_git.html b/pages/001/what_is_git.html index 6fcdb45..0410997 100644 --- a/pages/001/what_is_git.html +++ b/pages/001/what_is_git.html @@ -1,16 +1,14 @@ + - + What is Git? +
@@ -30,22 +28,17 @@

What is Git?

- Git is a version control system. A version control system records - the changes made to the project's code over time in a special - database called a repository. We can then look at the - database and see who's made changes and when. This way, if we made - a mistake we can easily go back to a previous state. + Git is a version control system. A version control system records the changes made to the project's code + over time in a special database called a repository. We can then look at the database and see + who's made changes and when. This way, if we made a mistake we can easily go back to a previous state.


- Version control systems can be classified into two categories: - Centralized and Distributed. In a centralized - system, all team members connect to a central server to get and - share code. The problem with these systems is that if the server - goes down, we can't save snapshots. In distributed systems, every - member of the team has a copy of the entire project on their - machine, and then share their code to a central copy of the - project. Git is a distributed control system. + Version control systems can be classified into two categories: Centralized and + Distributed. In a centralized system, all team members connect to a central server to get and + share code. The problem with these systems is that if the server goes down, we can't save snapshots. In + distributed systems, every member of the team has a copy of the entire project on their machine, and then + share their code to a central copy of the project. Git is a distributed control system.

@@ -54,9 +47,7 @@

What is Git?

- + + diff --git a/pages/002/configuring_git.html b/pages/002/configuring_git.html index 6fb6b0e..95eeee9 100644 --- a/pages/002/configuring_git.html +++ b/pages/002/configuring_git.html @@ -1,16 +1,14 @@ + - + Configuring Git +
@@ -42,26 +40,16 @@

Configuring Git

Settings can be specified at three different levels

    -
  • - System: settings at the system level apply to - all users of the computer. -
    • -
  • - Global: the settings here apply to all - repositories of the current user. -
    • -
  • - Local: the settings here apply to the current - repository. -
    • +
  • System: settings at the system level apply to all users of the computer.
    • +
  • Global: the settings here apply to all repositories of the current user.
    • +
  • Local: the settings here apply to the current repository.

- To configure the settings, open the Git Bash (Bash = "Bourne Again - Shell") or Terminal. You can specify the name with: + To configure the settings, open the terminal. You can specify the name with:

git config --global user.name "User Name" @@ -75,16 +63,15 @@

Configuring Git

git config --global core.editor "code --wait"

- All these configuration settings are stored in a text file that we - can access and edit with our default editor. You can open it with: + All these configuration settings are stored in a text file that we can access and edit with our default + editor. You can open it with:

git config --global -e

- This will open the .gitconfig file where you can edit - configurations. When you go back to Git Bash you'll see a message - that says + This will open the .gitconfig file where you can edit configurations. When you go back to the + terminal you'll see a message that says

hint: Waiting for your editor to close the file... @@ -95,13 +82,11 @@

Configuring Git

- Now we need to configure how Git will handle the end-of-line. On - Windows, the end-of-line are marked with two special characters: - \r for Carriage Return, - and \n for Line Feed. On - macOS and Linux, the end-of-line is indicated with - \n. We have to configure a - property called core.autocrlf. On Windows use: + Now we need to configure how Git will handle the end-of-line. On Windows, the end-of-line are marked with + two special characters: \r for Carriage Return, and + \n for Line Feed. On macOS and Linux, the end-of-line is + indicated with \n. We have to configure a property called + core.autocrlf. On Windows use:

git config --global core.autocrlf true @@ -117,9 +102,7 @@

Configuring Git

- + + diff --git a/pages/003/getting_help.html b/pages/003/getting_help.html index 292fa9b..74363f5 100644 --- a/pages/003/getting_help.html +++ b/pages/003/getting_help.html @@ -1,16 +1,14 @@ + - - Getting Help + + Getting help +
@@ -20,7 +18,7 @@
-

Getting Help

+

Getting help

- + + diff --git a/pages/004/initializing_a_repository.html b/pages/004/initializing_a_repository.html index 6ba93f7..7449c0d 100644 --- a/pages/004/initializing_a_repository.html +++ b/pages/004/initializing_a_repository.html @@ -1,16 +1,14 @@ + - + Initializing a repository +
@@ -32,68 +30,57 @@

Initializing a repository

- In order to start working with Git, the first thing we need to do - is creating a directory for our project (a folder in your - computer). You can put this directory anywhere on your computer. - To do so, open Git Bash and run: + In order to start working with Git, the first thing we need to do is creating a directory for + our project (a folder in your computer). You can put this directory anywhere on your computer. To do so, + open the terminal and run:

mkdir directory_name
- Now to move into the directory use + To move into the directory use
cd directory_name
- You can combine these two actions in one with - &&. So - mkdir and - cd become + You can combine these two actions in one with &&. So + mkdir and cd become
- mkdir directory_name && cd - directory_name + mkdir directory_name && cddirectory_name

- Now that we have a directory, we need to initialize a new empty - repository. To do this, we run + Now that we have a directory, we need to initialize a new empty repository. To do this, we run

git init

- You should see a message that says that an empty repository was - initialized and the path to the directory. Inside your directory, - you now have a sub-directory called - .git. This subdirectory is hidden - because you are not supposed to touch it. If you list all the - files in your directory with + You should see a message that says that an empty repository was initialized and the path to the + directory. Inside your directory, you now have a sub-directory called + .git. This subdirectory is hidden because you are not supposed to touch + it. If you list all the files in your directory with

ls

- you won't see the - .git sub-directory. To list it, - use + you won't see the .git sub-directory. To list it, use

ls -a

- you can now see it (the -a flag - stands for all). You can open this sub-directory with + you can now see it (the -a flag stands for all). You can open + this sub-directory with

start .git

- If you corrupt or remove this directory, you will lose your - project's history. If you need to remove it, just run + If you corrupt or remove this directory, you will lose your project's history. If you need to remove it, + just run

rm -rf .git @@ -105,9 +92,7 @@

Initializing a repository

- + + diff --git a/pages/005/git_workflow.html b/pages/005/git_workflow.html index 6c0e133..d1d056a 100644 --- a/pages/005/git_workflow.html +++ b/pages/005/git_workflow.html @@ -1,16 +1,14 @@ + - + Git Workflow +
@@ -32,21 +30,16 @@

Git workflow

- When working with Git the normal workflow starts with making - changes to files, or adding new files, or deleting old files that - are no longer needed. Once we are done making changes, we - add these files to the - Staging Area. If we are satisfied with the changes, we - will commit those changes to the - Repository. + When working with Git the normal workflow starts with making changes to files, or adding new files, or + deleting old files that are no longer needed. Once we are done making changes, we add these files to the Staging Area. If we are satisfied with + the changes, we will commit those changes to the Repository.


- Creating a commit is like taking - a snapshot of our project. These snapshots are permanently stored - in our repository. If there are changes that we don't want to add - to the snapshot, we can un-stage them and add them to a later - snapshot. + Creating a commit is like taking a snapshot of our project. These + snapshots are permanently stored in our repository. If there are changes that we don't want to add to the + snapshot, we can un-stage them and add them to a later snapshot.


To add a file to the staging area we use

@@ -54,52 +47,40 @@

Git workflow

git add file_name.ext

- Once we've reviewed the files and are sure that we want to take a - snapshot, we use + Once we've reviewed the files and are sure that we want to take a snapshot, we use

git commit -m "commit message"

- Every commit should contain a - meaningful message that explains what changes were made in that - snapshot. + Every commit should contain a meaningful message that explains what + changes were made in that snapshot.

- Git workflow 1 + Git workflow 1

- Once we commit some changes the - Staging Area does not get emptied. Think of it as the - staging server of an application. Once we release a new version, - the live and staging versions are the same, but that does not mean - that there is no staging version. + Once we commit some changes the Staging Area does not get + emptied. Think of it as the staging server of an application. Once we release a new version, the live and + staging versions are the same, but that does not mean that there is no staging version.


- If we make some new changes to a file, we need to - stage the files again. The same - is true when deleting files. If we delete a file from our working - directory, we need to stage the - deletion. To do it we use + If we make some new changes to a file, we need to stage the files again. + The same is true when deleting files. If we delete a file from our working directory, we need to + stage the deletion. To do it we use

git add name_of_the_deleted_file

- Then we can permanently record this deletion by committing it with - the following command: + Then we can permanently record this deletion by committing it with the following command:

git commit -m "commit message" @@ -115,13 +96,11 @@

Git workflow

  • Date and time of the commit
  • Author
  • - A complete snapshot of the project at the time the - commit was created + A complete snapshot of the project at the time the commit was created

    • - Git can store the complete project snapshot because it compresses - the files and doesn’t store duplicates. + Git can store the complete project snapshot because it compresses the files and doesn't store duplicates.

    @@ -130,9 +109,7 @@

    Git workflow

    - + + diff --git a/pages/006/staging_files.html b/pages/006/staging_files.html index c7aabed..3676719 100644 --- a/pages/006/staging_files.html +++ b/pages/006/staging_files.html @@ -1,16 +1,14 @@ + - + Staging files +
    @@ -34,18 +32,15 @@

    Staging files

    - Before we can stage a file, we - need to create one. To do so, we run + Before we can stage a file, we need to create one. To do so, we run

    echo hello > file1.txt

    - This will create a new file called file1.txt and write - the word hello into this file. - echo is not a Git command, it's - just a good ol' system command. Now let's create a second file, - using the same command + This will create a new file called file1.txt and write the word hello into this file. + echo is not a Git command, it's just a good ol' system command. Now + let's create a second file, using the same command

    echo hello > file2.txt @@ -55,81 +50,57 @@

    Staging files

    - Git will not start tracking your files on its own. To check the - status of the project's files run + Git will not start tracking your files on its own. To check the status of the project's files run

    git status

    - Here we can see that our two files are un-tracked. We also see - that they are not in the Staging Area because they are - red. In order to add them to the - Staging Area, we use the - git add command and the name of - the file(s). Here we can pass one file or more, separated by a - space. We can also use patterns (all files matching this pattern - will be added), or a period (all files in the directory will be - added). + Here we can see that our two files are un-tracked. We also see that they are not in the + Staging Area because they are red. In order to add them to the + Staging Area, we use the git add command and the name of the + file(s). Here we can pass one file or more, separated by a space. We can also use patterns (all files + matching this pattern will be added), or a period (all files in the directory will be added).

    git add *.txt
    - Staging files 1 + Staging files 1
    - Staging files 2 + Staging files 2

    - Now if we run git status again, - you'll see that the files changed to - green because they are in the - Staging Area. + Now if we run git status again, you'll see that the files changed to + green because they are in the Staging Area.

    - Now let's modify file1.txt by appending the word - world to it. To do this, we run the same command as for - creating it but with a double greater-than symbol: + Now let's modify file1.txt by appending the word world to it. To do this, we run the + same command as for creating it but with a double greater-than symbol:

    echo world >> file1.txt

    - And let's run git status again. - See that now file1.txt is both in the - Staging Area and in the Working Directory. This - is because when we staged the - files, Git took a snapshot of file1.txt and placed it in - the Staging Area. So the version of - file1.txt that exists in the - Staging Area differs from the one that exists in the - Working Directory. We can sync them up by running - git add file1.txt again. + And let's run git status again. See that now file1.txt is both + in the Staging Area and in the Working Directory. This is because when we + staged the files, Git took a snapshot of file1.txt and placed + it in the Staging Area. So the version of file1.txt that exists in the + Staging Area differs from the one that exists in the Working Directory. We can sync + them up by running git add file1.txt again.

    - Staging files 3 + Staging files 3
    @@ -137,9 +108,7 @@

    Staging files

    - + + diff --git a/pages/007/committing_changes.html b/pages/007/committing_changes.html index 9af6bc6..8cb6f88 100644 --- a/pages/007/committing_changes.html +++ b/pages/007/committing_changes.html @@ -1,16 +1,14 @@ + - + Committing changes +
    @@ -32,19 +30,16 @@

    Committing changes

    - Now we have a snapshot in the Staging Area that is ready - to be permanently saved in the Repository. To do this we - run + Now we have a snapshot in the Staging Area that is ready to be permanently saved in the + Repository. To do this we run

    git commit -m "Commit Message"

    - Here the -m flag means that we - are providing a message. The message itself is what we type in - quotes. This will only let us write a short one-line message. If - we need longer messages we omit the flag, and Git will open our - text editor, where we can enter a more detailed message. + Here the -m flag means that we are providing a message. The message + itself is what we type in quotes. This will only let us write a short one-line message. If we need longer + messages we omit the flag, and Git will open our text editor, where we can enter a more detailed message.

    git commit @@ -53,50 +48,35 @@

    Committing changes

    - Committing changes 1 + Committing changes 1

    - Now on VS Code, we can write our - commit message. On the first - line, we should write the title of our commit or a short - description of it. This description should not exceed 80 + Now on VS Code, we can write our commit message. On the first line, we + should write the title of our commit or a short description of it. This description should not exceed 80 characters.


    - Then we write a long description that explains what was changed, - deleted, or added in this commit. - When done, we save the changes and close VS Code. Keep in mind - that when we close VS Code the - commit command is executed, so - make sure to double-check your message and make sure you included - everything that needs to be included. + Then we write a long description that explains what was changed, deleted, or added in this + commit. When done, we save the changes and close VS Code. Keep in mind + that when we close VS Code the commit command is executed, so make sure + to double-check your message and make sure you included everything that needs to be included.

    - Back in Git Bash, we'll see a message with basic statistics of - what was changed. Here it says that two files were changed: - file1.txt and file2.txt. It also says that there - were three insertions (one for each time we added - hello to each file and one for when we added + Back in Git Bash, we'll see a message with basic statistics of what was changed. Here it says that two + files were changed: file1.txt and file2.txt. It also says that there were three + insertions (one for each time we added hello to each file and one for when we added world to file1.txt).

    - Committing changes 2 + Committing changes 2
    @@ -104,9 +84,7 @@

    Committing changes

    - + + diff --git a/pages/008/removing_files.html b/pages/008/removing_files.html index d64aae9..ede8f4f 100644 --- a/pages/008/removing_files.html +++ b/pages/008/removing_files.html @@ -1,16 +1,14 @@ + - + Removing files +
    @@ -34,51 +32,41 @@

    Removing files

    - To remove a file (say file2.txt) from our repository we - could use rm file2.txt. The - problem with this command is that is not a - git command. So the file will be - removed from the Working Directory, but not from the - Staging Area. It's OK to do it this way, just remember - that since the file is still in the Staging Area, you'll - need to git add it and then - git commit it. Since this is such - a common operation, there's a Git version of the remove command - that does everything in one step. + To remove a file (say file2.txt) from our repository we could use + rm file2.txt. The problem with this command is that is not a + git command. So the file will be removed from the + Working Directory, but not from the Staging Area. It's OK to do it this way, just + remember that since the file is still in the Staging Area, you'll need to + git add it and then git commit it. + Since this is such a common operation, there's a Git version of the remove command that does everything + in one step.

    - You can check which files are in the Staging Area by - running + You can check which files are in the Staging Area by running

    git ls-files

    - You should see both files in there: file1.txt and - file2.txt. Now to delete file2.txt we use + You should see both files in there: file1.txt and file2.txt. Now to delete + file2.txt we use

    git rm file2.txt

    - If you run git ls-files again, - you should see that file2.txt is no longer in the - Staging Area. And if you run - ls you'll see that neither is - file2.txt in the Working Directory. We have - successfully delete file2.txt in one command. + If you run git ls-files again, you should see that file2.txt is + no longer in the Staging Area. And if you run ls you'll see + that neither is file2.txt in the Working Directory. We have successfully delete + file2.txt in one command.

    - Removing files 1 + Removing files 1
    @@ -86,9 +74,7 @@

    Removing files

    - + + diff --git a/pages/009/renaming_or_moving_files.html b/pages/009/renaming_or_moving_files.html index 4cd5a36..8293ea8 100644 --- a/pages/009/renaming_or_moving_files.html +++ b/pages/009/renaming_or_moving_files.html @@ -1,16 +1,14 @@ + - + Renaming or moving files +
    @@ -32,41 +30,34 @@

    Renaming or moving files

    - Just as with removing; renaming or moving files can be two-step - operations if we don't use Git commands. Keep in mind here that - for your OS, the complete name of a file includes the path to it, - so moving is like renaming. + Just as with removing; renaming or moving files can be two-step operations if we don't use Git commands. + Keep in mind here that for your OS, the complete name of a file includes the path to it, so moving is + like renaming.

    - Suppose we want to change the name of file1.txt to - main.txt. To do this in one command we use + Suppose we want to change the name of file1.txt to main.txt. To do this in one command + we use

    git mv file1.txt main.txt

    - Now that our file has been renamed, we can check that it's already - in the Staging Area by running + Now that our file has been renamed, we can check that it's already in the Staging Area by running

    git status

    - See that Git already realized that what we are doing is renaming a - file. Now we can commit our - changes. + See that Git already realized that what we are doing is renaming a file. Now we can + commit our changes.

    - Renaming or moving files 1 + Renaming or moving files 1
    @@ -74,9 +65,7 @@

    Renaming or moving files

    - + + diff --git a/pages/010/ignoring_files.html b/pages/010/ignoring_files.html index 87bbffb..3998559 100644 --- a/pages/010/ignoring_files.html +++ b/pages/010/ignoring_files.html @@ -1,16 +1,14 @@ + - + Ignoring files +
    @@ -32,25 +30,23 @@

    Ignoring files

    - Sometimes we don't want Git to track certain files. To handle this - we use a special file "called" .gitignore. This file has - no name, only an extension. We should place it at the root of our + Sometimes we don't want Git to track certain files. To handle this we use a special file called + .gitignore. This file has no name, only an extension. We should place it at the root of our project. To create it we run

    touch .gitignore

    - If at the time of creating it we already have a file or - sub-directory that we want to add to it, we can use + If at the time of creating it we already have a file or sub-directory that we want to add to it, we can + use

    echo file_name.ext > .gitignore

    - If we already have a .gitignore file and we want to add a - new file to it (i.e. we want to append the - .gitignore file), we run + If we already have a .gitignore file and we want to add a new file to it (i.e. we want to append + the .gitignore file), we run

    echo new_file_name.ext >> .gitignore @@ -60,8 +56,7 @@

    Ignoring files

    echo sub-dir_name/ >> .gitignore

    - Once we've created our .gitignore file, we can inspect it - with VS Code by running + Once we've created our .gitignore file, we can inspect it with VS Code by running

    code .gitignore @@ -72,77 +67,61 @@

    Ignoring files

    - As an example, let's create a logs sub-directory and add - it to our .gitignore file. First, we create the sub-dir - and a file inside that sub-dir with + As an example, let's create a logs sub-directory and add it to our .gitignore file. + First, we create the sub-dir and a file inside that sub-dir with

    mkdir logs && echo hello > logs/dev.log

    - Next, we add it to (and create) the .gitignore file by - running + Next, we add it to (and create) the .gitignore file by running

    echo logs/ > .gitignore

    - Now, if we run a git status, - we'll see that the .gitignore file is only in the - Working Directory, so we'll + Now, if we run a git status, we'll see that the .gitignore file + is only in the Working Directory, so we'll

    git add .gitignore

    and

    git commit -m "Add .gitignore file"

    - to commit it to our Repository. But notice that we didn't stage - nor committed our logs sub-dir. + to commit it to our Repository. But notice that we didn't stage nor committed our logs sub-dir.

    - Ignoring files 1 + Ignoring files 1

    - Inside our .gitignore we can have as many items as we - want. We can add new files as file_name.ext, we can add - entire sub-directories as sub-dir_name/, or we can use - patterns. So, for example, adding config.py will cause - Git to ignore the file named config.py. Adding - *.js will cause Git to ignore all files with a - .js extension in our project. Adding - logs/*.log will cause Git to ignore all files with - extension .log in the logs/ sub-dir, but not - other files in that sub-dir, nor files with the - .log extension in other directories inside our project. + Inside our .gitignore we can have as many items as we want. We can add new files as + file_name.ext, we can add entire sub-directories as sub-dir_name/, or we can use + patterns. So, for example, adding config.py will cause Git to ignore the file named + config.py. Adding *.js will cause Git to ignore all files with a .js extension + in our project. Adding logs/*.log will cause Git to ignore all files with extension .log + in the logs/ sub-dir, but not other files in that sub-dir, nor files with the .log + extension in other directories inside our project.

    - Keep in mind that all of this only works if you haven't added a - file to the repository already. If you have, Git will keep on - tracking it. If you added a file to the repository and you now - want Git to stop tracking it, you need to remove it from the - staging area. To do this we'll use + Keep in mind that all of this only works if you haven't added a file to the repository already. If you + have, Git will keep on tracking it. If you added a file to the repository and you now want Git to stop + tracking it, you need to remove it from the staging area. To do this we'll use

    git rm --cached -r file_name

    - Now you can commit this deletion and Git will stop tracking the - file. Do not forget the - --cached option or Git will - remove the file both from the staging area and the working - directory!! + Now you can commit this deletion and Git will stop tracking the file. Do not forget the + --cached option or Git will remove the file both from the staging area + and the working directory!

    @@ -151,9 +130,7 @@

    Ignoring files

    - + + diff --git a/pages/011/short_status.html b/pages/011/short_status.html index 5fe8cce..5901689 100644 --- a/pages/011/short_status.html +++ b/pages/011/short_status.html @@ -1,16 +1,14 @@ + - + Short status +
    @@ -32,55 +30,38 @@

    Short status

    - We can get a less verbose version of the status of our project by - running + We can get a less verbose version of the status of our project by running

    git status -s

    - To show how this works, suppose that we've created a new file - file2.txt and modified an existing file, - file1.txt. In the short version of the status each file - name is preceded by two columns: the left column represents the - staging area, and the right column represents the working - directory. + To show how this works, suppose that we've created a new file file2.txt and modified an existing + file, file1.txt. In the short version of the status each file name is preceded by two columns: + the left column represents the staging area, and the right column represents the working directory.


    - In this example, file1.txt is shown with a red - M. Git is telling us that this file - has been modified, but that this modification is not in the - staging area, only in the working directory. - file1.txt has nothing in the left column since there are - no changes in this file affecting its staging area status. + In this example, file1.txt is shown with a red M. Git is telling us + that this file has been modified, but that this modification is not in the staging area, only in the + working directory. file1.txt has nothing in the left column since there are no changes in this + file affecting its staging area status.

    - Short status 1 + Short status 1
    - Short status 2 + Short status 2

    - If we stage file1.txt and run - git status -s again, we see that - now file1.txt has a green - M on the left column. This means - that all the changes we had in the working area are now in the - staging area. The right column is now empty because we don't have - any other changes to add. + If we stage file1.txt and run git status -s again, we see that + now file1.txt has a green M on the left column. This means that + all the changes we had in the working area are now in the staging area. The right column is now empty + because we don't have any other changes to add.

    @@ -88,43 +69,30 @@

    Short status

    Now let's make some more changes to file1.txt and run - git status -s one more time. Git - is now showing a green M on the - left-hand column and a red M on the - right-hand column. This means that there are staged changes and - un-staged changes. To add the new changes to the staging area we - just run + git status -s one more time. Git is now showing a green + M on the left-hand column and a red M on the + right-hand column. This means that there are staged changes and un-staged changes. To add the new changes + to the staging area we just run

    git add file1.txt
    - Short status 3 + Short status 3
    - Short status 4 + Short status 4

    - Now let's take a look at file2.txt. This file has two red - ?? because it's a new file. To add it - to the staging area we just run - git add file2.txt. Now the Git - status has a green A on the - left-hand side column. This means that the file is new, and it's - in the staging area. We can go ahead and commit it if we are - satisfied with the changes by running + Now let's take a look at file2.txt. This file has two red ?? because + it's a new file. To add it to the staging area we just run + git add file2.txt. Now the Git status has a green + A on the left-hand side column. This means that the file is new, and it's + in the staging area. We can go ahead and commit it if we are satisfied with the changes by running

    git commit -m "Add file2.txt" @@ -134,24 +102,17 @@

    Short status

    - If we now delete both files, Git will show them with a green - D on the left-hand column. This - means that they are both going to be deleted. + If we now delete both files, Git will show them with a green D on the + left-hand column. This means that they are both going to be deleted.


    - If at any time you run - git status -s and there are no - changes to neither the working nor the staging area, Git will show - an empty line. + If at any time you run git status -s and there are no changes to neither + the working nor the staging area, Git will show an empty line.

    - Short status 5 + Short status 5
    @@ -159,9 +120,7 @@

    Short status

    - + + diff --git a/pages/012/viewing_changes.html b/pages/012/viewing_changes.html index ff5ebd5..71fdaba 100644 --- a/pages/012/viewing_changes.html +++ b/pages/012/viewing_changes.html @@ -1,16 +1,14 @@ + - + Viewing changes +
    @@ -32,51 +30,36 @@

    Viewing changes

    - The git status -s only tells us - which files have changed. To explore what we have in the staging - area we use + The git status -s only tells us which files have changed. To explore + what we have in the staging area we use

    git diff --staged

    - The first line of this output tells us that the - diff utility was called to - compare two versions of file1.txt. The copy prefixed with - a is the old copy (the one we had - in the last commit). The copy prefixed with - b is the one we have in the - staging area. Next, we have a legend with the IDs. After that, - there's a line with - --- a/file1.txt and another one - with +++ b/file1.txt. Changes to - the old copy are prefixed with minus signs and changes to the new - copy are prefixed with plus signs. After that, there's a header - with information about which parts of the files have changed. This - is because Git will not show the entire file (if it's too long), - just a chunk. Each chunk has a header that looks like that. The - first part of the header says - -1,3. This means Git is showing - lines 1 through 3 of the old copy. + The first line of this output tells us that the diff utility was called + to compare two versions of file1.txt. The copy prefixed with a + is the old copy (the one we had in the last commit). The copy prefixed with + b is the one we have in the staging area. Next, we have a legend with + the IDs. After that, there's a line with --- a/file1.txt and another one + with +++ b/file1.txt. Changes to the old copy are prefixed with minus + signs and changes to the new copy are prefixed with plus signs. After that, there's a header with + information about which parts of the files have changed. This is because Git will not show the entire + file (if it's too long), just a chunk. Each chunk has a header that looks like that. The first part of + the header says -1,3. This means Git is showing lines 1 through 3 of the + old copy.

    - Viewing changes 1 + Viewing changes 1

    - The second part of the header says - +1,5. This means Git is showing - us lines 1 through 5 of the new copy. Below that we can see the - difference between the two of them. The - +sky and - +ocean mean that those two lines + The second part of the header says +1,5. This means Git is showing us + lines 1 through 5 of the new copy. Below that we can see the difference between the two of them. The + +sky and +ocean mean that those two lines are new lines that are being added in the new version of the file.

    @@ -84,36 +67,28 @@

    Viewing changes

    - Now we'll compare two versions of file2.txt. In this - case, Git is showing - --- /dev/null along with a header - of -0,0 because the file is new. - So, from the "previous" (none-existing) version is pulling lines 0 - through 0. + Now we'll compare two versions of file2.txt. In this case, Git is showing + --- /dev/null along with a header of + -0,0 because the file is new. So, from the "previous" (none-existing) + version is pulling lines 0 through 0.

    - Viewing changes 2 + Viewing changes 2

    - If instead, we wish to compare files in the working area to files - in the staging area, we use the same command but without the - --staged option. So, + If instead, we wish to compare files in the working area to files in the staging area, we use the same + command but without the --staged option. So,

    git diff

    - Here Git is telling us that in file1.txt the first two - lines (hello and - world) were removed and replaced with + Here Git is telling us that in file1.txt the first two lines + (hello and world) were removed and replaced with a new line (hello world).

    @@ -121,38 +96,28 @@

    Viewing changes

    - As you may have probably guessed already, this is not how we - inspect changes. To inspect changes we use a diff tool. - Here we'll use VS Code. So first we need to set VS Code as our - default diff tool. To do that, we run + As you may have probably guessed already, this is not how we inspect changes. To inspect changes we use a + diff tool. Here we'll use VS Code. So first we need to set VS Code as our default diff tool. To + do that, we run

    git config --global diff.tool vscode

    - With this command, we are just giving a name to our default - diff tool. Now we need to tell Git how to launch our diff - tool. To do this we run + With this command, we are just giving a name to our default diff tool. Now we need to tell Git + how to launch our diff tool. To do this we run

    - - git config --global difftool.vscode.cmd "code --wait --diff - $LOCAL $REMOTE" - + git config --global difftool.vscode.cmd "code --wait --diff $LOCAL $REMOTE"

    - For this to work remember that you must have added VS Code to your - system path. If you forgot about that, the easiest way is to just - reinstall VS Code and check the add to PATH checkbox on the - installation wizard. code just - tells the command prompt that it needs to open VS Code. The - --wait option tells the command - prompt that it needs to wait until we are done with VS Code. The - --diff option tells VS Code that - we want to use it for diffing files. Lastly, - $LOCAL and - $REMOTE are placeholders for the - older and newer versions of the file. + For this to work remember that you must have added VS Code to your system path. If you forgot about that, + the easiest way is to just reinstall VS Code and check the add to PATH checkbox on the installation + wizard. code just tells the command prompt that it needs to open VS + Code. The --wait option tells the command prompt that it needs to wait + until we are done with VS Code. The --diff option tells VS Code that + we want to use it for diffing files. Lastly, $LOCAL and + $REMOTE are placeholders for the older and newer versions of the file.

    @@ -163,32 +128,23 @@

    Viewing changes

    git config --global -e

    - This will open the Git settings in VS Code. You should see the - commands we just run at the bottom of the file. Make sure that - they are just as we typed them. So tool = vscode and - cmd = "code --wait --diff $LOCAL $REMOTE". If there are - any mistakes, you can correct them there. Just remember to save - your changes before closing. + This will open the Git settings in VS Code. You should see the commands we just run at the bottom of the + file. Make sure that they are just as we typed them. So tool = vscode and + cmd = "code --wait --diff $LOCAL $REMOTE". If there are any mistakes, you can correct them there. + Just remember to save your changes before closing.

    - Viewing changes 3 + Viewing changes 3

    - Now, all we need to do is to change the - diff part of our command with - difftool and select - Y when prompted by Git Bash. This - will open VS Code with both versions of our file placed side by - side. The old copy that we have in the staging area is shown on - the left-hand side panel, and the new copy that we have in the + Now, all we need to do is to change the diff part of our command with + difftool and select Y when prompted by + Git Bash. This will open VS Code with both versions of our file placed side by side. The old copy that we + have in the staging area is shown on the left-hand side panel, and the new copy that we have in the working directory is shown on the right-hand side panel.

    @@ -196,11 +152,7 @@

    Viewing changes

    - Viewing changes 4 + Viewing changes 4
    @@ -213,11 +165,9 @@

    Viewing changes

    git difftool --staged

    - In this case, the old copy (left) is what we had on the last - commit, and the new copy (right) is what we have on the staging - area. If more than one file is affected then, once we are done - with the first one and close VS Code, Git Bash will ask us if we - want to look at the other one. + In this case, the old copy (left) is what we had on the last commit, and the new copy (right) is what we + have on the staging area. If more than one file is affected then, once we are done with the first one and + close VS Code, Git Bash will ask us if we want to look at the other one.

    @@ -226,9 +176,7 @@

    Viewing changes

    - + + diff --git a/pages/013/viewing_history.html b/pages/013/viewing_history.html index ea6ff5e..875a6f1 100644 --- a/pages/013/viewing_history.html +++ b/pages/013/viewing_history.html @@ -1,16 +1,14 @@ + - + Viewing history +
    @@ -36,45 +34,32 @@

    Viewing history

    git log

    - This will print the last commits done on our repository starting - from the newest one. The first line is the commit ID, then it - shows us the author of that commit, the date and time at which the - commit was done, and the one-line description for the commit. + This will print the last commits done on our repository starting from the newest one. The first line is + the commit ID, then it shows us the author of that commit, the date and time at which the commit was done, + and the one-line description for the commit.


    - To see more commits press the space bar. This will print the next - page in the commit log. To quit, press + To see more commits press the space bar. This will print the next page in the commit log. To quit, press q.

    - Viewing history 1 + Viewing history 1
    - Viewing history 2 + Viewing history 2

    - We can add the --oneline option - to tell Git to print a summary of the history. Git will show the - last 7 characters of the commit ID, followed by the commit - message. + We can add the --oneline option to tell Git to print a summary of the + history. Git will show the last 7 characters of the commit ID, followed by the commit message.


    - If we want the commit history to be printed in reverse order - (oldest first), we just need to add the + If we want the commit history to be printed in reverse order (oldest first), we just need to add the --reverse option to our command.

    @@ -84,9 +69,7 @@

    Viewing history

    - + + diff --git a/pages/014/viewing_a_commit.html b/pages/014/viewing_a_commit.html index 59da034..ec568c9 100644 --- a/pages/014/viewing_a_commit.html +++ b/pages/014/viewing_a_commit.html @@ -1,16 +1,14 @@ + - + Viewing a commit +
    @@ -32,20 +30,16 @@

    Viewing a commit

    - Suppose now that we want to look at one specific commit in our - history. To do this we'll use the - git show command. We need to - specify the commit that we want to inspect. There are two ways in - which we can reference a commit: 1) by the commit ID, 2) as the - number of commits before the - HEAD pointer of our repository. + Suppose now that we want to look at one specific commit in our history. To do this we'll use the + git show command. We need to specify the commit that we want to inspect. + There are two ways in which we can reference a commit: 1) by the commit ID, 2) as the number of commits + before the HEAD pointer of our repository.


    - Here's an example (image). If we want to view the commit previous - to the - HEAD pointer of our repository we - can run either one of the following commands + Here's an example (image). If we want to view the commit previous to the + HEAD pointer of our repository we can run either one of the following + commands

    git show 292c34d @@ -54,30 +48,23 @@

    Viewing a commit

    git show HEAD~1

    - If we use the commit ID we don't have to pass all the first 7 - characters of the ID. We can pass fewer characters as long as it - doesn't generate ambiguity. If we instead go with the second - option, the number after the tilde is how many steps back from the - HEAD pointer we wish to go. Not - including the tilde and number means that we wish Git to show the + If we use the commit ID we don't have to pass all the first 7 characters of the ID. We can pass fewer + characters as long as it doesn't generate ambiguity. If we instead go with the second option, the number + after the tilde is how many steps back from the HEAD pointer we wish to + go. Not including the tilde and number means that we wish Git to show the HEAD.

    - Viewing a commit 1 + Viewing a commit 1

    - Regardless of which one we use, Git will print the commit - information along with the diff. If instead of seeing the diff we - want to inspect the state of a specific file at that point in the - repository's history we run + Regardless of which one we use, Git will print the commit information along with the diff. If instead of + seeing the diff we want to inspect the state of a specific file at that point in the repository's history + we run

    git show HEAD~1:file_name.ext @@ -90,31 +77,24 @@

    Viewing a commit

    - Viewing a commit 2 + Viewing a commit 2

    - If instead of browsing the commits we want to inspect the state of - our entire repository at the time of a specific commit we run + If instead of browsing the commits we want to inspect the state of our entire repository at the time of a + specific commit we run

    git ls-tree HEAD~1

    - This will print the list of the objects that were present in our - repository at the time of the commit that we specified. Elements - of type blob are files and - elements of type tree are - sub-directories within our project. + This will print the list of the objects that were present in our repository at the time of the commit + that we specified. Elements of type blob are files and elements of type + tree are sub-directories within our project.


    - Now we can ask Git to show us the content of a specific file by - running + Now we can ask Git to show us the content of a specific file by running

    git show file_id @@ -124,27 +104,22 @@

    Viewing a commit

    - For example, if we want to inspect the main.txt file - inside the src sub-directory, we run + For example, if we want to inspect the main.txt file inside the src sub-directory, we + run

    git ls-tree HEAD~1:src/

    - This tells Git that we want to inspect the - ls-tree of the - src subdirectory. Now we can pick our file by its ID + This tells Git that we want to inspect the ls-tree of the src + subdirectory. Now we can pick our file by its ID

    git show 31e0f
    - Viewing a commit 3 + Viewing a commit 3
    @@ -152,9 +127,7 @@

    Viewing a commit

    - + + diff --git a/pages/015/unstaging_files.html b/pages/015/unstaging_files.html index 676b636..9f87f8d 100644 --- a/pages/015/unstaging_files.html +++ b/pages/015/unstaging_files.html @@ -1,16 +1,14 @@ + - + Un-staging files +
    @@ -34,53 +32,39 @@

    Un-staging files

    - Suppose that we've added some changes to the staging area, but we - now realize that we shouldn't have. We want to un-stage our - file(s) and get it back to the working area. To solve this we run + Suppose that we've added some changes to the staging area, but we now realize that we shouldn't have. We + want to un-stage our file(s) and get it back to the working area. To solve this we run

    git restore --staged file_name.ext
    - Un-staging files 1 + Un-staging files 1

    - We can pass one filename, multiple files separated by a space, - patterns such as *.txt, or a - period to indicate all files. This tells Git to take the changes - that are already in the staging area and revert them to the - working directory. What Git is doing here under the hood is taking - the last version of our file from the next environment. So, if we - restore a file that is in the - staging area, the last version from the next environment is the - state of the file in the last commit. Git will take this version - and place it in the staging area. + We can pass one filename, multiple files separated by a space, patterns such as + *.txt, or a period to indicate all files. This tells Git to take the + changes that are already in the staging area and revert them to the working directory. What Git is doing + here under the hood is taking the last version of our file from the next environment. So, if we + restore a file that is in the staging area, the last version from the + next environment is the state of the file in the last commit. Git will take this version and place it in + the staging area.

    - Un-staging files 2 + Un-staging files 2

    - Now suppose the file we want to restore is a new file, so it - didn't exist at the last commit. If we - restore this file, Git will take - the staging area version of it, and place it in the working - directory as a new un-tracked file. + Now suppose the file we want to restore is a new file, so it didn't exist at the last commit. If we + restore this file, Git will take the staging area version of it, and + place it in the working directory as a new un-tracked file.

    @@ -89,9 +73,7 @@

    Un-staging files

    - + + diff --git a/pages/016/discarding_local_changes.html b/pages/016/discarding_local_changes.html index 7d197c1..6850e29 100644 --- a/pages/016/discarding_local_changes.html +++ b/pages/016/discarding_local_changes.html @@ -1,16 +1,14 @@ + - + Discarding local changes +
    @@ -32,47 +30,38 @@

    Discarding local changes

    - To discard local changes (i.e. changes in our working directory) - from a file that is already been tracked, we run + To discard local changes (i.e. changes in our working directory) from a file that is already been + tracked, we run

    git restore file_name.ext

    - Same as before, Git will take the version of this file that is in - the next environment. Since we are on the working directory now, - the next environment is the staging area. + Same as before, Git will take the version of this file that is in the next environment. Since we are on + the working directory now, the next environment is the staging area.


    - Note that file3.txt was not restored to its previous - state. This is because this file is new, so there is no previous - state. Going back to the "previous version" of this file means - deleting it. To do this we run + Note that file3.txt was not restored to its previous state. This is because this file is new, so + there is no previous state. Going back to the "previous version" of this file means deleting it. To do + this we run

    git clean -fd
    - Discarding local changes 1 + Discarding local changes 1

    - The -fd switch is necessary - because by default Git will not allow us to delete un-tracked - files (since they can not be recovered). The - f switch is mandatory here and it - means force. So we are forcing - Git to go ahead with the removal. The - d switch is necessary for - deleting entire un-tracked sub-directories. + The -fd switch is necessary because by default Git will not allow us to + delete un-tracked files (since they can not be recovered). The f switch + is mandatory here and it means force. So we are forcing Git to go ahead + with the removal. The d switch is necessary for deleting entire + un-tracked sub-directories.

    @@ -81,9 +70,7 @@

    Discarding local changes

    - + + diff --git a/pages/017/restoring_a_file.html b/pages/017/restoring_a_file.html index 76ff2dc..a5895ed 100644 --- a/pages/017/restoring_a_file.html +++ b/pages/017/restoring_a_file.html @@ -1,16 +1,14 @@ + - + Restoring a file +
    @@ -34,61 +32,42 @@

    Restoring a file

    - If we deleted a file and we want to restore it to the previous - state we run + If we deleted a file and we want to restore it to the previous state we run

    - - git restore --source=HEAD~1 file_path/file_name.ext - + git restore --source=HEAD~1 file_path/file_name.ext

    - Here we are restoring a deleted file to the version that was - available in the commit previous to deleting it. But we can use - this strategy to for file from any point in the history of our - repository. + Here we are restoring a deleted file to the version that was available in the commit previous to deleting + it. But we can use this strategy to for file from any point in the history of our repository.

    - Restoring a file 1 + Restoring a file 1
    - Restoring a file 2 + Restoring a file 2

    - As an example, take a look at the image on the left. - file2.txt has only one line in it, - sky. Then we add - hello and commit the changes, and - finally we add world and commit - the changes. + As an example, take a look at the image on the left. file2.txt has only one line in it, + sky. Then we add hello and commit the + changes, and finally we add world and commit the changes.


    - file2.txt has not been deleted. It still exists in our - working directory. So, say we want to revert file2.txt to - a previous state when it only had the word + file2.txt has not been deleted. It still exists in our working directory. So, say we want to + revert file2.txt to a previous state when it only had the word sky in it. To do this we run

    git restore --source=HEAD~2 file2.txt

    - With this, Git will restore it to two steps behind the - HEAD pointer of our repository, - when the file only said sky. If - we want to keep the changes as they were at this point in time, we - can commit file2.txt to our repository. + With this, Git will restore it to two steps behind the HEAD pointer of + our repository, when the file only said sky. If we want to keep the + changes as they were at this point in time, we can commit file2.txt to our repository.

    @@ -97,9 +76,7 @@

    Restoring a file

    - + + diff --git a/pages/018/viewing_the_history.html b/pages/018/viewing_the_history.html index a408c6a..da954cf 100644 --- a/pages/018/viewing_the_history.html +++ b/pages/018/viewing_the_history.html @@ -1,16 +1,14 @@ + - + Viewing the history +
    @@ -34,40 +32,28 @@

    Viewing the history

    - We already covered the basic use of the - git log command and of the - --oneline option. We can use - other options with this command. For example, the - --stat will produce stats about - the files that were changed in each commit. + We already covered the basic use of the git log command and of the + --oneline option. We can use other options with this command. For + example, the --stat will produce stats about the files that were changed + in each commit.

    git log --oneline --stat

    - Take a look at the last commit. Here Git is telling us that on - this commit, 5 files were changed. There were a total of 7 - insertions and 4 deletions. Of those, 3 insertions and 1 deletion - were made to audience.txt, 1 insertion was done to the - file objectives.txt, and one deletion and one insertion - were done to each of the other files. + Take a look at the last commit. Here Git is telling us that on this commit, 5 files were changed. There + were a total of 7 insertions and 4 deletions. Of those, 3 insertions and 1 deletion were made to + audience.txt, 1 insertion was done to the file objectives.txt, and one deletion and one + insertion were done to each of the other files.

    - Viewing the history 1 + Viewing the history 1
    - Viewing the history 2 + Viewing the history 2

    To see the actual changes in each commit we use

    @@ -75,11 +61,9 @@

    Viewing the history

    git log --online --patch

    - Here we can see that, for example, in the - audience.txt file, four lines were inserted: 1) a line at - the top with the AUDIENCE title, - followed by 2) a blank line, and - finally 3) a line with the text + Here we can see that, for example, in the audience.txt file, four lines were inserted: 1) a line + at the top with the AUDIENCE title, followed by 2) a + blank line, and finally 3) a line with the text No prior experience is required..


    @@ -88,8 +72,7 @@

    Viewing the history

    - If you find this view confusing, you can always open the file with - VS Code. Just open VS Code by running + If you find this view confusing, you can always open the file with VS Code. Just open VS Code by running

    code . @@ -99,20 +82,15 @@

    Viewing the history

    - Now navigate to the file and click on the - TIMELINE tab at the bottom of the - navigation panel. + Now navigate to the file and click on the TIMELINE tab at the bottom of + the navigation panel.

    - Viewing the history 3 + Viewing the history 3
    @@ -120,9 +98,7 @@

    Viewing the history

    - + + diff --git a/pages/019/filtering_the_history.html b/pages/019/filtering_the_history.html index ad6aa71..5009152 100644 --- a/pages/019/filtering_the_history.html +++ b/pages/019/filtering_the_history.html @@ -1,16 +1,14 @@ + - + Filtering the history +
    @@ -32,54 +30,42 @@

    Filtering the history

    - When browsing the history of a repository we'll usually want to - filter commits. There are several filters that we can use along - with the git log command. For - example, to see the last 3 commits we run + When browsing the history of a repository we'll usually want to filter commits. There are several filters + that we can use along with the git log command. For example, to see the + last 3 commits we run

    git log --online -3

    - To filter by author we use the - --author option and pass the name - of the author. We can short the name in an unambiguous way. + To filter by author we use the --author option and pass the name of the + author. We can short the name in an unambiguous way.

    git log --oneline --author="Daniel"
    - Filtering the history 1 + Filtering the history 1
    - Filtering the history 2 + Filtering the history 2

    - We have several ways of filtering by date. We use the - --before or - --after options. As a value we - can pass a date, or a relative date. So, for example, if we run + We have several ways of filtering by date. We use the --before or + --after options. As a value we can pass a date, or a relative date. So, + for example, if we run

    git log --oneline --before="2020-08-17"

    - Git will show us all commits done on or prior to August 17, 2020. - When using relative dates there are multiple options that Git will - understand. For example, if we run + Git will show us all commits done on or prior to August 17, 2020. When using relative dates there are + multiple options that Git will understand. For example, if we run

    git log --oneline --after="yesterday" @@ -96,85 +82,65 @@

    Filtering the history

    - To find all commits that have a specific pattern in its message we - use the --grep option. For - example, if we want to find all commits that mention + To find all commits that have a specific pattern in its message we use the + --grep option. For example, if we want to find all commits that mention app.py we run

    git log --oneline --grep="app.py"

    - The --grep option will search for - the pattern in the commit message. Keep in mind that the search is - case sensitive. + The --grep option will search for the pattern in the commit message. Keep + in mind that the search is case sensitive.


    - Now suppose we want to find all commits that have added or removed - the declaration of the hello() function. To achieve this - we run + Now suppose we want to find all commits that have added or removed the declaration of the hello() + function. To achieve this we run

    git log --oneline -S"hello()"

    - We can also add the - --patch option to see what was - done in each of the involved commits. + We can also add the --patch option to see what was done in each of the + involved commits.

    - Filtering the history 3 + Filtering the history 3
    - Filtering the history 4 + Filtering the history 4

    - We can also filter the history by a specific range of commits. - First we need to get the IDs for the two commits. Then we run + We can also filter the history by a specific range of commits. First we need to get the IDs for the two + commits. Then we run

    git log --oneline oldest_commit..newest_commit

    - Keep in mind that Git will look for commits greater than - oldest_commit and less than or - equal to newest_commit. + Keep in mind that Git will look for commits greater than oldest_commit + and less than or equal to newest_commit.

    - We can find all commits that touch a particular file or group of - files. To do so we just pass the name or names of the files to - git log. When doing this it's - recommended to separate the last option passed to the - git log command with - -- so that Git does not confuse - options from filenames. Also, keep in mind that all options must - be supplied before the filenames. + We can find all commits that touch a particular file or group of files. To do so we just pass the name or + names of the files to git log. When doing this it's recommended to + separate the last option passed to the git log command with + -- so that Git does not confuse options from filenames. Also, keep in + mind that all options must be supplied before the filenames.

    - Filtering the history 5 + Filtering the history 5
    @@ -182,9 +148,7 @@

    Filtering the history

    - + + diff --git a/pages/020/aliases.html b/pages/020/aliases.html index 3f37c93..4547899 100644 --- a/pages/020/aliases.html +++ b/pages/020/aliases.html @@ -1,16 +1,14 @@ + - + Aliases +
    @@ -32,31 +30,20 @@

    Aliases

    - We can create personal Git commands using aliases. First, let's - take a look at how to format the output. For this, suppose you - don't like the output of neither the - git log command, nor the output - of git log --oneline. We can - create a personalized output like this: + We can create personal Git commands using aliases. First, let's take a look at how to format the output. + For this, suppose you don't like the output of neither the git log + command, nor the output of git log --oneline. We can create a + personalized output like this:

    - - git log --pretty=format:'%Cgreen%an%Creset committed - %Cgreen%h%Creset on %Cgreen%cd%Creset' - + git log --pretty=format:'%Cgreen%an%Creset committed %Cgreen%h%Creset on %Cgreen%cd%Creset'

    - Here %an stands for - author name, %h stands - for short hash, and - %cd stands for - commit date. %C is for - setting and resetting the color. You can check the complete list - of possible placeholders and styles - - here - - . + Here %an stands for author name, + %h stands for short hash, and + %cd stands for commit date. %C + is for setting and resetting the color. You can check the complete list of possible placeholders and + styles here.

    @@ -69,24 +56,19 @@

    Aliases

    - Of course typing all of this every time we want to use the command - is very time consuming. But in Git we can set up aliases for any - command we want (even the built in ones). First we need to define - a new property in the - alias section of the Git - configuration. So we run: + Of course typing all of this every time we want to use the command is very time consuming. But in Git we + can set up aliases for any command we want (even the built in ones). First we need to define a new + property in the alias section of the Git configuration. So we run:

    - git config --global alias.lg "log - --pretty=format:'%Cgreen%an%Creset committed %Cgreen%h%Creset on + git config --global alias.lg "log --pretty=format:'%Cgreen%an%Creset committed %Cgreen%h%Creset on %Cgreen%cd%Creset'"

    - Here lg will be the name of our - custom command, and in between quotes we type our command. We can - see (and edit) our command in VS Code. + Here lg will be the name of our custom command, and in between quotes we + type our command. We can see (and edit) our command in VS Code.

    @@ -99,13 +81,10 @@

    Aliases

    Now we can define an alias for un-staging files.

    - - git config --global alias.unstage 'restore --staged .' - + git config --global alias.unstage 'restore --staged .'

    - With it we can restore all the files in the staging area with one - simple command. + With it we can restore all the files in the staging area with one simple command.

    git unstage @@ -120,9 +99,7 @@

    Aliases

    - + + diff --git a/pages/021/viewing_a_commit.html b/pages/021/viewing_a_commit.html index b0e085c..e9f83c4 100644 --- a/pages/021/viewing_a_commit.html +++ b/pages/021/viewing_a_commit.html @@ -1,16 +1,14 @@ + - + Viewing a commit +
    @@ -32,58 +30,44 @@

    Viewing a commit

    - We can view commits with the - git show command. When doing so, - we can reference a commit hash, or we can use the - HEAD pointer. For example, to see - the commit twice removed from the repository - HEAD we run + We can view commits with the git show command. When doing so, we can + reference a commit hash, or we can use the HEAD pointer. For example, to + see the commit twice removed from the repository HEAD we run

    git show HEAD~2

    - Git will show all the information about that commit. If instead we - only want to see the final version of a file in the that commit we - run + Git will show all the information about that commit. If instead we only want to see the final version of a + file in the that commit we run

    git show HEAD~2:file_path/file_name.ext

    - Keep in mind that if the file is not in the root of our project, - we need to supply the entire path and the filename. + Keep in mind that if the file is not in the root of our project, we need to supply the entire path and the + filename.

    - Viewing a commit 1 + Viewing a commit 1
    - Viewing a commit 2 + Viewing a commit 2

    - If we only want to see the files that were modified in a commit, - we use the --name-only option + If we only want to see the files that were modified in a commit, we use the --name-only option

    git show HEAD~2 --name-only

    - With this option, we can only see the names of the files. If we - also want to see what was done to those files (added, delete, - modified), we use the - --name-status option + With this option, we can only see the names of the files. If we also want to see what was done to those + files (added, delete, modified), we use the --name-status option

    git show HEAD~2 --name-status @@ -95,9 +79,7 @@

    Viewing a commit

    - + + diff --git a/pages/022/viewing_the_changes_across_commits.html b/pages/022/viewing_the_changes_across_commits.html index b2fb768..fee9064 100644 --- a/pages/022/viewing_the_changes_across_commits.html +++ b/pages/022/viewing_the_changes_across_commits.html @@ -1,16 +1,14 @@ + - + Viewing changes across commits +
    @@ -34,43 +32,33 @@

    Viewing changes across commits

    - Suppose we want to see what has changed over the last 3 commits. - To do that we use the + Suppose we want to see what has changed over the last 3 commits. To do that we use the git diff command

    git diff HEAD~3 HEAD

    - If we only want to see the changes to a particular file, we can - add the filename at the end of the command + If we only want to see the changes to a particular file, we can add the filename at the end of the command

    git diff HEAD~3 HEAD file_path/file_name.ext
    - Viewing the changes across commits + Viewing the changes across commits
    - Viewing the changes across commits 2 + Viewing the changes across commits 2

    - Here too we can use options like - --name-only or - --name-status to see only the - list of files that have been changed. + Here too we can use options like --name-only or + --name-status to see only the list of files that have been changed.

    git diff HEAD~5 HEAD~2 --name-only @@ -85,9 +73,7 @@

    Viewing changes across commits

    - + + diff --git a/pages/023/checking_out_a_commit.html b/pages/023/checking_out_a_commit.html index 8a38d16..8f175b8 100644 --- a/pages/023/checking_out_a_commit.html +++ b/pages/023/checking_out_a_commit.html @@ -1,24 +1,19 @@ + - + Checking out a commit +
    -
    @@ -35,10 +30,9 @@

    Checking out a commit

    - Suppose we want to see the snapshot of the complete project at a - certain point in time. We can - checkout a specific commit, and - Git will restore our project to that point in time. + Suppose we want to see the snapshot of the complete project at a certain point in time. We can + checkout a specific commit, and Git will restore our project to that + point in time.

    git checkout commit_hash @@ -49,194 +43,129 @@

    Checking out a commit

    - Checking out a commit 1 + Checking out a commit 1
    - Checking out a commit 2 + Checking out a commit 2

    - Imagine the image to our left represents our repository. The way - Git can keep track of things is by using pointers. If your - background is not in software engineering, just think about - pointers like...well...that...things that point to other things. - An instruction a program needs (in this case Git) that tells him - where he needs to go to find something. Each commit points to its - previous commit. + Imagine the image to our left represents our repository. The way Git can keep track of things is by using + pointers. If your background is not in software engineering, just think about pointers + as...well...that...things that point to other things. An instruction a program needs (in this case Git) + that tells him where he needs to go to find something. Each commit points to its previous commit.

    - All the commits that we've created so far are part of the - master branch. Side note here: - Git started calling this branch the - main branch in mid-2020, but - there are still lots (probably most) repositories that haven't - been changed yet. + All the commits that we've created so far are part of the master branch. + Side note here: Git started calling this branch the main branch in + mid-2020, but there are still lots (probably most) repositories that haven't been changed yet.


    - The way Git keeps track of the different branches is with pointers - too. So, in this example, the - master branch (i.e. the pointer - that tells Git where the - master branch is) is pointing at - our last commit. + The way Git keeps track of the different branches is with pointers too. So, in this example, the + master branch (i.e. the pointer that tells Git where the + master branch is) is pointing at our last commit.

    - Checking out a commit 3 + Checking out a commit 3
    - Checking out a commit 4 + Checking out a commit 4

    - Because we can work in different branches, Git also needs to know - in which branch we are working on. To do this, Git uses another - pointer called HEAD. + Because we can work in different branches, Git also needs to know in which branch we are working on. To do + this, Git uses another pointer called HEAD.

    - This is why when we run, for example, - git log --oneline the last commit - (the first one shown) starts with - (HEAD -> - master). That's just Git's way of telling us that the - master branch is pointing to our - last commit and that we are currently (the - HEAD) pointing to it. + This is why when we run, for example, git log --oneline the last commit + (the first one shown) starts with (HEAD -> + master). That's just Git's way of telling us that the + master branch is pointing to our last commit and that we are currently + (the HEAD) pointing to it.

    - Checking out a commit 5 + Checking out a commit 5
    - Checking out a commit 6 + Checking out a commit 6

    - So, long story short, what that - 'detached HEAD' state message is - telling us is that our HEAD is - not attached to a branch anymore, but pointing to a specific - commit. + So, long story short, what that 'detached HEAD' state message is telling + us is that our HEAD is not attached to a branch anymore, but pointing to + a specific commit.

    - You can see this in the image to the right. While - master is at commit - 8eec1d2, HEAD is at - commit fa1b75e (the one we checked out to). Also, notice - that Git Bash no longer says - (master), but is instead displaying - the commit hash. + You can see this in the image to the right. While master is at commit + 8eec1d2, HEAD is at commit fa1b75e (the one we checked + out to). Also, notice that Git Bash no longer says (master), but is instead + displaying the commit hash.


    - Side note here. When inspecting the log while in a - detached HEAD we need to add the - --all option. Otherwise, Git will - only show us the commits prior to the commit where our - HEAD is at. + Side note here. When inspecting the log while in a detached HEAD we need + to add the --all option. Otherwise, Git will only show us the commits + prior to the commit where our HEAD is at.

    - Checking out a commit 7 + Checking out a commit 7
    - Checking out a commit 8 + Checking out a commit 8

    - One very important consequence of this that we need to always keep - in mind is that we shouldn't create new commits in this state. If - we do so, that new commit will point to our old commit, and our - HEAD will now point to the new - commit. + One very important consequence of this that we need to always keep in mind is that we shouldn't create new + commits in this state. If we do so, that new commit will point to our old commit, and our + HEAD will now point to the new commit.

    - But once we move our HEAD back to - the master (or any other branch), - this commit will not be reachable from any commit or pointer. It's - a dead commit. Git checks for commits like this and deletes them. - So all changes left there will be lost. + But once we move our HEAD back to the + master (or any other branch), this commit will not be reachable from any + commit or pointer. It's a dead commit. Git checks for commits like this and deletes them. So all changes + left there will be lost.

    - Checking out a commit 9 + Checking out a commit 9
    - Checking out a commit 10 + Checking out a commit 10

    - To take the HEAD back to the - master we just run + To take the HEAD back to the master we + just run

    git checkout master @@ -248,9 +177,7 @@

    Checking out a commit

    - + + diff --git a/pages/024/bisect.html b/pages/024/bisect.html index 134664b..be93d0e 100644 --- a/pages/024/bisect.html +++ b/pages/024/bisect.html @@ -1,16 +1,14 @@ + - + Bisect +
    @@ -32,18 +30,15 @@

    Bisect

    - Suppose our project looks like the one on the right and we found a - bug we didn't know existed or what caused it. We could check every - single commit one-by-one until we find it, but that is - time-consuming. bisect is a Git - tool for finding bugs in our code. + Suppose our project looks like the one on the right and we found a bug we didn't know existed or what + caused it. We could check every single commit one-by-one until we find it, but that is time-consuming. + bisect is a Git tool for finding bugs in our code.


    - In a nutshell, it works by doing a binary search throughout our - repository. We'll tell Git of a good commit, and a - bad commit and Git will help us zero-in the commit that - caused the bug so that we can fix it. + In a nutshell, it works by doing a binary search throughout our repository. We'll tell Git of a + good commit, and a bad commit and Git will help us zero-in the commit that caused the + bug so that we can fix it.

    @@ -53,10 +48,9 @@

    Bisect

    - So, imagine 8eec1d2 (our - HEAD) is a bad commit (we found a - bug here), and ca49180 (our initial commit) will be our - first good commit (a commit that we know did not have the issue). + So, imagine 8eec1d2 (our HEAD) is a bad commit (we found a bug + here), and ca49180 (our initial commit) will be our first good commit (a commit that we know did + not have the issue).


    @@ -66,31 +60,25 @@

    Bisect

    git bisect start

    - Notice that Git Bash changed from - (master) to - (master | BISECTING). Right now our - HEAD is at the bad commit (the - last one), so we need to tell Git that this is a bad commit. To do - that, we run + Notice that Git Bash changed from (master) to + (master | BISECTING). Right now our HEAD is + at the bad commit (the last one), so we need to tell Git that this is a bad commit. To do that, we run

    git bisect bad

    - Now we need to give Git a good commit. If you didn't write down - the hash for a good commit before starting the - bisect process don't worry, you - can run git log --oneline and get - it now. So we run + Now we need to give Git a good commit. If you didn't write down the hash for a good commit before starting + the bisect process don't worry, you can run + git log --oneline and get it now. So we run

    git bisect good ca49180

    - Now Git is telling us that we have 7 revisions left (7 commits to - check instead of the total 16), and it's also telling us that we - can get it done in 3 steps. Notice that Git Bash changed again and - is not at commit 24e86ee anymore. + Now Git is telling us that we have 7 revisions left (7 commits to check instead of the total 16), and it's + also telling us that we can get it done in 3 steps. Notice that Git Bash changed again and is not at + commit 24e86ee anymore.

    @@ -100,21 +88,14 @@

    Bisect

    - If we now run - git log --oneline --all we see - that master is at the top and it's - referenced as a bad commit. At the bottom of the log, we see that - there's a second reference for our bad commit. Our - HEAD is at commit 24e86ee. - This means that our working directory has been restored to this - point in time. Therefore, we can test and see if the bug is here - already. If it is, that means that the bug was introduced - somewhere between ca49180 and - HEAD. If it is not, then the bug was - introduced somewhere between - HEAD and - master. Either way, we eliminated - half of all possible commits in one try. + If we now run git log --oneline --all we see that + master is at the top and it's referenced as a bad commit. At the bottom of + the log, we see that there's a second reference for our bad commit. Our HEAD + is at commit 24e86ee. This means that our working directory has been restored to this point in + time. Therefore, we can test and see if the bug is here already. If it is, that means that the bug was + introduced somewhere between ca49180 and HEAD. If it is not, then + the bug was introduced somewhere between HEAD and + master. Either way, we eliminated half of all possible commits in one try.


    For this demo, let's tell Git that this is a good commit

    @@ -129,44 +110,39 @@

    Bisect

    - Now Git is telling us that there are 3 revisions left and that it - will take 2 steps to inspect them. Our - HEAD has now moved to commit - 50db987. If we look at the log again, we see that it has - moved up. Our repository has once again been checked out to this - commit. So we can test our application here and see if the bug is - there or not. Again for this demo, we'll tell Git that this is a - good commit. So again we run + Now Git is telling us that there are 3 revisions left and that it will take 2 steps to inspect them. Our + HEAD has now moved to commit 50db987. If we look at the log again, + we see that it has moved up. Our repository has once again been checked out to this commit. So we can test + our application here and see if the bug is there or not. Again for this demo, we'll tell Git that this is + a good commit. So again we run

    git bisect good

    - And we'll do it one more time so that it moves to the commit prior - to master. + And we'll do it one more time so that it moves to the commit prior to + master.

    - Now we are at commit e22efe7 and suppose that we found - the bug here. We'll tell Git that this is a bad commit + Now we are at commit e22efe7 and suppose that we found the bug here. We'll tell Git that this is + a bad commit

    git bisect bad

    - Now Git knows which one was the first bad commit and it's giving - us all the information about that commit: author, date, a summary - of changes. + Now Git knows which one was the first bad commit and it's giving us all the information about that commit: + author, date, a summary of changes.


    - Now we can inspect and test our code here and find the bug. Once - we know how to fix it, we can move our - HEAD back to - master and implement the fix. + Now we can inspect and test our code here and find the bug. Once we know how to fix it, we can move our + HEAD back to master and implement the + fix.

    git bisect reset @@ -181,9 +157,7 @@

    Bisect

    - + + diff --git a/pages/025/contributors.html b/pages/025/contributors.html index ff28645..2dcb8bb 100644 --- a/pages/025/contributors.html +++ b/pages/025/contributors.html @@ -1,16 +1,14 @@ + - + Contributors +
    @@ -32,35 +30,27 @@

    Contributors

    - If we want find all the people who have contributed to our project - we use, + If we want find all the people who have contributed to our project we use,

    git shortlog

    - This command can take several options. For example, - -n will sort the output according - to the number of commits, -s will - suppress commit descriptions, - -e will show the contributors’ - email address, etc. You can check the entire list by running + This command can take several options. For example, -n will sort the + output according to the number of commits, -s will suppress commit + descriptions, -e will show the contributors' email address, etc. You can + check the entire list by running

    git shortlog -h

    - We can also filter the output using the - --before and + We can also filter the output using the --before and --after options.

    - Contributors 1 + Contributors 1
    @@ -68,9 +58,7 @@

    Contributors

    - + + diff --git a/pages/026/viewing_the_history_of_a_file.html b/pages/026/viewing_the_history_of_a_file.html index 4e9284e..1c38af7 100644 --- a/pages/026/viewing_the_history_of_a_file.html +++ b/pages/026/viewing_the_history_of_a_file.html @@ -1,16 +1,14 @@ + - + Viewing the history of a file +
    @@ -38,21 +36,14 @@

    Viewing the history of a file

    git log file_path/file_name.ext

    - Here we can also use the - --oneline option for showing a - less verbose version of the log, the - --stat option to see stats of - what changed, or the - --patch option to see the actual - changes. + Here we can also use the --oneline option for showing a less verbose + version of the log, the --stat option to see stats of what changed, or + the --patch option to see the actual changes.

    - Viewing the history of a file 1 + Viewing the history of a file 1
    @@ -60,9 +51,7 @@

    Viewing the history of a file

    - + + diff --git a/pages/027/restoring_a_deleted_file.html b/pages/027/restoring_a_deleted_file.html index e168297..bb106b6 100644 --- a/pages/027/restoring_a_deleted_file.html +++ b/pages/027/restoring_a_deleted_file.html @@ -1,16 +1,14 @@ + - + Restoring a deleted file +
    @@ -32,39 +30,29 @@

    Restoring a deleted file

    - We can restore files that we deleted in previous commits. Suppose - that we accidentally removed app.py and now we need it - back. The first thing that we need to do is find the last commit - where that file was not deleted. To do that we run + We can restore files that we deleted in previous commits. Suppose that we accidentally removed + app.py and now we need it back. The first thing that we need to do is find the last commit where + that file was not deleted. To do that we run

    git log --oneline -- app.py

    - So far nothing new. Now, since the file will show up on the commit - in which we delete it, the last commit were the file was not - deleted is the second commit from the top: commit - 8eec1d2. What we need to do now is to - git checkout just that file from - that commit. So we run + So far nothing new. Now, since the file will show up on the commit in which we delete it, the last commit + were the file was not deleted is the second commit from the top: commit 8eec1d2. What we need to + do now is to git checkout just that file from that commit. So we run

    git checkout 8eec1d2 app.py

    - Git will take the file as it was at that point in time and place - it in our staging area. That is why if we run a - git status -s we can see that the - file has an A on the left column. - Lastly, we commit the file to the repository. + Git will take the file as it was at that point in time and place it in our staging area. That is why if we + run a git status -s we can see that the file has an + A on the left column. Lastly, we commit the file to the repository.

    - Restoring a deleted file 1 + Restoring a deleted file 1
    @@ -72,9 +60,7 @@

    Restoring a deleted file

    - + + diff --git a/pages/028/blaming.html b/pages/028/blaming.html index 485d8e4..a3141fd 100644 --- a/pages/028/blaming.html +++ b/pages/028/blaming.html @@ -1,16 +1,14 @@ + - + Blaming +
    @@ -32,29 +30,23 @@

    Blaming

    - We use blame to find the author - of a particular line. To do so we run + We use blame to find the author of a particular line. To do so we run

    git blame file_path/file_name.ext

    - Git will display the entire file, line by line, with the commit ID - in which that line was last changed and the name of the person who - changed it. We could add the email with the - -e option. + Git will display the entire file, line by line, with the commit ID in which that line was last changed and + the name of the person who changed it. We could add the email with the -e + option.


    - If we don't want to see all the lines in the file we use the - -L option and supply the line - numbers from where to start and end. + If we don't want to see all the lines in the file we use the -L option + and supply the line numbers from where to start and end.

    - - git blame -L start_line,end_line - file_path/file_name.ext - + git blame -L start_line,end_line file_path/file_name.ext
    @@ -66,9 +58,7 @@

    Blaming

    - + + diff --git a/pages/029/tagging.html b/pages/029/tagging.html index b76e0e5..ab18482 100644 --- a/pages/029/tagging.html +++ b/pages/029/tagging.html @@ -1,16 +1,14 @@ + - + Tagging +
    @@ -32,34 +30,28 @@

    Tagging

    - Once our project has reached a stable version, we will release it. - That doesn't mean we'll never work on it again. A common and - recommended practice is to bookmark the commit where a release - happened. To do so we use a tag. + Once our project has reached a stable version, we will release it. That doesn't mean we'll never work on + it again. A common and recommended practice is to bookmark the commit where a release happened. To do so + we use a tag.


    - Now, suppose we want to create a release for our project right - before the point in which we introduced app.py. We check - the log and see that this means creating a - tag at commit a642e12. - To do so we run + Now, suppose we want to create a release for our project right before the point in which we introduced + app.py. We check the log and see that this means creating a tag + at commit a642e12. To do so we run

    git tag v1.0 a642e12

    - This will tell Git that we want to make a - tag called v1.0 at - commit a642e12. If we check the log now, we will see that - Git has added that tag at that commit. + This will tell Git that we want to make a tag called v1.0 at + commit a642e12. If we check the log now, we will see that Git has added that tag at that commit.


    - These type of tags are called - lightweight tags because they are just pointers to a - specific commit. A better way is to use annotated tags. - These tags take a release message too. + These type of tags are called lightweight tags because they are + just pointers to a specific commit. A better way is to use annotated tags. These tags take a + release message too.

    @@ -72,25 +64,22 @@

    Tagging

    - First, let's delete the lightweight tag. To do this we use the - -d option and supply the tag - name, like so + First, let's delete the lightweight tag. To do this we use the -d option + and supply the tag name, like so

    git tag -d v1.0

    - You can check the log now and you'll see that the tag is not there - anymore. + You can check the log now and you'll see that the tag is not there anymore.

    - To create an annotated tag we use the - -a option and supply it a message - with the -m option + To create an annotated tag we use the -a option and supply it a + message with the -m option

    git tag -a v1.0 -m "Version 1.0" a642e12 @@ -100,17 +89,14 @@

    Tagging

    git tag -a v2.0 -m "Version 2.0" c674d68

    - Our log now shows that we have two tags pointing at different - commits. + Our log now shows that we have two tags pointing at different commits.


    - But v2.0 had a bug which we fixed in our last commit. So - we'll release a new version of our program. The difference is that - since we now only fixed a bug instead of introducing new - functionality, we'll increment the tag minor instead of the major. - Since we are releasing a tag at the last commit, we don't need to - supply a commit ID + But v2.0 had a bug which we fixed in our last commit. So we'll release a new version of our + program. The difference is that since we now only fixed a bug instead of introducing new functionality, + we'll increment the tag minor instead of the major. Since we are releasing a tag at the last commit, we + don't need to supply a commit ID

    git tag -a v2.1 -m "Version 2.1" @@ -130,19 +116,16 @@

    Tagging

    git tag -n

    - Once we have tags, we can checkout to those points in our commit - history by name instead of using the commit ID. For example, - running + Once we have tags, we can checkout to those points in our commit history by name instead of using the + commit ID. For example, running

    git checkout v1.0

    - moves the HEAD to the - v1.0 tag. Keep in mind that you are in a - 'detached HEAD' state now, so - you'll need to checkout to - master again when done. + moves the HEAD to the v1.0 tag. Keep in mind that you are in a + 'detached HEAD' state now, so you'll need to + checkout to master again when done.

    @@ -151,9 +134,7 @@

    Tagging

    - + + diff --git a/pages/030/what_are_branches.html b/pages/030/what_are_branches.html index 7a85e49..ef05169 100644 --- a/pages/030/what_are_branches.html +++ b/pages/030/what_are_branches.html @@ -1,16 +1,14 @@ + - + What are branches? +
    @@ -32,40 +30,27 @@

    What are branches?

    - Branching allows us to divert from the main line of work, and work - in something different in isolation. This allows us to develop new - features without compromising the stability of our production - code. + Branching allows us to divert from the main line of work, and work in something different in isolation. + This allows us to develop new features without compromising the stability of our production code.


    - Branches in Git are fast and cheap because they are just pointers - to different commits in a commit tree. Likewise, Git knows which - branch we are working on by using another pointer called - HEAD. + Branches in Git are fast and cheap because they are just pointers to different commits in a commit tree. + Likewise, Git knows which branch we are working on by using another pointer called HEAD.

    - What are branches 1 + What are branches 1
    - What are branches 2 + What are branches 2

    - When we move from one branch to the other, what Git does is to - reposition the HEAD pointer to the pointer of that - branch. + When we move from one branch to the other, what Git does is to reposition the HEAD pointer to the + pointer of that branch.

    @@ -74,9 +59,7 @@

    What are branches?

    - + + diff --git a/pages/031/working_with_branches.html b/pages/031/working_with_branches.html index d88246f..7a77081 100644 --- a/pages/031/working_with_branches.html +++ b/pages/031/working_with_branches.html @@ -1,16 +1,14 @@ + - + Working with branches +
    @@ -34,18 +32,15 @@

    Working with branches

    - Suppose we got a bug report. To fix this bug we should first - create a new branch. This way any changes that we do to our code - can be tested before we merge them into production. To create a - new branch we run + Suppose we got a bug report. To fix this bug we should first create a new branch. This way any changes + that we do to our code can be tested before we merge them into production. To create a new branch we run

    git branch new_branch_name

    - If we run git branch, Git will - return a list of the branches our project has. The branch we are - currently in will have an asterisk next to its name. + If we run git branch, Git will return a list of the branches our project + has. The branch we are currently in will have an asterisk next to its name.


    To switch branches we run

    @@ -58,60 +53,45 @@

    Working with branches

    - Working with branches 1 + Working with branches 1
    - Working with branches 2 + Working with branches 2

    - Now that we are in the new branch, we can work on fixing the bug. - Once we are done, we need to stage and commit our changes. + Now that we are in the new branch, we can work on fixing the bug. Once we are done, we need to stage and + commit our changes.


    - Suppose we've done all that. If we take a look at the log now - we'll see that our bugfix branch is ahead of the master branch. If - we switch back to the master branch, we'll see that the bug is - still there. We still need to merge our branches. + Suppose we've done all that. If we take a look at the log now we'll see that our bugfix branch is ahead of + the master branch. If we switch back to the master branch, we'll see that the bug is still there. We still + need to merge our branches.

    - Once we are done with a branch, we should delete it. To do so we - run + Once we are done with a branch, we should delete it. To do so we run

    git branch -d branch_name

    - Keep in mind that if the changes that you did in that branch have - not been merged into the master branch, Git will complain about - this action. This is to protect you from accidentally deleting - work you still need. To override this protection we use + Keep in mind that if the changes that you did in that branch have not been merged into the master branch, + Git will complain about this action. This is to protect you from accidentally deleting work you still + need. To override this protection we use

    git branch -D branch_name
    - Working with branches 3 + Working with branches 3
    @@ -119,9 +99,7 @@

    Working with branches

    - + + diff --git a/pages/032/comparing_branches.html b/pages/032/comparing_branches.html index 3d191ce..9cda60b 100644 --- a/pages/032/comparing_branches.html +++ b/pages/032/comparing_branches.html @@ -1,16 +1,14 @@ + - + Comparing branches +
    @@ -32,61 +30,48 @@

    Comparing branches

    - At some point, we'll have to merge our branches to master. To get - a list of the commits that will be merged into the master branch - when we do so, we use + At some point, we'll have to merge our branches to master. To get a list of the commits that will be + merged into the master branch when we do so, we use

    git log master..branch_name

    - With this, Git will give us a list of all the commits that are in - the other branch, but not in master. Just as before, we can use - the --oneline option to make the - output more concise. + With this, Git will give us a list of all the commits that are in the other branch, but not in master. + Just as before, we can use the --oneline option to make the output more + concise.

    - Comparing branches 1 + Comparing branches 1
    - Comparing branches 2 + Comparing branches 2

    - If want to see the actual changes we use the - diff command + If want to see the actual changes we use the diff command

    git diff master..branch_name

    - Here Git will show us the diff of - the different files that will be affected by the merge. + Here Git will show us the diff of the different files that will be + affected by the merge.


    - When diffing branches we don't always have to type both branches. - If we want to see the - diff between the branch we are - currently in and another branch we just run + When diffing branches we don't always have to type both branches. If we want to see the + diff between the branch we are currently in and another branch we just + run

    git diff branch_name

    - If we only want a list of the files that will change and the type - of change, we can use the + If we only want a list of the files that will change and the type of change, we can use the --name-status option

    @@ -99,9 +84,7 @@

    Comparing branches

    - + + diff --git a/pages/033/stashing.html b/pages/033/stashing.html index 8fde019..35c58fc 100644 --- a/pages/033/stashing.html +++ b/pages/033/stashing.html @@ -1,16 +1,14 @@ + - + Stashing +
    @@ -32,37 +30,30 @@

    Stashing

    - Suppose we are working on a new feature and we realize that we - forgot to create a new branch before starting. We could throw away - our work and create a new branch. But that would - involve...well...throwing away our work. We can solve this - situation by stashing our work. + Suppose we are working on a new feature and we realize that we forgot to create a new branch before + starting. We could throw away our work and create a new branch. But that would involve...well...throwing + away our work. We can solve this situation by stashing our work.


    - As an example, suppose we created the new calc.py on - master and now we want to move it - into a new branch called - calc-functions. First we need to + As an example, suppose we created the new calc.py on master and now + we want to move it into a new branch called calc-functions. First we need to stash our un-tracked file. To so we run

    git stash push -u -m "calc functions"

    - We use the -u option here because - our file was un-tracked. More on that below. Now that we've stash - our changes, we can switch into a new branch with + We use the -u option here because our file was un-tracked. More on that + below. Now that we've stash our changes, we can switch into a new branch with

    git switch -C "calc-functions"

    - This will create a new branch called - calc-functions and the - -C option with tell Git to also - switch into it. Now that we are - in the new branch, we can unpack our stashed changes by running + This will create a new branch called calc-functions and the + -C option with tell Git to also switch + into it. Now that we are in the new branch, we can unpack our stashed changes by running

    git stash pop @@ -76,8 +67,7 @@

    Stashing

    - If you are left wondering how does this work, here's a simplified - explanation. + If you are left wondering how does this work, here's a simplified explanation.

    @@ -90,19 +80,13 @@

    Stashing

    - When we invoke - git stash Git commits our - changes and creates a new type of reference called a - stash from where it can access that new commit - (technically there are several commits involved depending on - what we are stashing, you can read all about it - + When we invoke git stash Git commits our changes and creates a new + type of reference called a stash from where it can access that new commit (technically + there are several commits involved depending on what we are stashing, you can read all about it + here - - ). + ).

    @@ -112,8 +96,7 @@

    Stashing

    - When we switch branches Git just moves the - HEAD reference to the tip of that branch. + When we switch branches Git just moves the HEAD reference to the tip of that branch.

    @@ -123,9 +106,8 @@

    Stashing

    - Finally, when we pop our - stashed commit, Git adds the content of that commit to the - working directory in that branch. + Finally, when we pop our stashed commit, Git adds the content of + that commit to the working directory in that branch.

    @@ -153,11 +135,9 @@

    Stashing

    - One thing to keep in mind here is the difference between - git stash pop and - git stash apply. They both add - the content of the stash to the working directory of that branch, - but while pop deletes the stash, + One thing to keep in mind here is the difference between git stash pop + and git stash apply. They both add the content of the stash to the + working directory of that branch, but while pop deletes the stash, apply does not.

    @@ -171,15 +151,11 @@

    Stashing

    git stash list

    - Git keeps track of which stash was added first and which one was - added last. The stash at the top of the list is the one that was - added last. When we run - git stash apply (or - pop) this is the stash that will - be applied by default. But each stash has a unique identifier - called stash@{n} where n is its position on the - stash stack. You can use these identifiers (or just the - n number) to reference them when popping or applying. + Git keeps track of which stash was added first and which one was added last. The stash at the top of the + list is the one that was added last. When we run git stash apply (or + pop) this is the stash that will be applied by default. But each stash + has a unique identifier called stash@{n} where n is its position on the stash stack. You + can use these identifiers (or just the n number) to reference them when popping or applying.

    @@ -192,18 +168,16 @@

    Stashing

    - One place in which this references come in handy is when viewing - the changes of a stash. When we have more than one stash we should - check what's in a stash before applying in to the working - directory. To do this we run + One place in which this references come in handy is when viewing the changes of a stash. When we have more + than one stash we should check what's in a stash before applying in to the working directory. To do this + we run

    git stash show n

    - where n is the reference. With - this Git will show us what changes are done in each stash so that - we can choose which one we want to apply. + where n is the reference. With this Git will show us what changes are + done in each stash so that we can choose which one we want to apply.


    Once we select the stash to apply, we can do so with

    @@ -211,8 +185,7 @@

    Stashing

    git stash apply n

    - Once we are done with our stashes we should delete them. Here we - can use + Once we are done with our stashes we should delete them. Here we can use

    git stash drop n @@ -229,9 +202,7 @@

    Stashing

    - + + diff --git a/pages/034/merging.html b/pages/034/merging.html index 5cbc81b..12707d6 100644 --- a/pages/034/merging.html +++ b/pages/034/merging.html @@ -1,16 +1,14 @@ + - + Merging +
    @@ -32,31 +30,24 @@

    Merging

    - Merging is the action of bringing the changes in one branch onto - another branch. In Git there are two types of mergers: - fast-forward merges, and three-way merges. To - make things clearer, suppose we have a branch called - new-feature that we want to merge - into master. + Merging is the action of bringing the changes in one branch onto another branch. In Git there are two + types of mergers: fast-forward merges, and three-way merges. To make things clearer, + suppose we have a branch called new-feature that we want to merge into + master.


    - Git will use a fast-forward merge if - master and - new-feature have not diverged. This - means that the last common commit for both branches is also the - last commit on the master branch. In - this case, all Git has to do is move the - master pointer to the tip of the + Git will use a fast-forward merge if master and + new-feature have not diverged. This means that the last common commit for + both branches is also the last commit on the master branch. In this case, + all Git has to do is move the master pointer to the tip of the new-feature branch.


    - If the branches have diverged, Git will use a three-way merge. In - this scenario, Git will look at three different commits (thus - three-way merge). The last common ancestor to both branches and - the tip in each branch. Then it will create a new commit (called - merge commit) that integrates all changes. + If the branches have diverged, Git will use a three-way merge. In this scenario, Git will look at three + different commits (thus three-way merge). The last common ancestor to both branches and the tip in each + branch. Then it will create a new commit (called merge commit) that integrates all changes.

    @@ -89,9 +80,7 @@

    Merging

    - + + diff --git a/pages/035/fast_forward_merging.html b/pages/035/fast_forward_merging.html index 3f16510..2a01b31 100644 --- a/pages/035/fast_forward_merging.html +++ b/pages/035/fast_forward_merging.html @@ -1,16 +1,14 @@ + - + Fast-forward merging +
    @@ -30,84 +28,60 @@

    Fast-forward merging

    - To make a fast-forward merge, first we need to switch to - the branch that we want to merge into. Then we use the - git merge command. For example, - if we want to merge a branch called - bugfix into - master we run + To make a fast-forward merge, first we need to switch to the branch that we want to merge into. + Then we use the git merge command. For example, if we want to merge a + branch called bugfix into master we run

    git merge bugfix
    - Fast-forward merging 1 + Fast-forward merging 1
    - Fast-forward merging 2 + Fast-forward merging 2

    - Fast-forward merges have one disadvantage compared to three-way - merges. Since they don't have a merge commit, undoing the merge - (for example if there was a bug in the merged code) can be hard. - So we usually tell Git to not do an ff-merge, even if it's - possible. Let's see this in an example. + Fast-forward merges have one disadvantage compared to three-way merges. Since they don't have a merge + commit, undoing the merge (for example if there was a bug in the merged code) can be hard. So we usually + tell Git to not do an ff-merge, even if it's possible. Let's see this in an example.


    - Since we don't need the old - bugfix branch anymore (because all - its content has already been merged into - master), we delete it and create a - new bugfix branch where we'll fix a - new bug. Once the bug is fixed, we stage and commit the changes, - and switch to master. To merge we - run + Since we don't need the old bugfix branch anymore (because all its content + has already been merged into master), we delete it and create a new + bugfix branch where we'll fix a new bug. Once the bug is fixed, we stage and + commit the changes, and switch to master. To merge we run

    git merge --no-ff bugfix

    - VS Code will open and we'll be asked to write a commit message. In - general, the default message is OK. When we close the VS Code tab, - Git will carry out the merge, using a three-way merge strategy. + VS Code will open and we'll be asked to write a commit message. In general, the default message is OK. + When we close the VS Code tab, Git will carry out the merge, using a three-way merge strategy.

    - Now let's check our log, but using the - --graph option. So we run + Now let's check our log, but using the --graph option. So we run

    git log --oneline --all --graph -5

    - This will show a one-line log of our last 5 commits from all - branches, using the graph display. Here we can see that commit - 4188bbb was created as a commit message that combined - commits e6614d7 and d106b04. + This will show a one-line log of our last 5 commits from all branches, using the graph display. Here we + can see that commit 4188bbb was created as a commit message that combined commits + e6614d7 and d106b04.

    - Fast-forward merging 3 + Fast-forward merging 3
    @@ -117,9 +91,8 @@

    Fast-forward merging

    git config ff no

    - This will disable them for this repository alone. If you want to - disable them for all repositories, just add the - --global option. + This will disable them for this repository alone. If you want to disable them for all repositories, just + add the --global option.

    @@ -128,9 +101,7 @@

    Fast-forward merging

    - + + diff --git a/pages/036/three_way_merges.html b/pages/036/three_way_merges.html index d578dc2..6d25e98 100644 --- a/pages/036/three_way_merges.html +++ b/pages/036/three_way_merges.html @@ -1,16 +1,14 @@ + - + Three-way merging +
    @@ -32,86 +30,64 @@

    Three-way merging

    - To see how three-way merges work, first we'll create a new branch - called new-feature and create a new - file there called main.js. After staging and committing - main.js we switch back to - master. Here we'll update - toc.txt and again, we'll stage and commit the changes. + To see how three-way merges work, first we'll create a new branch called + new-feature and create a new file there called main.js. After + staging and committing main.js we switch back to master. Here we'll + update toc.txt and again, we'll stage and commit the changes.


    - Now we are in the situation described in the three-way merge - scenario. Our target branch (in this case - master) is one commit ahead of the - commit it was when we created the objective branch (in this case - new-feature). Thus, Git can't just - move the master pointer to the - tip of the new-feature branch - because there's a commit in + Now we are in the situation described in the three-way merge scenario. Our target branch (in this case + master) is one commit ahead of the commit it was when we created the + objective branch (in this case new-feature). Thus, Git can't just move the + master pointer to the tip of the + new-feature branch because there's a commit in master that cannot be reached from new-feature.


    - To run a three-way merge we proceed as before and start by - switching into the master branch. - Now we run + To run a three-way merge we proceed as before and start by switching into the + master branch. Now we run

    git merge new-feature

    - VS Code will be launched where we can edit our commit message (if - necessary). When we close it, Git will conclude the merge process. + VS Code will be launched where we can edit our commit message (if necessary). When we close it, Git will + conclude the merge process.

    - Three-way merges 1 + Three-way merges 1
    - Three-way merges 2 + Three-way merges 2

    - We can see our merges in the - log more clearly by using the + We can see our merges in the log more clearly by using the --graph option

    git log --oneline --all --graph -10

    - Starting from the bottom and moving up, the first merge we see is - the fast-forward merge from the now-deleted - bugfix branch onto - master. This branch was created - from commit d106b04. On it, we created commit - e6614d7. Because at the time of merge - master was still at commit - d106b04 and we used a - --no-ff option, the merge commit - 4188bbb was created. Git shows this merge as a triangle - where each commit is a vertex. + Starting from the bottom and moving up, the first merge we see is the fast-forward merge from the + now-deleted bugfix branch onto master. This + branch was created from commit d106b04. On it, we created commit e6614d7. Because at the + time of merge master was still at commit d106b04 and we used a + --no-ff option, the merge commit 4188bbb was created. Git shows + this merge as a triangle where each commit is a vertex.


    - On the other hand, for our three-way merge, Git is displaying a - trapezoid, since there's a commit on - master (2aa25c1) that was - created after the - new-feature branch was created. - Both branches merged at commit 9a4b466. + On the other hand, for our three-way merge, Git is displaying a trapezoid, since there's a commit on + master (2aa25c1) that was created after the + new-feature branch was created. Both branches merged at commit + 9a4b466.

    @@ -120,9 +96,7 @@

    Three-way merging

    - + + diff --git a/pages/037/viewing_branches.html b/pages/037/viewing_branches.html index 426a10b..1f927e9 100644 --- a/pages/037/viewing_branches.html +++ b/pages/037/viewing_branches.html @@ -1,16 +1,14 @@ + - + Viewing merged and unmerged branches +
    @@ -32,25 +30,22 @@

    Viewing merged and unmerged branches

    - Sometimes we might forget to delete branches that have already - been merged into master. To check - which branches have already been merged we use + Sometimes we might forget to delete branches that have already been merged into + master. To check which branches have already been merged we use

    git branch --merged

    - Git will return the list of branches that have already been merged - into master. Similarly, to check - which branches have not been merged we run + Git will return the list of branches that have already been merged into + master. Similarly, to check which branches have not been merged we run

    git branch --no-merged

    - We can use these two commands with any branch and Git will show - the list of branches that have merged or have not been merged onto - our current branch. + We can use these two commands with any branch and Git will show the list of branches that have merged or + have not been merged onto our current branch.

    @@ -59,9 +54,7 @@

    Viewing merged and unmerged branches

    - + + diff --git a/pages/038/merge_conflicts.html b/pages/038/merge_conflicts.html index 2d0d8f0..d514207 100644 --- a/pages/038/merge_conflicts.html +++ b/pages/038/merge_conflicts.html @@ -1,16 +1,14 @@ + - + Merge conflicts +
    @@ -32,27 +30,23 @@

    Merge conflicts

    - When merging branches, three different types of conflicts may - arise + When merging branches, three different types of conflicts may arise

    • - The same line of code was changed in different ways in the two - merging branches. + The same line of code was changed in different ways in the two merging branches.
    • - A file was changed in one branch but deleted in the other - branch. + A file was changed in one branch but deleted in the other branch.
    • - The same file is added in different branches, but the content of - the file is different in the two branches. + The same file is added in different branches, but the content of the file is different in the two + branches.

    - Whenever there's a conflict Git will not know how to merge the - branches and it's going to ask us to solve the conflicts manually - before staging and committing the merge. + Whenever there's a conflict Git will not know how to merge the branches and it's going to ask us to solve + the conflicts manually before staging and committing the merge.

    @@ -60,18 +54,14 @@

    Merge conflicts

    - To see an example of the first scenario, let's create a new branch - called bugfix and change the - toc.txt file. In this file, we'll delete all its content - and on the first line write Changes from bugfix branch. - Now stage it and commit it. + To see an example of the first scenario, let's create a new branch called + bugfix and change the toc.txt file. In this file, we'll delete all + its content and on the first line write Changes from bugfix branch. Now stage it and commit it.


    - Next, we'll switch back to master. - Open the toc.txt file. Delete all its content, and in the - first row write Changes from master branch. Stage it. - Commit it. + Next, we'll switch back to master. Open the toc.txt file. Delete + all its content, and in the first row write Changes from master branch. Stage it. Commit it.


    Now we'll run

    @@ -79,28 +69,18 @@

    Merge conflicts

    git merge bugfix

    - Now Git is telling us that there is a conflict and that the - automatic merge process failed. Notice that Git Bash has changed - from master to - master|MERGING. This tells us that - Git is in the middle of a merge process. + Now Git is telling us that there is a conflict and that the automatic merge process failed. Notice that + Git Bash has changed from master to + master|MERGING. This tells us that Git is in the middle of a merge process.

    - Merge conflicts 1 + Merge conflicts 1
    - Merge conflicts 2 + Merge conflicts 2

    First, let's run

    @@ -108,10 +88,8 @@

    Merge conflicts

    git status

    - Here we can see where the merge conflict is under the unmerged - paths. Git is telling us that both branches have changes to - toc.txt. So let's open toc.txt in VS Code by - running + Here we can see where the merge conflict is under the unmerged paths. Git is telling us that both branches + have changes to toc.txt. So let's open toc.txt in VS Code by running

    code toc.txt @@ -121,113 +99,83 @@

    Merge conflicts

    - The image to the right is what you'll see in VS Code. What we see - are markers that represent the changes in the current branch - (green) and the changes in the other branch (blue). In between - them there's a divider marked by equal signs, =======. - This syntax will be repeated throughout the file as many times as - there are conflicts. + The image to the right is what you'll see in VS Code. What we see are markers that represent the changes + in the current branch (green) and the changes in the other branch (blue). In between them there's a + divider marked by equal signs, =======. This syntax will be repeated throughout the file as many + times as there are conflicts.

    - Merge conflicts 3 + Merge conflicts 3
    - Merge conflicts 4 + Merge conflicts 4

    - On top of the HEAD marker, there - are three buttons. We need to choose one. If we select - Accept Current Change then the changes from the current - branch will be kept and the incoming ones will be discarded. If - the select Accept Incoming Changes the incoming changes - will be kept and the current ones will be discarded. If we select - Accept Both Changes then both changes will be kept, in - the order in which VS Code is showing them. + On top of the HEAD marker, there are three buttons. We need to choose one. + If we select Accept Current Change then the changes from the current branch will be kept and the + incoming ones will be discarded. If the select Accept Incoming Changes the incoming changes will + be kept and the current ones will be discarded. If we select Accept Both Changes then both + changes will be kept, in the order in which VS Code is showing them.


    - For this demo, I'll go with Accept Both Changes and the - file will change to what you see on the image to the left. + For this demo, I'll go with Accept Both Changes and the file will change to what you see on the + image to the left.

    - Three brief comments before we move on. There's a fourth button - that reads Compare Changes. If you click on it, VS Code - will open the file in diff mode (that is, showing the changes side - by side). + Three brief comments before we move on. There's a fourth button that reads Compare Changes. If + you click on it, VS Code will open the file in diff mode (that is, showing the changes side by side).


    - If you selected an option and wish to change it, even if you have - already saved it, just press Ctrl + z (undo). Git will not - continue with the merge process until we manually create a merge - commit. + If you selected an option and wish to change it, even if you have already saved it, just press Ctrl + z + (undo). Git will not continue with the merge process until we manually create a merge commit.


    - You can always edit the file by hand. To do so, you'll need to - remove the markers and the separation. Try not to include new - changes on the merge commit (that is, new code or new lines of any - sort). But sometimes this is not possible because of the kind of - merge conflict that we are faced with. We refer to merge commits - that add new code as evil commits. + You can always edit the file by hand. To do so, you'll need to remove the markers and the separation. Try + not to include new changes on the merge commit (that is, new code or new lines of any sort). But sometimes + this is not possible because of the kind of merge conflict that we are faced with. We refer to merge + commits that add new code as evil commits.

    - Now that we have resolved all merge conflicts, we can stage our - changes with git add toc.txt. If - we run + Now that we have resolved all merge conflicts, we can stage our changes with + git add toc.txt. If we run

    git status

    - we'll see that now there are no more unmerged paths. Therefore, - there are no more changes. At this point, we can commit our - changes. Since this is a merge commit, we will not introduce a - commit message. So we run + we'll see that now there are no more unmerged paths. Therefore, there are no more changes. At this point, + we can commit our changes. Since this is a merge commit, we will not introduce a commit message. So we run

    git commit
    - Merge conflicts 5 + Merge conflicts 5

    - Because we didn't provide a commit message, Git will open VS Code. - In general, we accept the default short-message but add a - description explaining how the merge conflicts were resolved. Once - done, we save our changes and close VS Code. Now Git will complete - the merge process. You can see that Git Bash has changed from - master|MERGING to - master. + Because we didn't provide a commit message, Git will open VS Code. In general, we accept the default + short-message but add a description explaining how the merge conflicts were resolved. Once done, we save + our changes and close VS Code. Now Git will complete the merge process. You can see that Git Bash has + changed from master|MERGING to master.

    @@ -236,9 +184,7 @@

    Merge conflicts

    - + + diff --git a/pages/039/aborting_a_merge.html b/pages/039/aborting_a_merge.html index e6d7135..e8339fc 100644 --- a/pages/039/aborting_a_merge.html +++ b/pages/039/aborting_a_merge.html @@ -1,16 +1,14 @@ + - + Aborting a merge +
    @@ -32,9 +30,8 @@

    Aborting a merge

    - Sometimes we run into conflicts while merging and we decide that - this is not a good time to solve them. In order to continue - working, we need to abort the merge process. To do so we run + Sometimes we run into conflicts while merging and we decide that this is not a good time to solve them. In + order to continue working, we need to abort the merge process. To do so we run

    git merge --abort @@ -46,9 +43,7 @@

    Aborting a merge

    - + + diff --git a/pages/040/undoing_a_merge.html b/pages/040/undoing_a_merge.html index aee2ac1..70182d0 100644 --- a/pages/040/undoing_a_merge.html +++ b/pages/040/undoing_a_merge.html @@ -1,16 +1,14 @@ + - + Undoing a merge +
    @@ -32,50 +30,36 @@

    Undoing a merge

    - Sometimes we do a merge and realize that our program stopped - working and we want to undo it. Here we have two options: 1) - undoing the commit as if it had never been there (called - resetting), 2) create a new commit that cancels out all the - changes in our merge commit (called reverting). + Sometimes we do a merge and realize that our program stopped working and we want to undo it. Here we have + two options: 1) undoing the commit as if it had never been there (called resetting), 2) create a new + commit that cancels out all the changes in our merge commit (called reverting).


    - When resetting we have to be very careful because we are - re-writing history. If the changes only exist on our local - repository that is OK. But if we have already shared the changes - with the rest of our team we should - NEVER re-write history. + When resetting we have to be very careful because we are re-writing history. If the changes only exist on + our local repository that is OK. But if we have already shared the changes with the rest of our team we + should NEVER re-write history.


    - The diagrams below explain the two situations. In both of them, we - begin from the same starting point: a merger commit has taken - place, merging a branch called - new-feature into - master. The difference is that when - we use reset we move the - master pointer back to its parent - commit (the commit with a red border that is before the merge - commit, and in the master branch). - Because there are now no commits or pointers pointing to our - merger commit, Git will Garbage Collect this commit and - throw it away. + The diagrams below explain the two situations. In both of them, we begin from the same starting point: a + merger commit has taken place, merging a branch called new-feature into + master. The difference is that when we use reset we move the + master pointer back to its parent commit (the commit with a red border that + is before the merge commit, and in the master branch). Because there are + now no commits or pointers pointing to our merger commit, Git will Garbage Collect this commit + and throw it away.


    - On the other hand, when we use a revert we are creating a - new commit that comes after the merge commit, and moving the - HEAD pointer onto this new commit - (shown in blue with white border on the diagram). This commit - makes all the opposite changes as those that were done on the - merge commit. One thing to consider when reverting mergers is that - the merge commit actually has two parent commits: one on - master and one on - new-feature. We'll have to specify - Git which commit to revert to and, since we'll do it from the - master branch (because it's the - branch that was modified with the merger), we'll revert to the - parent commit on this branch. + On the other hand, when we use a revert we are creating a new commit that comes after the merge + commit, and moving the HEAD pointer onto this new commit (shown in blue + with white border on the diagram). This commit makes all the opposite changes as those that were done on + the merge commit. One thing to consider when reverting mergers is that the merge commit actually has two + parent commits: one on master and one on + new-feature. We'll have to specify Git which commit to revert to and, since + we'll do it from the master branch (because it's the branch that was + modified with the merger), we'll revert to the parent commit on this branch.

    @@ -83,32 +67,16 @@

    Undoing a merge

    - Undoing a merge 1 + Undoing a merge 1
    - Undoing a merge 2 + Undoing a merge 2
    - Undoing a merge 3 + Undoing a merge 3
    - Undoing a merge 4 + Undoing a merge 4
    @@ -116,110 +84,80 @@

    Undoing a merge

    - Before we start with an example, let's take a look at our log. - We'll do both operations on commit 3a485a4, which is our - last merge commit. Before starting an operation like this, it's - always recommended that you write down the ID for the commit you - are going to revert or reset. You can delete it once done. + Before we start with an example, let's take a look at our log. We'll do both operations on commit + 3a485a4, which is our last merge commit. Before starting an operation like this, it's always + recommended that you write down the ID for the commit you are going to revert or reset. You can delete it + once done.

    - Undoing a merge 5 + Undoing a merge 5

    - We'll start with the reset option. But before we do we - need to clarify some terminology. The - git reset command has three - options: + We'll start with the reset option. But before we do we need to clarify some terminology. The + git reset command has three options:

    • - --soft: Git will have our - repository point to a different commit, but our index and - working tree will not be affected. + --soft: Git will have our repository point to a different commit, but + our index and working tree will not be affected.
    • - --mixed: Git will take the new - snapshot and put it in the index as well. This is the default - option so we don't need to specify it. + --mixed: Git will take the new snapshot and put it in the index as + well. This is the default option so we don't need to specify it.
    • - --hard: Git will take the new - snapshot and copy it to both the index and the working tree. - This means that all environments will look the same. It also - means that all local changes in our working-tree will be lost, - so make sure to stash them before resetting. + --hard: Git will take the new snapshot and copy it to both the index + and the working tree. This means that all environments will look the same. It also means that all local + changes in our working-tree will be lost, so make sure to stash them before resetting.
    - Undoing a merge 6 + Undoing a merge 6

    - To reset our repository, index, and working tree in the - master branch to the commit previous - to the merge we run + To reset our repository, index, and working tree in the master branch to the + commit previous to the merge we run

    git reset --hard HEAD~1

    - We can see that both HEAD and - master are now at commit - b03190d, and the merge commit has disappeared from our - tree. The commit is still in our repository thou, and we can - recover it (until the Garbage Collector takes it away for - good). + We can see that both HEAD and master are now + at commit b03190d, and the merge commit has disappeared from our tree. The commit is still in our + repository thou, and we can recover it (until the Garbage Collector takes it away for good).

    - If we want to reset to the point before resetting (i.e. a point - where the merge is still there) we run + If we want to reset to the point before resetting (i.e. a point where the merge is still there) we run

    git reset --hard 3a485a4

    - We can now check our log and see that our merge commit is back. - Keep in mind that if you close Git Bash, the - Garbage Collector will be run and the commit will be lost - forever. + We can now check our log and see that our merge commit is back. Keep in mind that if you close Git Bash, + the Garbage Collector will be run and the commit will be lost forever.

    - Undoing a merge 7 + Undoing a merge 7
    - Undoing a merge 8 + Undoing a merge 8

    Now let's take a look at reverting. To do so we run

    @@ -227,22 +165,19 @@

    Undoing a merge

    git revert -m 1 HEAD

    - Here we are telling Git that it should revert the - HEAD pointer to the previous - commit on the master branch. The - -m 1 means - first parent commit. + Here we are telling Git that it should revert the HEAD pointer to the + previous commit on the master branch. The + -m 1 means first parent commit.


    - Git will open VS Code so that we can edit our message, but here - we'll accept the default and close it. When we do, Git will - complete the reverting process. + Git will open VS Code so that we can edit our message, but here we'll accept the default and close it. + When we do, Git will complete the reverting process.


    - We can check our log now and see that a new commit has been added - and its message says that it has reverted the merge. + We can check our log now and see that a new commit has been added and its message says that it has + reverted the merge.

    @@ -251,9 +186,7 @@

    Undoing a merge

    - + + diff --git a/pages/041/squash_merging.html b/pages/041/squash_merging.html index c776727..85ff6c6 100644 --- a/pages/041/squash_merging.html +++ b/pages/041/squash_merging.html @@ -1,16 +1,14 @@ + - + Squash merging +
    @@ -32,66 +30,46 @@

    Squash merging

    - Suppose we have a branch called - bugfix where we fixed a bug in a - hurry. In this branch, we did two commits: B1 and - B2. But because we were in a hurry, these are not very - good commits. So now we need to merge them into - master but instead of using a - three-way merge, we are going to create a squash merge. - In this type of merge, we create a new commit which is the - combination of all the commits in our branch but has no ancestry - to the tip of the branch (in this example, commit B2). + Suppose we have a branch called bugfix where we fixed a bug in a hurry. In + this branch, we did two commits: B1 and B2. But because we were in a hurry, these are + not very good commits. So now we need to merge them into master but instead + of using a three-way merge, we are going to create a squash merge. In this type of merge, we + create a new commit which is the combination of all the commits in our branch but has no ancestry to the + tip of the branch (in this example, commit B2).


    - Once we squash merge we can (and should) delete the - bugfix branch. Though this technique - produces clean linear histories on the - master branch, it should only be - used for short-lived branches with small changes and dirty commit - histories. + Once we squash merge we can (and should) delete the bugfix branch. Though + this technique produces clean linear histories on the master branch, it + should only be used for short-lived branches with small changes and dirty commit histories.

    - Squash merging 1 + Squash merging 1
    - Squash merging 2 + Squash merging 2

    - As an example, let's create a new branch called - bugfix. In this branch, we'll create - two new commits, one that modifies audience.txt and one - that modifies toc.txt. + As an example, let's create a new branch called bugfix. In this branch, + we'll create two new commits, one that modifies audience.txt and one that modifies + toc.txt.


    - Now we switch onto the - master branch. In order to merge the - bugfix branch onto - master, we run + Now we switch onto the master branch. In order to merge the + bugfix branch onto master, we run

    git merge --squash bugfix

    - If we check the status of our repository we see that our changes - are now available on master, but - they are not committed. We need to create a commit with these + If we check the status of our repository we see that our changes are now available on + master, but they are not committed. We need to create a commit with these changes, and give it a meaningful message that explains the merge.

    @@ -99,29 +77,20 @@

    Squash merging

    - If we check the log now, we will see that our - bugfix branch has two commits: - 3accc2f and 2de4c95. Our - master branch is at commit - 6166e28 which is our squash merge commit, but this commit - is not connected to the tip of the + If we check the log now, we will see that our bugfix branch has two commits: + 3accc2f and 2de4c95. Our master branch is at commit + 6166e28 which is our squash merge commit, but this commit is not connected to the tip of the bugfix branch.


    - Since the branch was not merged on to - master, it is very important that we - delete it. Otherwise, it will cause confusion in the future once - we have moved on from this bug and no one even remembers what that - branch was supposed to do. + Since the branch was not merged on to master, it is very important that we + delete it. Otherwise, it will cause confusion in the future once we have moved on from this bug and no one + even remembers what that branch was supposed to do.

    - Squash merging 3 + Squash merging 3
    @@ -129,9 +98,7 @@

    Squash merging

    - + + diff --git a/pages/042/rebasing.html b/pages/042/rebasing.html index 216ec05..60a1925 100644 --- a/pages/042/rebasing.html +++ b/pages/042/rebasing.html @@ -1,16 +1,14 @@ + - + Rebasing +
    @@ -32,23 +30,16 @@

    Rebasing

    - In Git we can change the base commit of a branch by using a - technique called rebasing. - Suppose we have a repository that looks like the one on the - diagram. The way rebasing seems to work is by moving the base - commit of a branch (that is the parent commit of F1). The - problem with rebasing is that this is not true. Commits are - immutable. So what Git actually does is to create new commits (in - this example, F1* and F2*) that come after the - master pointer, and moves the branch - pointer from F2 to F2*. Now there are no pointers or commits pointing to F2 so - Git will delete them on the next - Garbage Collection cycle. This might be OK if this branch - is local (only you have it on your computer), but if other people - created commits on top of F2 their work will be lost - too!! So be very careful when rebasing. + In Git we can change the base commit of a branch by using a technique called + rebasing. Suppose we have a repository that looks like the one on the + diagram. The way rebasing seems to work is by moving the base commit of a branch (that is the parent + commit of F1). The problem with rebasing is that this is not true. Commits are immutable. So what + Git actually does is to create new commits (in this example, F1* and + F2*) that come after the master pointer, and moves the + branch pointer from F2 to F2*. Now there are no pointers or commits pointing + to F2 so Git will delete them on the next Garbage Collection cycle. This might be OK if + this branch is local (only you have it on your computer), but if other people created commits on top of + F2 their work will be lost too!! So be very careful when rebasing.

    @@ -59,32 +50,16 @@

    Rebasing

    Rebasing

    - Rebasing 1 + Rebasing 1
    - Rebasing 2 + Rebasing 2
    - Rebasing 3 + Rebasing 3
    - Rebasing 4 + Rebasing 4
    @@ -93,25 +68,19 @@

    Rebasing

    - To see an example of rebasing, I've created a new branch called - feature. In this branch, I've - updated the toc.txt. Back in the - master branch, I've updated the - main.js file. If we look at the log we can see that both - branches have diverged. The new - feature branch is at - 9795f10, master is at - 4104ec7, and their last common ancestor is + To see an example of rebasing, I've created a new branch called feature. In + this branch, I've updated the toc.txt. Back in the master branch, + I've updated the main.js file. If we look at the log we can see that both branches have diverged. + The new feature branch is at 9795f10, + master is at 4104ec7, and their last common ancestor is 6166e28.


    - When we rebase the feature branch we - will change its base commit from 6166e28 (which was the - commit that our master branch was at - when we created the feature branch), - to commit 4104ec7 (which is the commit where - master is now). + When we rebase the feature branch we will change its base commit from + 6166e28 (which was the commit that our master branch was at + when we created the feature branch), to commit 4104ec7 (which is + the commit where master is now).

    @@ -124,39 +93,33 @@

    Rebasing

    - To rebase, make sure that you are on the target branch, in this - case, feature. Now we run + To rebase, make sure that you are on the target branch, in this case, + feature. Now we run

    git rebase master

    - This is telling Git to change the base of the current branch (in - this case feature) with the tip of - the branch that we supply (in this case - master). Usually, when rebasing - there will be conflicts that we must resolve the same way that we - resolve merge conflicts. + This is telling Git to change the base of the current branch (in this case + feature) with the tip of the branch that we supply (in this case + master). Usually, when rebasing there will be conflicts that we must resolve + the same way that we resolve merge conflicts.


    - Now if we check our log we can see that there's a linear path from - master to our - feature branch. If we merge these - branches, Git will do a simple fast-forward merge. But take a - close look at the commit IDs. Before the rebase, the tip of our - branch was at commit 9795f10, now it's at commit - 6f25ebf. This is a new commit! + Now if we check our log we can see that there's a linear path from master to + our feature branch. If we merge these branches, Git will do a simple + fast-forward merge. But take a close look at the commit IDs. Before the rebase, the tip of our branch was + at commit 9795f10, now it's at commit 6f25ebf. This is a new commit!

    - We can checkout to the old commit 9795f10 and use the log - to see the graph. The new tip of the rebased branch is in fact an - entirely new commit. The old one still exists. But there are no - pointers pointing to it, Git will Garbage Collect it. + We can checkout to the old commit 9795f10 and use the log to see the graph. The new tip of the + rebased branch is in fact an entirely new commit. The old one still exists. But there are no pointers + pointing to it, Git will Garbage Collect it.

    @@ -169,11 +132,9 @@

    Rebasing

    - Back on the master branch, we can - now merge the feature branch onto it - and Git will resolve it with a fast-forward merge. If we check out - the log again, we'll see that both branches are now pointing to - the same commit. + Back on the master branch, we can now merge the + feature branch onto it and Git will resolve it with a fast-forward merge. If + we check out the log again, we'll see that both branches are now pointing to the same commit.

    @@ -181,34 +142,29 @@

    Rebasing

    - A few comments about rebasing conflicts. When Git tries to rebase, - it will start by taking the oldest commit in the current branch - and adding it to the tip of the target branch. If there's a - conflict we'll have to open VS Code and solve it the same way we - would solve a merge conflict. But because Git does a rebase one - commit at a time, when we are done, we need to run + A few comments about rebasing conflicts. When Git tries to rebase, it will start by taking the oldest + commit in the current branch and adding it to the tip of the target branch. If there's a conflict we'll + have to open VS Code and solve it the same way we would solve a merge conflict. But because Git does a + rebase one commit at a time, when we are done, we need to run

    git rebase --continue

    - This will let Git know that it can continue to the next commit. If - we wish to skip one commit, we run + This will let Git know that it can continue to the next commit. If we wish to skip one commit, we run

    git rebase --skip

    - Git will not create a copy of that commit and move on to the next - one. If at any point in time we wish to stop the rebase all - together, we run + Git will not create a copy of that commit and move on to the next one. If at any point in time we wish to + stop the rebase all together, we run

    git rebase --abort

    - This will tell Git to stop the rebase and revert everything back - to before we even started. + This will tell Git to stop the rebase and revert everything back to before we even started.

    @@ -216,28 +172,25 @@

    Rebasing

    - If before starting a rebase we already know that we always want to - keep the changes as they are in the - feature branch, we can run the - rebase with the -Xtheirs option. + If before starting a rebase we already know that we always want to keep the changes as they are in the + feature branch, we can run the rebase with the + -Xtheirs option.

    git rebase -Xtheirs NEW_BASE_BRANCH

    - Likewise, if before starting the rebase we already know that we - wish to keep the changes in the - master branch, the we use the - -Xours option. + Likewise, if before starting the rebase we already know that we wish to keep the changes in the + master branch, the we use the -Xours + option.

    git rebase -Xours NEW_BASE_BRANCH

    - This -X option is called the - strategy option. You should keep in mind that when we - supply a strategy to be used by default, said strategy is used in - all commits that are being rebased. + This -X option is called the strategy option. You should keep in + mind that when we supply a strategy to be used by default, said strategy is used in all commits that are + being rebased.

    @@ -246,9 +199,7 @@

    Rebasing

    - + + diff --git a/pages/043/cherry_picking.html b/pages/043/cherry_picking.html index 97e3251..9cbac4f 100644 --- a/pages/043/cherry_picking.html +++ b/pages/043/cherry_picking.html @@ -1,16 +1,14 @@ + - + Cherry picking +
    @@ -32,13 +30,10 @@

    Cherry picking

    - Suppose we are working on a new feature on its own branch, but - there's a commit on that branch that we would like to have on - another branch (say master), but we - are not ready to merge the entire branch. This is where - cherry-picking comes in. The cherry-picking tool - allows us to grab a commit from another branch, and apply it to - the tip of our current branch. + Suppose we are working on a new feature on its own branch, but there's a commit on that branch that we + would like to have on another branch (say master), but we are not ready to + merge the entire branch. This is where cherry-picking comes in. The cherry-picking tool + allows us to grab a commit from another branch, and apply it to the tip of our current branch.

    @@ -49,18 +44,10 @@

    Cherry picking

    Cherry-picking

    - Cherry-picking 1 + Cherry-picking 1
    - Cherry-picking 2 + Cherry-picking 2
    @@ -69,58 +56,41 @@

    Cherry picking

    - As an example, take a look at the git log. Here I've added two - commits to the feature branch (f88ecdc - and fc6e687), and one commit to the - master branch (88c4524). - Now suppose that we want to get the changes made in commit - f88ecdc and apply them to the tip of the - master branch. To cherry-pick this - commit we run + As an example, take a look at the git log. Here I've added two commits to the + feature branch (f88ecdc and fc6e687), and one commit to + the master branch (88c4524). Now suppose that we want to get the + changes made in commit f88ecdc and apply them to the tip of the + master branch. To cherry-pick this commit we run

    git cherry-pick f88ecdc

    - Before cherry-picking commits, be sure to check your current - branch. Your current branch should be the branch into which you - want to bring the target commit. + Before cherry-picking commits, be sure to check your current branch. Your current branch should be the + branch into which you want to bring the target commit.

    - Cherry-picking 3 + Cherry-picking 3
    - Cherry-picking 4 + Cherry-picking 4

    - If we take a look at the log we can see that all previous commits - still exist, but the tip of the - master branch is now - 86bf257 which is a copy of f88ecdc. + If we take a look at the log we can see that all previous commits still exist, but the tip of the + master branch is now 86bf257 which is a copy of f88ecdc.

    - During a cherry-pick, you might run into conflicts. These - conflicts are no different than a - merge conflict. Solve them - using VS Code and then stage and commit your changes. + During a cherry-pick, you might run into conflicts. These conflicts are no different than a + merge conflict. Solve them using VS Code and then stage and commit + your changes.

    @@ -129,9 +99,7 @@

    Cherry picking

    - + + diff --git a/pages/044/picking_a_file_from_another_branch.html b/pages/044/picking_a_file_from_another_branch.html index 64c8201..06e59f9 100644 --- a/pages/044/picking_a_file_from_another_branch.html +++ b/pages/044/picking_a_file_from_another_branch.html @@ -1,16 +1,14 @@ + - + Picking a file from another branch +
    @@ -34,30 +32,23 @@

    Picking a file from another branch

    - Suppose you are working on a branch and need a file from another - branch. As an example, I've created a branch called - feature and made some changes to the - toc.txt file in that branch. Now we switch back to the - master branch and we are going to - bring the last version of toc.txt from the - feature branch onto the + Suppose you are working on a branch and need a file from another branch. As an example, I've created a + branch called feature and made some changes to the toc.txt file in + that branch. Now we switch back to the master branch and we are going to + bring the last version of toc.txt from the feature branch onto the master branch. To do so, we run

    git restore --source=feature -- toc.txt

    - Git will grab that version of the file and place it in our working - tree. We can now stage it and commit it to the - master branch. + Git will grab that version of the file and place it in our working tree. We can now stage it and commit it + to the master branch.

    - Picking a file from another branch 1 + Picking a file from another branch 1
    @@ -65,9 +56,7 @@

    Picking a file from another branch

    - + + diff --git a/pages/045/collaboration_workflows.html b/pages/045/collaboration_workflows.html index 95df9ac..4bc54d0 100644 --- a/pages/045/collaboration_workflows.html +++ b/pages/045/collaboration_workflows.html @@ -1,24 +1,19 @@ + - + Collaboration workflows +
    -
    @@ -37,44 +32,31 @@

    Collaboration workflows

    - When working in collaboration with other people we use hosting - services like GitHub to host a centralized version of the - repository. There are two possible workflows that we can use: - Centralized Workflow or - Integration-Manager Workflow. + When working in collaboration with other people we use hosting services like GitHub to host a centralized + version of the repository. There are two possible workflows that we can use: Centralized Workflow + or Integration-Manager Workflow.


    - In the Centralized Workflow, all collaborators have push - authorization and can thus write changes to the central - repository. They all start by - cloning the central repository to - get a local copy of it on their machines. To keep their copy - up-to-date with what's on the central repository, they use the - pull command. To send their local - changes to the central repository they use the - push command. + In the Centralized Workflow, all collaborators have push authorization and can thus write changes + to the central repository. They all start by cloning the central + repository to get a local copy of it on their machines. To keep their copy up-to-date with what's on the + central repository, they use the pull command. To send their local + changes to the central repository they use the push command.


    - In the Integration-Manager Workflow, only some people - (known as Maintainers) have push access to the - central repository. In order to contribute to these projects, - Contributors need to first - fork the central repository. This - creates a copy of the central repository on GitHub to which they - have push access. Then they must - clone this - forked repository to get a local - copy on their machines. Once they are done with their proposed - changes, they push them into - their forked copy of the - centralized repository, and from it, send a - pull request to the - Maintainer of the original centralized repository. - Maintainers then review the changes and decide whether - they want to pull the changes - into the repository or not. + In the Integration-Manager Workflow, only some people (known as Maintainers) have + push access to the central repository. In order to contribute to these projects, + Contributors need to first fork the central repository. This + creates a copy of the central repository on GitHub to which they have push access. Then they must + clone this forked repository to get a + local copy on their machines. Once they are done with their proposed changes, they + push them into their forked copy of the + centralized repository, and from it, send a pull request to the + Maintainer of the original centralized repository. Maintainers then review the changes + and decide whether they want to pull the changes into the repository or + not.

    @@ -82,16 +64,10 @@

    Collaboration workflows

    - +
    - +
    @@ -99,54 +75,39 @@

    Collaboration workflows

    - The Centralized Workflow is the workflow we commonly use - for projects with people we know. The - Integration-Manager Workflow is the one commonly used for - open-source projects where anyone can contribute. + The Centralized Workflow is the workflow we commonly use for projects with people we know. The + Integration-Manager Workflow is the one commonly used for open-source projects where anyone can + contribute.


    - Many companies use a hybrid workflow. In this workflow, there are - two roles: the team manager and the contributors, and the - repository is organized in at least three branches. The - master branch is where the - production code lives. The team manager is in charge of - maintaining this branch and of merging Pull Requests. Other team - members work on the staging and - feature branches. When someone needs - to start working on a new feature, they start by creating a new - branch from the staging branch. Once - they are done working, they send a - pull request from the - feature branch to the - staging. Another team member must - approve it before it can be merged on to the - staging branch. + Many companies use a hybrid workflow. In this workflow, there are two roles: the team manager and the + contributors, and the repository is organized in at least three branches. The + master branch is where the production code lives. The team manager is in + charge of maintaining this branch and of merging Pull Requests. Other team members work on the + staging and feature branches. When someone + needs to start working on a new feature, they start by creating a new branch from the + staging branch. Once they are done working, they send a + pull request from the feature branch to the + staging. Another team member must approve it before it can be merged on to + the staging branch.


    - There's usually a server that runs the code in the - staging branch called a - staging server. Once code reaches this branch (and thus - this server) it is presented to clients and/or stakeholders for - approval. If approved, the team manager merges the - staging branch into the - master branch and creates a new - release tag. Code that makes it to - the master branch is run on the - production server and makes up the application or program - that can be accessed by the final users. + There's usually a server that runs the code in the staging branch called a + staging server. Once code reaches this branch (and thus this server) it is presented to clients + and/or stakeholders for approval. If approved, the team manager merges the + staging branch into the master branch and + creates a new release tag. Code that makes it to the + master branch is run on the production server and makes up the + application or program that can be accessed by the final users.

    - Collaboration workflows 3 + Collaboration workflows 3
    @@ -154,9 +115,7 @@

    Collaboration workflows

    - + + diff --git a/pages/046/creating_a_github_repository.html b/pages/046/creating_a_github_repository.html index c33cec9..42f2d9b 100644 --- a/pages/046/creating_a_github_repository.html +++ b/pages/046/creating_a_github_repository.html @@ -1,16 +1,14 @@ + - + Creating a GitHub repository +
    @@ -34,108 +32,75 @@

    Creating a GitHub repository

    - When you log on to GitHub, you'll see your home page. On the - left-hand panel you can find your repositories (top) and your - teams (bottom). On the main panel you can see your recent activity - (top) and the recent activity of people you follow or repositories - you've stared. On the right-hand panel GitHub will recommend other - repositories you might be interested in. + When you log on to GitHub, you'll see your home page. On the left-hand panel you can find your + repositories (top) and your teams (bottom). On the main panel you can see your recent activity + (top) and the recent activity of people you follow or repositories you've stared. On the right-hand panel + GitHub will recommend other repositories you might be interested in.


    - To create a new repository on GitHub, login, and on the home page - click the - New button - icon on the left-hand side panel. + To create a new repository on GitHub, login, and on the home page click the + New button icon on the + left-hand side panel.

    - Creating a GitHub repository 1 + Creating a GitHub repository 1
    - Creating a GitHub repository 3 + Creating a GitHub repository 3

    - Here you can create a new repository. Mandatory fields have a red - asterisk next to them. If you've created - template repositories and want to create a new repository - based on one of your templates you can choose so at the top. A - template repository is a repository that already comes - with certain files and directories. Usually, you will create - templates for things you do quite often and that share some common - structure. + Here you can create a new repository. Mandatory fields have a red asterisk next to them. If you've created + template repositories and want to create a new repository based on one of your templates you can + choose so at the top. A template repository is a repository that already comes with certain files + and directories. Usually, you will create templates for things you do quite often and that share some + common structure.


    - After choosing a name and (optionally) a - description for your repository, you need to choose - whether it will be public or private. Public repositories can be - seen by anyone, but you can still manage who has - push access to them. Private repositories can only be - seen by you and by those with whom you choose to share it with (by - adding them as collaborators). You can manage different levels of - privileges for contributors on private repositories. + After choosing a name and (optionally) a description for your repository, you need to + choose whether it will be public or private. Public repositories can be seen by anyone, but you can still + manage who has push access to them. Private repositories can only be seen by you and by those + with whom you choose to share it with (by adding them as collaborators). You can manage different levels + of privileges for contributors on private repositories.


    - Below this there are three checkboxes. The README file is a - Markdown file where you can explain how to use the repository. Its - content will be displayed on the repositories code tab (more on - that later). I suggest you always create all repositories with a - README file. Next, you can choose to add a - .gitignore file. If you do so, a dropdown menu will - appear where you can choose the language. These are templates that - already come with a list of the files you should normally ignore - when working on the selected language. I suggest you always create - all repositories with a .gitignore file. + Below this there are three checkboxes. The README file is a Markdown file where you can explain how to use + the repository. Its content will be displayed on the repositories code tab (more on that later). I suggest + you always create all repositories with a README file. Next, you can choose to add a .gitignore + file. If you do so, a dropdown menu will appear where you can choose the language. These are templates + that already come with a list of the files you should normally ignore when working on the selected + language. I suggest you always create all repositories with a .gitignore file.


    - Lastly, you can choose a template LICENSE file. These are usually - only used on open-source projects. + Lastly, you can choose a template LICENSE file. These are usually only used on open-source projects.

    - After clicking on the Create Repository button at the - bottom of the page, GitHub will create a new repository for you. - If you selected either a README, .gitignore, or LICENSE then - GitHub will also create the first commit (with an - Initial commit message) and create those files for you. + After clicking on the Create Repository button at the bottom of the page, GitHub will create a + new repository for you. If you selected either a README, .gitignore, or LICENSE then GitHub will also + create the first commit (with an Initial commit message) and create those files for you.

    - Creating a GitHub repository 4 + Creating a GitHub repository 4

    If you need to add collaborators to the repository, go to - Settings > Manage Access > Invite Collaborator section. - You can search for them by name, user name, or email address. Once - you add them, they will receive an invite via email where they can - choose to accept or ignore your invitation. + Settings > Manage Access > Invite Collaborator section. You can search for them by name, user + name, or email address. Once you add them, they will receive an invite via email where they can choose to + accept or ignore your invitation.

    @@ -144,9 +109,7 @@

    Creating a GitHub repository

    - + + diff --git a/pages/047/cloning_a_repository.html b/pages/047/cloning_a_repository.html index 6fda861..119aaab 100644 --- a/pages/047/cloning_a_repository.html +++ b/pages/047/cloning_a_repository.html @@ -1,16 +1,14 @@ + - + Cloning a repository +
    @@ -34,29 +32,17 @@

    Cloning a repository

    To start working on our repository, we first need to clone it to our local machine. To do so, click on the - Clone repository icon + Clone repository icon button and copy the URL.

    - Cloning a repository 1 + Cloning a repository 1
    - Cloning a repository 3 + Cloning a repository 3

    Now, open the Git Bash and run

    @@ -64,63 +50,46 @@

    Cloning a repository

    git clone url directory_name

    - where url is the URL you copied from GitHub and the - directory_name is optional (by default Git will create a - directory with the same name as your repository). + where url is the URL you copied from GitHub and the directory_name is optional (by + default Git will create a directory with the same name as your repository).

    - Now, cd into the directory and - check the log. Here you'll see the two pointers you are already - familiar with, HEAD and - main (remember, - main and - master are the same thing). But - there are also two new pointers - origin/main and - origin/HEAD. + Now, cd into the directory and check the log. Here you'll see the two + pointers you are already familiar with, HEAD and + main (remember, main and + master are the same thing). But there are also two new pointers + origin/main and origin/HEAD.


    - The origin part refers to the GitHub - repository. It's just how Git names it. So, - origin/master is telling us where the - master branch was in that - repository the last time we checked (in this case the last time we - checked was when we cloned the - repository). The same happens with - HEAD, but it tells us where the + The origin part refers to the GitHub repository. It's just how Git names it. + So, origin/master is telling us where the + master branch was in that repository the last time we checked (in this case + the last time we checked was when we cloned the repository). The same + happens with HEAD, but it tells us where the HEAD was the last time we checked.

    - Cloning a repository 4 + Cloning a repository 4

    - Technically these are called Remote tracking branches. - But they don't work like regular branches. You can't - git switch into them, or + Technically these are called Remote tracking branches. But they don't work like regular branches. + You can't git switch into them, or commit to them.

    - Cloning a repository 5 + Cloning a repository 5

    You can check the list of remotes by running

    @@ -128,11 +97,9 @@

    Cloning a repository

    git remote -v

    - A remote is any repository that is not on the current - working directory. Currently, we only have one remote (the origin - on GitHub). The -v option tells - Git to show us the URLs. These are the URLs that will be used when - talking to that remote. + A remote is any repository that is not on the current working directory. Currently, we only have + one remote (the origin on GitHub). The -v option tells Git to show us the + URLs. These are the URLs that will be used when talking to that remote.

    @@ -141,9 +108,7 @@

    Cloning a repository

    - + + diff --git a/pages/048/fetching.html b/pages/048/fetching.html index 21b05d0..3b17667 100644 --- a/pages/048/fetching.html +++ b/pages/048/fetching.html @@ -1,16 +1,14 @@ + - + Fetching +
    @@ -32,18 +30,16 @@

    Fetching

    - One thing to always keep in mind when working with GitHub is that - your local repository and the remote repository are not connected - and thus, don't sync up automatically when something changes on - either of them. + One thing to always keep in mind when working with GitHub is that your local repository and the remote + repository are not connected and thus, don't sync up automatically when something changes on either of + them.


    - Suppose a situation like the one described in the diagram below. - We start with both the local and remote repositories synced-up. - They both only have one commit (commit A). Next, we make - a commit on the remote repository. Now we need to tell our local - Git repository to sync up with the remote GitHub repository. + Suppose a situation like the one described in the diagram below. We start with both the local and remote + repositories synced-up. They both only have one commit (commit A). Next, we make a commit on the + remote repository. Now we need to tell our local Git repository to sync up with the remote GitHub + repository.

    @@ -68,15 +64,11 @@

    Fetching

    - As an example, let's head on to GitHub and edit the - README.md file. To do so, click on the pencil icon on the - top-right corner of the file. This will open the file on edit - mode. Now, edit the file. Then, scroll to the bottom of the page - and click on the - - button. If we click on the Code tab, we'll see that next - to the README.md on the list of files, the last commit - time has changed to now. + As an example, let's head on to GitHub and edit the README.md file. To do so, click on the pencil + icon on the top-right corner of the file. This will open the file on edit mode. Now, edit the file. Then, + scroll to the bottom of the page and click on the + button. If we click on the Code tab, we'll see that next to the README.md on the list of + files, the last commit time has changed to now.

    @@ -89,10 +81,9 @@

    Fetching

    - Now we are in the situation described in frame 2 of the diagram. - Our remote repository has one more commit than our local - repository. You can verify this by using the - git log command. + Now we are in the situation described in frame 2 of the diagram. Our remote repository has one more commit + than our local repository. You can verify this by using the git log + command.


    To bring the changes into our local repository we run

    @@ -100,42 +91,33 @@

    Fetching

    git fetch remote branch

    - where remote is the name of the - remote from where we want to - fetch and - branch is the name of the branch - in that remote that we want to fetch. If we omit the - branch option, Git will fetch all - branches, and if we omit the - remote option, Git will assume we - want to fetch the origin remote. + where remote is the name of the remote from where we want to + fetch and branch is the name of the + branch in that remote that we want to fetch. If we omit the branch + option, Git will fetch all branches, and if we omit the remote option, + Git will assume we want to fetch the origin remote.


    - Now if we look at the log again, we'll see that - origin/main and - origin/HEAD have both moved one - commit ahead of the local HEAD and - main. We can also check this by + Now if we look at the log again, we'll see that origin/main and + origin/HEAD have both moved one commit ahead of the local + HEAD and main. We can also check this by running

    git branch -vv

    - Git is now telling us that our local - main is behind the remote by 1 - commit. To bring our main branch - forward we merge the remote tracking branch onto the local by - running + Git is now telling us that our local main is behind the remote by 1 commit. + To bring our main branch forward we merge the remote tracking branch onto + the local by running

    git merge origin/main

    - Now, main and - origin/main are pointing to the same - commit. + Now, main and origin/main are pointing to the + same commit.

    @@ -144,9 +126,7 @@

    Fetching

    - + + diff --git a/pages/049/pulling.html b/pages/049/pulling.html index e6b53c1..70da08e 100644 --- a/pages/049/pulling.html +++ b/pages/049/pulling.html @@ -1,16 +1,14 @@ + - + Pulling +
    @@ -30,26 +28,23 @@

    Pulling

    - Because syncing up the local and remote repositories is so common, - Git has a special command that will - git fetch and - git merge origin/master in one go + Because syncing up the local and remote repositories is so common, Git has a special command that will + git fetch and git merge origin/master in + one go

    git pull

    - To see an example of this, I've created a new commit on GitHub. - Now we run + To see an example of this, I've created a new commit on GitHub. Now we run

    git pull

    - In the Git Bash image, you can see how Git first fetched the - updates and then automatically performed a merge (fast-forward - merge in this case). + In the Git Bash image, you can see how Git first fetched the updates and then automatically performed a + merge (fast-forward merge in this case).

    @@ -60,24 +55,19 @@

    Pulling

    - Since you will probably be working on teams, most of the time - updating your local repository will not be so straightforward - since while you were making commits on your local repository, - other team members were making commits on their local - repositories. Once done, you'll send your changes to the remote - (an action called pushing which - we'll cover next). But what happens if your local - main branch and the remote - main branch have diverge? + Since you will probably be working on teams, most of the time updating your local repository will not be + so straightforward since while you were making commits on your local repository, other team members were + making commits on their local repositories. Once done, you'll send your changes to the remote (an action + called pushing which we'll cover next). But what happens if your local + main branch and the remote main branch have + diverge?


    - Because updating the local repository involves fetching the origin - and merging, the situations you may encounter are the same as when - you merge two local branches: either 1) the other person changed - some file which does not affect the files you are changing, or 2) - you both updated the same file and you'll have to resolve a merger - conflict when pulling. + Because updating the local repository involves fetching the origin and merging, the situations you may + encounter are the same as when you merge two local branches: either 1) the other person changed some file + which does not affect the files you are changing, or 2) you both updated the same file and you'll have to + resolve a merger conflict when pulling.

    @@ -88,27 +78,24 @@

    Pulling

    - Let's see an example of the first situation: you changed some - files in your local repository that have not been changed in the - remote repository. To do this, first we go back to GitHub and - write yet another line in the README.md file. Then we - create a new local file and commit it. Finally, we + Let's see an example of the first situation: you changed some files in your local repository that have not + been changed in the remote repository. To do this, first we go back to GitHub and write yet another line + in the README.md file. Then we create a new local file and commit it. Finally, we git pull.


    - Because our local and remote - main branches had diverged, Git - used a three-way merge and created a merge commit. + Because our local and remote main branches had diverged, Git used a + three-way merge and created a merge commit.

    - Because this creates a non-linear history, some people prefer - using a git pull --rebase. To see - this, first we need to undo the merge commit. Then we run + Because this creates a non-linear history, some people prefer using a + git pull --rebase. To see this, first we need to undo the merge commit. + Then we run

    git pull --rebase @@ -124,9 +111,7 @@

    Pulling

    - + + diff --git a/pages/050/pushing.html b/pages/050/pushing.html index 8a99d5b..edff992 100644 --- a/pages/050/pushing.html +++ b/pages/050/pushing.html @@ -1,16 +1,14 @@ + - + Pushing +
    @@ -32,35 +30,29 @@

    Pushing

    - Once we are finished making changes locally, you have to - push them on to the remote - repository so that others can see them too. To do this we run + Once we are finished making changes locally, you have to push them on to + the remote repository so that others can see them too. To do this we run

    git push remote branch

    - Here branch is the remote branch to which we want to push - to. If we omit it, then Git will assume you want to push to the - main branch. remote refers - to the remote repository to which you wish to push to. If omitted, - Git will assume that you want to push onto origin. + Here branch is the remote branch to which we want to push to. If we omit it, then Git will assume + you want to push to the main branch. remote refers to the remote + repository to which you wish to push to. If omitted, Git will assume that you want to push onto origin.


    - If this is your first time pushing onto a remote, Git will ask for - your GitHub credentials so that it can authenticate and make sure - you have push access. We'll see how to store them next so that you - don't have to supply them every time you push. + If this is your first time pushing onto a remote, Git will ask for your GitHub credentials so that it can + authenticate and make sure you have push access. We'll see how to store them next so that you don't have + to supply them every time you push.


    - Sometimes, others will have pushed their changes before you. If - so, Git will not let you push your changes until you update your - local repository with the remote one. If this is the case, you - just need to pull before you can push. Keep in mind that when - pulling, you may encounter merge conflicts that you will have to - resolve before being able to push. + Sometimes, others will have pushed their changes before you. If so, Git will not let you push your changes + until you update your local repository with the remote one. If this is the case, you just need to pull + before you can push. Keep in mind that when pulling, you may encounter merge conflicts that you will have + to resolve before being able to push.

    @@ -70,8 +62,7 @@

    Pushing

    - Some people online will tell you that when your changes get - rejected, you should force push by running + Some people online will tell you that when your changes get rejected, you should force push by running

    git push -f @@ -81,15 +72,11 @@

    Pushing

    git push --force

    - You should NEVER - EVER - EVER - EVER force push onto a remote - repository unless you have discussed it with your teammates and - everyone is in line with this action. What a force push does is it - tells GitHub that it should discard all commits ahead of your - local repository, and push your changes. So you are throwing away - your teammates work. + You should NEVER EVER + EVER EVER force push onto a remote repository + unless you have discussed it with your teammates and everyone is in line with this action. What a force + push does is it tells GitHub that it should discard all commits ahead of your local repository, and push + your changes. So you are throwing away your teammates work.

    @@ -98,9 +85,7 @@

    Pushing

    - + + diff --git a/pages/051/storing_credentials.html b/pages/051/storing_credentials.html index 1511cd8..0ffb431 100644 --- a/pages/051/storing_credentials.html +++ b/pages/051/storing_credentials.html @@ -1,16 +1,14 @@ + - + Storing credentials +
    @@ -30,19 +28,17 @@

    Storing credentials

    - In order to avoid having to enter our GitHub credentials every - time we need to push, we need to store them in our machine. We - have two options here. If we run + In order to avoid having to enter our GitHub credentials every time we need to push, we need to store them + in our machine. We have two options here. If we run

    git config --global credential.helper cache

    - Git will store our credentials in memory for 15 minutes. If we - want to store them on disk we need to use Keychain on - Mac, or Windows Credential Manager on Windows. Either of - these will encrypt our credentials. There's an option for storing - GitHub credentials on plain text files, but it's not recommended. + Git will store our credentials in memory for 15 minutes. If we want to store them on disk we need to use + Keychain on Mac, or Windows Credential Manager on Windows. Either of these will encrypt + our credentials. There's an option for storing GitHub credentials on plain text files, but it's not + recommended.

    @@ -51,9 +47,7 @@

    Storing credentials

    - + + diff --git a/pages/052/sharing_tags.html b/pages/052/sharing_tags.html index cf9b0db..9d3801b 100644 --- a/pages/052/sharing_tags.html +++ b/pages/052/sharing_tags.html @@ -1,16 +1,14 @@ + - + Sharing tags +
    @@ -32,29 +30,22 @@

    Sharing tags

    - By default, the push command does - not push local tags onto the remote repository - automatically. We need to specifically tell it to push them. To do - so, we run + By default, the push command does not push local tags onto the + remote repository automatically. We need to specifically tell it to push them. To do so, we run

    git push origin tag_name

    - where tag_name is the name we - have our tag when creating it. If you pushed it by accident and - need to delete it from the remote repository, you need to run + where tag_name is the name we have our tag when creating it. If you + pushed it by accident and need to delete it from the remote repository, you need to run

    git push origin --delete tag_name
    - Sharing tags 1 + Sharing tags 1
    @@ -62,9 +53,7 @@

    Sharing tags

    - + + diff --git a/pages/053/releases.html b/pages/053/releases.html index ed44696..1db9fb5 100644 --- a/pages/053/releases.html +++ b/pages/053/releases.html @@ -1,16 +1,14 @@ + - + Releases +
    @@ -32,86 +30,66 @@

    Releases

    - Releases are a GitHub (not Git) feature that is built on top of - tags (every release requires a tag). To create one, go to your - repositories home page and, on the right-hand panel, click on - Releases. You'll be directed to the releases page. Now - click on Create a new release. + Releases are a GitHub (not Git) feature that is built on top of tags (every release requires a tag). To + create one, go to your repositories home page and, on the right-hand panel, click on Releases. + You'll be directed to the releases page. Now click on Create a new release.


    - First, we need to give it a Tag version. If we already - have tags we can use one of those. If we don't have a tag, when we - create the release, GitHub will add it to the latest commit on the - branch that we select. + First, we need to give it a Tag version. If we already have tags we can use one of those. If we + don't have a tag, when we create the release, GitHub will add it to the latest commit on the branch that + we select.


    - Next, select the branch. Generally, programs are released based on - the master branch, but you can select any other branch in your - repository. + Next, select the branch. Generally, programs are released based on the master branch, but you can select + any other branch in your repository.


    - Then, write a Release Title. It can be anything you want. - Here I use the tag name. + Then, write a Release Title. It can be anything you want. Here I use the tag name.


    - After that, we can include our release notes. You have to use - Markdown syntax for it. + After that, we can include our release notes. You have to use Markdown syntax for it.

    - Releases 1 + Releases 1

    - Below that, you'll see the list of files GitHub will include in - the release. By default, it will include all the source code up to - that point in time, but you can add other files like binaries. + Below that, you'll see the list of files GitHub will include in the release. By default, it will include + all the source code up to that point in time, but you can add other files like binaries.


    - If your release is a pre-release (maybe your software is not - stable yet) you can mark it as a pre-release. When done, just - click on the Publish release button. + If your release is a pre-release (maybe your software is not stable yet) you can mark it as a pre-release. + When done, just click on the Publish release button.

    - Releases 2 + Releases 2

    - You'll be redirected to the releases panel. Here you can see all - your releases and their notes. On the left-hand side, you can see - the commit based on which the release was done. If you click on - Compare you can compare the state of your code at - different releases. + You'll be redirected to the releases panel. Here you can see all your releases and their notes. On the + left-hand side, you can see the commit based on which the release was done. If you click on + Compare you can compare the state of your code at different releases.


    - Next to your user name and the date on the central panel, GitHub - will show you the number of commits that were pushed to that - branch since that release. Currently is not showing anything - because there aren't any new commits. + Next to your user name and the date on the central panel, GitHub will show you the number of commits that + were pushed to that branch since that release. Currently is not showing anything because there aren't any + new commits.


    - Finally, on the right-hand side, you can choose to - Edit or Delete the release. + Finally, on the right-hand side, you can choose to Edit or Delete the release.

    @@ -120,9 +98,7 @@

    Releases

    - + + diff --git a/pages/054/sharing_branches.html b/pages/054/sharing_branches.html index cca423f..8e13dc3 100644 --- a/pages/054/sharing_branches.html +++ b/pages/054/sharing_branches.html @@ -1,16 +1,14 @@ + - + Sharing branches +
    @@ -30,19 +28,16 @@

    Sharing branches

    - By default, the branches we create locally, stay local. If we try - to push a local branch onto the remote repository, Git will throw - an error saying that - the current branch has no upstream branch. If we run + By default, the branches we create locally, stay local. If we try to push a local branch onto the remote + repository, Git will throw an error saying that + the current branch has no upstream branch. If we run

    git branch -vv

    - Git will show us our local and remote tracking branches, and we - can see which ones have an upstream and which ones don't. + Git will show us our local and remote tracking branches, and we can see which ones have an upstream and + which ones don't.


    You can see all remote tracking branches by running

    @@ -51,47 +46,34 @@

    Sharing branches

    - Sharing branches 1 + Sharing branches 1
    - Sharing branches 2 + Sharing branches 2

    - To link a local branch to a remote branch, the first time we push, - we have to run + To link a local branch to a remote branch, the first time we push, we have to run

    git push -u remote branch_name

    where -u is the short version of - --set-upstream, - remote is the name of the remote - repository we want to push to, and - branch_name is the name of the - branch. If we want to push to the GitHub repository, then - remote should be set to - origin. + --set-upstream, remote is the name of + the remote repository we want to push to, and branch_name is the name of + the branch. If we want to push to the GitHub repository, then remote + should be set to origin.

    - Notice that, in this case, we pushed the branch, without anything - new to commit. We just used the push command to tell GitHub that - there's a new pointer that we are going to be keeping track of. + Notice that, in this case, we pushed the branch, without anything new to commit. We just used the push + command to tell GitHub that there's a new pointer that we are going to be keeping track of.


    We can see this by checking the log with

    @@ -108,80 +90,55 @@

    Sharing branches

    - Sharing branches 3 + Sharing branches 3
    - Sharing branches 4 + Sharing branches 4

    - From now on, whenever we want to push local commits onto the - remote tracking branch, we just use the - git push command, the same as we - did with the master branch. + From now on, whenever we want to push local commits onto the remote tracking branch, we just use the + git push command, the same as we did with the master branch.


    - When we push, Git will tell GitHub to store our commits and to - move the remote feature pointer to - the new commit. It will also update the status of the remote - tracking branch on our local repository. + When we push, Git will tell GitHub to store our commits and to move the remote + feature pointer to the new commit. It will also update the status of the + remote tracking branch on our local repository.

    - The same holds true for mergers. Once you are done working locally - and merge your changes onto the local master branch, you can - simply push, and Git and GitHub will sync up and move the pointers - accordingly (assuming no one else pushed to the remote between the - time you pushed the branch and the time you are trying to push the - merge. If that is the case, there might be conflicts for you to - resolve). + The same holds true for mergers. Once you are done working locally and merge your changes onto the local + master branch, you can simply push, and Git and GitHub will sync up and move the pointers accordingly + (assuming no one else pushed to the remote between the time you pushed the branch and the time you are + trying to push the merge. If that is the case, there might be conflicts for you to resolve).

    - Sharing branches 5 + Sharing branches 5
    - Sharing branches 6 + Sharing branches 6

    - At some point, once you are done and merged your changes, you're - going to need to delete your branch. To delete the remote branch, - we run + At some point, once you are done and merged your changes, you're going to need to delete your branch. To + delete the remote branch, we run

    git push -d remote branch_name

    - But our local branch is still "linked" to the remote (it's - not...that's why Git is telling us that the remote is gone and - it's not showing up on our list of remote tracking branches, but - the local branch still thinks it's there). Just remember to delete - local branches too by running + But our local branch is still "linked" to the remote (it's not...that's why Git is telling us that the + remote is gone and it's not showing up on our list of remote tracking branches, but the local branch still + thinks it's there). Just remember to delete local branches too by running

    git branch -d branch_name @@ -191,56 +148,39 @@

    Sharing branches

    - When collaborating on a branch, any person can create the remote - branch from their local repository and push it like we just saw. - Another way is to create them directly on GitHub. + When collaborating on a branch, any person can create the remote branch from their local repository and + push it like we just saw. Another way is to create them directly on GitHub.


    - All you have to do is to click on the button that says - main and type the name of the new branch. When you press - Enter, GitHub will create the new branch. + All you have to do is to click on the button that says main and type the name of the new branch. + When you press Enter, GitHub will create the new branch.

    - Sharing branches 7 + Sharing branches 7
    - Sharing branches 8 + Sharing branches 8

    - At this point, our local Git repository has no idea that a new - branch was created on the remote repository. If we pull changes - from the remote, Git will create a new remote tracking branch, but - not a local branch. To do that we run + At this point, our local Git repository has no idea that a new branch was created on the remote + repository. If we pull changes from the remote, Git will create a new remote tracking branch, but not a + local branch. To do that we run

    - - git switch -C branch_name remote/branch_name - + git switch -C branch_name remote/branch_name

    - where branch_name is the name of - our local branch and - remote/branch_name is the name of - the remote and the name of the - branch that we wish to track in - that remote. To make this a - little bit more clear, take a look at the Git Bash image. Here - what we are telling Git that the local branch called - bugfix should be paired with the - remote tracking branch + where branch_name is the name of our local branch and + remote/branch_name is the name of the + remote and the name of the branch that + we wish to track in that remote. To make this a little bit more clear, + take a look at the Git Bash image. Here what we are telling Git that the local branch called + bugfix should be paired with the remote tracking branch origin/bugfix.

    @@ -248,36 +188,29 @@

    Sharing branches

    - At some point, you and your teammates are going to finish working - on that branch. Someone should now remove that branch from the - origin (and his/her local). If you are in charge of doing it, it's - just as what we saw before. + At some point, you and your teammates are going to finish working on that branch. Someone should now + remove that branch from the origin (and his/her local). If you are in charge of doing it, it's just as + what we saw before.


    - If it's not you who's in charge of deleting the remote branch - then: first, remember to switch to master on your local repository - and bring in the changes with a pull. This will sync up your local - repository. It should now show the merge commit your teammate did - before deleting the remote branch. + If it's not you who's in charge of deleting the remote branch then: first, remember to switch to master on + your local repository and bring in the changes with a pull. This will sync up your local repository. It + should now show the merge commit your teammate did before deleting the remote branch.


    - Second, delete your local branch by running - git branch -d branch_name just as - before. If you now check your remote tracking branches, you'll see - that the remote is still there. You need to prune it. To do so, - run + Second, delete your local branch by running git branch -d branch_name + just as before. If you now check your remote tracking branches, you'll see that the remote is still there. + You need to prune it. To do so, run

    git remote prune origin

    - Notice that the above command does not mention any particular - remote tracking branch. This is because it will get rid of all - branches with no upstream set. To make sure everything went OK, - run git branch -r, and the remote - tracking branch should be gone now. + Notice that the above command does not mention any particular remote tracking branch. This is because it + will get rid of all branches with no upstream set. To make sure everything went OK, run + git branch -r, and the remote tracking branch should be gone now.

    @@ -286,9 +219,7 @@

    Sharing branches

    - + + diff --git a/pages/055/pull_requests.html b/pages/055/pull_requests.html index 04397a7..4dbb1bd 100644 --- a/pages/055/pull_requests.html +++ b/pages/055/pull_requests.html @@ -1,16 +1,14 @@ + - + Pull requests +
    @@ -32,11 +30,9 @@

    Pull requests

    - A Pull Request (from now on, PR) is a way of opening a - discussion on a repository so that we can get feedback from other - team members on our code. In many organizations, opening PRs to - merge code into production or staging branches, and reviewing - other's people code is mandatory, even for the most senior + A Pull Request (from now on, PR) is a way of opening a discussion on a repository so that we can + get feedback from other team members on our code. In many organizations, opening PRs to merge code into + production or staging branches, and reviewing other's people code is mandatory, even for the most senior developers.

    @@ -44,296 +40,205 @@

    Pull requests

    - To see a scenario, let's suppose we just created a new commit on a - branch called bugfix and we pushed - it to the remote repository. If we now go to GitHub, we'll see the - message to create a PR. To start creating a PR, click on it. - Alternatively, you can go to the Pull Requests tab and start it - from there. + To see a scenario, let's suppose we just created a new commit on a branch called + bugfix and we pushed it to the remote repository. If we now go to GitHub, + we'll see the message to create a PR. To start creating a PR, click on it. Alternatively, you can go to + the Pull Requests tab and start it from there.

    - Pull requests 1 + Pull requests 1

    - You'll see a screen like the one below. First, we need to select - two branches. The base branch is the branch that we want - to merge our code into (here we'll choose main), our - compare branch is the branch that has the code we want to - merge into the base branch (in this case, I called the - branch bugfix). Next to the branch selectors, GitHub is telling us - that this branch can be merged without generating conflicts. This - is will not always be the case. If GitHub tells us that there are - conflicts that will have to be resolved that's OK, first our code - needs to be approved by our teammates anyway. + You'll see a screen like the one below. First, we need to select two branches. The base branch is + the branch that we want to merge our code into (here we'll choose main), our compare branch is + the branch that has the code we want to merge into the base branch (in this case, I called the + branch bugfix). Next to the branch selectors, GitHub is telling us that this branch can be merged without + generating conflicts. This will not always be the case. If GitHub tells us that there are conflicts that + will have to be resolved, that's OK, first our code needs to be approved by our teammates anyway.


    - Below that we can see the summary of changes. GitHub is telling us - that this PR will include 1 commit, with changes to 1 file. After - that, it shows us a graph of the involved commits. At the bottom - we can see the diffs for the different files (you can toggle the - views by pressing the Unified and Split buttons on the right). - When you are done reviewing this page, click on - Create pull request. + Below that we can see the summary of changes. GitHub is telling us that this PR will include 1 commit, + with changes to 1 file. After that, it shows us a graph of the involved commits. At the bottom we can see + the diffs for the different files (you can toggle the views by pressing the Unified and Split buttons on + the right). When you are done reviewing this page, click on Create pull request.

    - Pull requests 2 + Pull requests 2

    - In this new screen we need to first enter the PR's title. Because - this PR has only 1 commit, GitHub used the commit message as a PR - title. Usually you should change it to something more meaningful, - related to the task at hand (like feature name or bugfix and the - ID of the bugfix task). + In this new screen we need to first enter the PR's title. Because this PR has only 1 commit, GitHub used + the commit message as a PR title. Usually you should change it to something more meaningful, related to + the task at hand (like feature name or bugfix and the ID of the bugfix task).


    - In the details section of the PR you can write whatever you want. - Usually we list the changes or functions that were implemented - plus a short description of what they do. If there's any part of - your code that you want your teammates to pay special attention - to, this is where you should include that. When ready, click on - the Create pull request button. + In the details section of the PR you can write whatever you want. Usually we list the changes or functions + that were implemented plus a short description of what they do. If there's any part of your code that you + want your teammates to pay special attention to, this is where you should include that. When ready, click + on the Create pull request button.

    - Pull requests 3 + Pull requests 3

    - Now, if a reviewer was not assigned automatically, you need to - assign one. You can assign more than one too. The yellow dot next - to each reviewer's name indicates that they are still to respond - to the review request. + Now, if a reviewer was not assigned automatically, you need to assign one. You can assign more than one + too. The yellow dot next to each reviewer's name indicates that they are still to respond to the review + request.


    - From now on I'll be changing roles in this demo playing the role - of the creator of the PR and the reviewer, but I'll always use the - pronoun you since in the real world you'll have to do both: - sometimes you'll be the creator of the PR (when you are sharing - your code with your teammates and need someone to review it), and - sometimes you'll be the reviewer (when another teammate is - submitting code and asking that you review it). When playing the - PR creator's role the screen will be in dark theme. When playing - the role of the reviewer it will be in light theme. + From now on I'll be changing roles in this demo playing the role of the creator of the PR and the + reviewer, but I'll always use the pronoun you since in the real world you'll have to do both: sometimes + you'll be the creator of the PR (when you are sharing your code with your teammates and need someone to + review it), and sometimes you'll be the reviewer (when another teammate is submitting code and asking that + you review it). When playing the PR creator's role the screen will be in dark theme. When playing the role + of the reviewer it will be in light theme.

    - Pull requests 4 + Pull requests 4
    - Pull requests 5 + Pull requests 5

    - When someone asks for their code to be reviewed by you, GitHub - will send you an email. Upon logging into GitHub you'll see a - message that says that a teammate requested a review from you. - Click on the Add your review button. + When someone asks for their code to be reviewed by you, GitHub will send you an email. Upon logging into + GitHub you'll see a message that says that a teammate requested a review from you. Click on the + Add your review button.

    - You can now add comments to every and any line of code you think - needs one. When you hover over a line, a blue plus sign will - appear. To add a comment click on it. + You can now add comments to every and any line of code you think needs one. When you hover over a line, a + blue plus sign will appear. To add a comment click on it.

    - Pull requests 6 + Pull requests 6
    - Pull requests 7 + Pull requests 7
    - Pull requests 8 + Pull requests 8

    - After adding all of your comments, click on the - Review changes button in the top-right corner. Here you - can add a general message and approve, comment, or request changes - from the PR owner (the teammate who submitted it). + After adding all of your comments, click on the Review changes button in the top-right corner. + Here you can add a general message and approve, comment, or request changes from the PR owner (the + teammate who submitted it).

    - Let's go back to supposing that you are the person who created the - PR now. When the reviewer submits the review, you'll get an email - from GitHub saying that your code has been reviewed. Since in this - case changes were requested, you'll see a red icon next to the - reviewer’s name. + Let's go back to supposing that you are the person who created the PR now. When the reviewer submits the + review, you'll get an email from GitHub saying that your code has been reviewed. Since in this case + changes were requested, you'll see a red icon next to the reviewer's name.


    - Next, you'll go back to the code, implement the requested changes - (if you agree with them of course), and push the new commit onto - the remote repository. Now you can request a new review by - pressing the arrows next to the red icon. + Next, you'll go back to the code, implement the requested changes (if you agree with them of course), and + push the new commit onto the remote repository. Now you can request a new review by pressing the arrows + next to the red icon.

    - Pull requests 9 + Pull requests 9
    - Pull requests 10 + Pull requests 10

    - Back in the reviewer's role. You received an email from your - teammate saying that there's a new version of the code. You review - it again and since you are now OK with the code, you click on the - Viewed button. Now you submit a new review, this time - approving the changes. + Back in the reviewer's role. You received an email from your teammate saying that there's a new version of + the code. You review it again and since you are now OK with the code, you click on the Viewed + button. Now you submit a new review, this time approving the changes.

    - The person who submitted the PR will now see a green check mark - next to the reviewer's name. So now it's time to merge the PR onto - the base branch. + The person who submitted the PR will now see a green check mark next to the reviewer's name. So now it's + time to merge the PR onto the base branch.

    - Pull requests 11 + Pull requests 11
    - Pull requests 12 + Pull requests 12

    - Back in the PR's discussion panel you'll see a - Merge pull request at the bottom. Who should merge is - something that depends on the type of project and the culture and - rules of the organization. Some prefer that a person other than - the one who opened the PR merges it, some prefer the person who - created it to merge it. Just follow the rules and customs of your - organization. + Back in the PR's discussion panel you'll see a Merge pull request at the bottom. Who should merge + is something that depends on the type of project and the culture and rules of the organization. Some + prefer that a person other than the one who opened the PR merges it, some prefer the person who created it + to merge it. Just follow the rules and customs of your organization.


    - To merge, all you have to do is select the type of merge and click - on the merge button. + To merge, all you have to do is select the type of merge and click on the merge button.

    - Once done, don't forget to delete the branch. To delete the remote - branch you can just click on delete branch. To delete the local - branch on your computer, remember to first pull, switch to main, - and then delete and prune. + Once done, don't forget to delete the branch. To delete the remote branch you can just click on delete + branch. To delete the local branch on your computer, remember to first pull, switch to main, and then + delete and prune.


    - If you delete a branch by mistake, don't worry. Once you click on - the Delete branch button, it'll change to - Restore branch. + If you delete a branch by mistake, don't worry. Once you click on the Delete branch button, it'll + change to Restore branch.

    - Pull requests 13 + Pull requests 13
    - Pull requests 14 + Pull requests 14

    - As a side note, if during the PR process conflicts with the - base branch appear, you'll see this message on the PR - panel. You can resolve the conflict the same way as we saw before - using VS Code, or you can click on the - Resolve conflicts button on GitHub. Either way you do it, - the conflict is resolved the same way and the interface is pretty - much the same. + As a side note, if during the PR process conflicts with the base branch appear, you'll see this + message on the PR panel. You can resolve the conflict the same way as we saw before using VS Code, or you + can click on the Resolve conflicts button on GitHub. Either way you do it, the conflict is + resolved the same way and the interface is pretty much the same.

    @@ -342,9 +247,7 @@

    Pull requests

    - + + diff --git a/pages/056/github_issues.html b/pages/056/github_issues.html index cfcd880..19c7084 100644 --- a/pages/056/github_issues.html +++ b/pages/056/github_issues.html @@ -1,16 +1,14 @@ + - + GitHub issues +
    @@ -32,160 +30,107 @@

    GitHub issues

    - GitHub issues are a tool for collaboration. We can use issues to - document bugs or to start discussions with our team. Every issue - needs a clear title and a description of what the issue is about. - Also, on the right-hand side menu, we can assign issues to people - (or to ourselves), label issues, assign them as parts of projects, - or milestones. We can also link issues with PRs. Issues that are - linked to PRs will be closed when the PR is merged. + GitHub issues are a tool for collaboration. We can use issues to document bugs or to start discussions + with our team. Every issue needs a clear title and a description of what the issue is about. Also, on the + right-hand side menu, we can assign issues to people (or to ourselves), label issues, assign them as parts + of projects, or milestones. We can also link issues with PRs. Issues that are linked to PRs will be closed + when the PR is merged.

    - GitHub issues 1 + GitHub issues 1

    - Here I've created an example issue. Once someone creates an issue, - others con post to the conversation or share their reactions to - what is being said. + Here I've created an example issue. Once someone creates an issue, others con post to the conversation or + share their reactions to what is being said.


    - If we mention an issue in a commit message, it will be shown on - the issue thread. + If we mention an issue in a commit message, it will be shown on the issue thread.


    - GitHub issues 3 + GitHub issues 3
    - GitHub issues 2 + GitHub issues 2
    - GitHub issues 4 + GitHub issues 4

    - Alternatively, if we think that the issue can be closed after we - push certain changes, we can do so from the commit message. In - order to do so, our commit message must include the pattern - keyword #issue. The valid - keywords are: close, closes, closed, fix, fixes, fixed, resolve, - resolves, resolved. We can close multiple issues with one commit - by using commas to separate them. If we want to include a more - comprehensive message we can do so with a semicolon. + Alternatively, if we think that the issue can be closed after we push certain changes, we can do so from + the commit message. In order to do so, our commit message must include the pattern + keyword #issue. The valid keywords are: close, closes, closed, fix, + fixes, fixed, resolve, resolves, resolved. We can close multiple issues with one commit by using commas to + separate them. If we want to include a more comprehensive message we can do so with a semicolon.

    - - git commit -m "fixes #1, closes #2, resolves #3; Commit message" - + git commit -m "fixes #1, closes #2, resolves #3; Commit message"

    - GitHub issues 5 + GitHub issues 5

    - Notice that, even though this was our first issue, GitHub gave it - a number two. That is because issues and PRs use the same counter. - Every time we create a new issue or PR, the counter moves up by - one. + Notice that, even though this was our first issue, GitHub gave it a number two. That is because issues and + PRs use the same counter. Every time we create a new issue or PR, the counter moves up by one.

    - I've created a new issue with the bug label. In the label - tab, we can see all the default labels that all GitHub - repositories come with. We can edit these labels or create new - ones. On the labels tab GitHub will also show us the number of - open issues or PRs that have that label. + I've created a new issue with the bug label. In the label tab, we can see all the default labels + that all GitHub repositories come with. We can edit these labels or create new ones. On the labels tab + GitHub will also show us the number of open issues or PRs that have that label.


    We can assign more than one label per issue.

    - GitHub issues 6 + GitHub issues 6
    - GitHub issues 7 + GitHub issues 7

    - A related concept to that of issues is milestones. We use - milestones for tasks that are composed of more than one issue. To - create milestones go to the milestones tab (next to the issues - tab). Milestones need a title and can optionally have a due date - and a description. + A related concept to that of issues is milestones. We use milestones for tasks that are composed + of more than one issue. To create milestones go to the milestones tab (next to the issues tab). Milestones + need a title and can optionally have a due date and a description.

    - Once we've created a milestone, we can also create issues and - assign them to the corresponding milestone. We can also create a - label that refers to this milestone. + Once we've created a milestone, we can also create issues and assign them to the corresponding milestone. + We can also create a label that refers to this milestone.

    - GitHub issues 8 + GitHub issues 8
    - GitHub issues 9 + GitHub issues 9

    - As we work on the new milestone and close issues, GitHub will - update the progress of our milestone. + As we work on the new milestone and close issues, GitHub will update the progress of our milestone.

    @@ -194,9 +139,7 @@

    GitHub issues

    - + + diff --git a/pages/057/forks.html b/pages/057/forks.html index c0fb6af..51ac1a0 100644 --- a/pages/057/forks.html +++ b/pages/057/forks.html @@ -1,16 +1,14 @@ + - + Forks +
    @@ -34,15 +32,12 @@

    Forks

    - So far, all that we've done included working with a repository to - which we have push access. Suppose now that we've found an - Open-Source project to which we want to collaborate. These kinds - of projects use the Integration-Manager Workflow that we saw - before. Therefore, we don't have push access to them. This is why, - when contributing to open source projects, the first thing we need - to do is to fork the project repository. This will create a new - repository that we own and that has a copy of all the code and - files in the original repository. + So far, all that we've done included working with a repository to which we have push access. Suppose now + that we've found an Open-Source project to which we want to collaborate. These kinds of projects use the + Integration-Manager Workflow that we saw before. Therefore, we don't have push access to them. This is + why, when contributing to open source projects, the first thing we need to do is to fork the project + repository. This will create a new repository that we own and that has a copy of all the code and files in + the original repository.

    @@ -55,31 +50,25 @@

    Forks

    - The new repository will have the same name as the original one - (though we can change it), and a legend will be displayed below - our repository's name saying from which repository it was forked. - Since this new repository is ours, we can push changes to it. + The new repository will have the same name as the original one (though we can change it), and a legend + will be displayed below our repository's name saying from which repository it was forked. Since this new + repository is ours, we can push changes to it.


    - The first thing you need to do is to clone this new repository to - your local machine so that you can work on it. Then, create a new - branch where you will work on your proposed changes. + The first thing you need to do is to clone this new repository to your local machine so that you can work + on it. Then, create a new branch where you will work on your proposed changes.

    - Most open-source projects welcome contributions as long as they - are done following their contribution guide. Just as - README.md and LICENSE.md are special files to - GitHub, so too are files like CONTRIBUTION_GUIDE.md (or - some variation of the name), CODE_OF_CONDUCT.md, and - templates for issues and PRs. You can usually find all this - information in either the root directory of a repository, a - special folder set for this, or a Wiki page (under the Wiki tab of - the repository). + Most open-source projects welcome contributions as long as they are done following their contribution + guide. Just as README.md and LICENSE.md are special files to GitHub, so too are files + like CONTRIBUTION_GUIDE.md (or some variation of the name), CODE_OF_CONDUCT.md, and + templates for issues and PRs. You can usually find all this information in either the root directory of a + repository, a special folder set for this, or a Wiki page (under the Wiki tab of the repository).

    @@ -92,9 +81,8 @@

    Forks

    - Once you've made all your changes, push them onto your forked - repository. Remember that the first time you push a new branch, - you need to set the upstream with + Once you've made all your changes, push them onto your forked repository. Remember that the first time you + push a new branch, you need to set the upstream with

    git push -u remote_name branch_name @@ -104,8 +92,7 @@

    Forks

    - Once you are done making and pushing all your changes, go back to - GitHub and start a new PR. + Once you are done making and pushing all your changes, go back to GitHub and start a new PR.

    @@ -118,32 +105,29 @@

    Forks

    - The only difference between this PR and the PRs we saw earlier, is - that now you are going to be comparing the new branch on your - repository, with a branch (in this case main) from the - original repository. + The only difference between this PR and the PRs we saw earlier, is that now you are going to be comparing + the new branch on your repository, with a branch (in this case main) from the original + repository.

    - After clicking on the Create pull request button, GitHub - will create it IN THE ORIGINAL REPOSITORY. There we can - start a conversation with the maintainers of the project. They - might request additional changes from us, or to expand our - explanation or documentation of what our code does. + After clicking on the Create pull request button, GitHub will create it + IN THE ORIGINAL REPOSITORY. There we can start a conversation with the maintainers of the + project. They might request additional changes from us, or to expand our explanation or documentation of + what our code does.


    - But notice that we are not allowed to merge the PR into the - original repository. Only maintainers can do so. + But notice that we are not allowed to merge the PR into the original repository. Only maintainers can do + so.


    - Keep in mind that if we push more changes onto the branch that - we've created while the PR is in progress, these changes will - impact not only the branch in our fork but the PR too. + Keep in mind that if we push more changes onto the branch that we've created while the PR is in progress, + these changes will impact not only the branch in our fork but the PR too.

    @@ -156,13 +140,11 @@

    Forks

    - Whenever you find yourself in the position of the maintainer, - merging this type of PR is no different than merging any other PR. - Once that you and the contributor have finished discussing the - changes and you are ready to merge them, just click on the - Merge pull request button. If there are any conflicts - you'll have to resolve them or ask the contributor to make a new - push and that solves them, before clicking on the merge button. + Whenever you find yourself in the position of the maintainer, merging this type of PR is no different than + merging any other PR. Once that you and the contributor have finished discussing the changes and you are + ready to merge them, just click on the Merge pull request button. If there are any conflicts + you'll have to resolve them or ask the contributor to make a new push and that solves them, before + clicking on the merge button.


    Once the merger is done, the PR will be closed.

    @@ -171,19 +153,16 @@

    Forks

    - Now that your PR has been merged into the original repository, if - you go back to your forked repository on GitHub, you'll notice a - message saying that your fork is an x number of commits behind the - base repository. This happens because even though our fork knows - about the existence of the original repository, GitHub does not - automatically keep them in sync. We need to do this manually. + Now that your PR has been merged into the original repository, if you go back to your forked repository on + GitHub, you'll notice a message saying that your fork is an x number of commits behind the base + repository. This happens because even though our fork knows about the existence of the original + repository, GitHub does not automatically keep them in sync. We need to do this manually.


    - Therefore, we need to be able to pull the new changes from the - base repository onto our local repository of the forked - repository. To do so, we need to set up a new reference between - our local repository and the original remote upstream. + Therefore, we need to be able to pull the new changes from the base repository onto our local repository + of the forked repository. To do so, we need to set up a new reference between our local repository and the + original remote upstream.

    @@ -200,25 +179,18 @@

    Forks

    git remote -v

    - Git will show us our current remotes and the URL from where they - fetch or push to. When we clone a repository onto our machine, Git - will automatically create the - origin remote. In this case, this - remote refers to our forked repository. To add a new one that - points to the original upstream repository we run + Git will show us our current remotes and the URL from where they fetch or push to. When we clone a + repository onto our machine, Git will automatically create the origin + remote. In this case, this remote refers to our forked repository. To add a new one that points to the + original upstream repository we run

    - - git remote add remote_name remote_url - + git remote add remote_name remote_url

    - Here remote_name can be anything - you want, but it's most common to call them either - base or - upstream. The - remote_url we are referring to is - the URL of the original repository. + Here remote_name can be anything you want, but it's most common to call + them either base or upstream. The + remote_url we are referring to is the URL of the original repository.

    @@ -226,9 +198,7 @@

    Forks

    If you want to change the name of a remote, just run

    - - git remote rename current_name new_name - + git remote rename current_name new_name

    Similarly, to remove a remote, we run

    @@ -239,37 +209,29 @@

    Forks

    - Now we can bring in the new changes in the original repository by - using the fetch or - pull commands. Remember that when - we fetch or - pull we need to supply the name - of the remote from where Git is - supposed to fetch or - pull. When we omit this, Git - assumes that we want to use the - origin. But in this case, we must - include it, since we want Git to bring in changes that are not in - our origin but in a different - remote. So, we run + Now we can bring in the new changes in the original repository by using the + fetch or pull commands. Remember that + when we fetch or pull we need to supply + the name of the remote from where Git is supposed to + fetch or pull. When we omit this, Git + assumes that we want to use the origin. But, in this case, we must + include it, since we want Git to bring in changes that are not in our + origin but in a different remote. So, we + run

    git fetch remote_name

    - Notice that now we have a new branch called - base/main. If we take a look at our - log, we can see that this branch is ahead of our local - main branch. So we need to merge - base/main onto - main. Luckily, there's nothing - special about this merge. + Notice that now we have a new branch called base/main. If we take a look at + our log, we can see that this branch is ahead of our local main branch. So + we need to merge base/main onto main. Luckily, + there's nothing special about this merge.


    - Since our local repository is now in sync with the original - repository, we can push these changes into our forked repository - and it too will be up-to-date with the original one. + Since our local repository is now in sync with the original repository, we can push these changes into our + forked repository and it too will be up-to-date with the original one.

    @@ -279,30 +241,23 @@

    Forks

    - One thing you may have noticed is that we never merged the branch - where we made our proposed changes onto the main branch of our - repository. You can do so if you want. But our changes got brought - into our local and remote main branches via the pull (or fetch) - from the original repository in its post-PR state. So they are - there already. + One thing you may have noticed is that we never merged the branch where we made our proposed changes onto + the main branch of our repository. You can do so if you want. But our changes got brought into our local + and remote main branches via the pull (or fetch) from the original repository in its post-PR state. So + they are there already.


    - If you decide to go ahead and merge anyway, keep in mind that the - maintainer of the original repository may have changed our code - when merging (maybe he/she fixed some merge conflicts for - example). By merging our branch onto main we may be reintroducing - those merge conflicts. So it's usually best to just throw them - away (unless our changes were rejected by the maintainer but we'd - still like to keep them). + If you decide to go ahead and merge anyway, keep in mind that the maintainer of the original repository + may have changed our code when merging (maybe he/she fixed some merge conflicts for example). By merging + our branch onto main we may be reintroducing those merge conflicts. So it's usually best to just throw + them away (unless our changes were rejected by the maintainer but we'd still like to keep them).


    - A final comment. When contributing to open source projects is - usually customary that before we send a PR, we pull in the most - recent changes from the original repository first, merge the main - branch onto our proposed changes, and then start a PR. This - decreases the number of merge conflicts that could happen when + A final comment. When contributing to open source projects is usually customary that before we send a PR, + we pull in the most recent changes from the original repository first, merge the main branch onto our + proposed changes, and then start a PR. This decreases the number of merge conflicts that could happen when merging our PR into the original repository.

    @@ -312,9 +267,7 @@

    Forks

    - + + diff --git a/pages/058/rewriting_history.html b/pages/058/rewriting_history.html index c90734b..8ae7c24 100644 --- a/pages/058/rewriting_history.html +++ b/pages/058/rewriting_history.html @@ -1,16 +1,14 @@ + - + Rewriting History +
    @@ -30,88 +28,66 @@

    Rewriting History

    - In Git we can rewrite the history of our repository. But this must - be handled with care. The ultimate goal is to have a clean and - readable history that allows us to understand how our project - evolved and makes it easy to move back and forth between versions. + In Git we can rewrite the history of our repository. But this must be handled with care. The ultimate goal + is to have a clean and readable history that allows us to understand how our project evolved and makes it + easy to move back and forth between versions.


    - To ensure this goal, our commits should not be too large, nor too - small, and with meaningful messages that clearly explain what - changes in that commit (what was delete, added, or modified). They - should focus on one task at a time. So, for example, if - implementing a new feature requires completing three steps, then - there should be a branch for that feature. In this branch, we - should have three commits, each representing the completion of one - task. If while we are working on a task we find a bug or a typo, - we should create a new task and work on it on its own branch and - commits. + To ensure this goal, our commits should not be too large, nor too small, and with meaningful messages that + clearly explain what changes in that commit (what was delete, added, or modified). They should focus on + one task at a time. So, for example, if implementing a new feature requires completing three steps, then + there should be a branch for that feature. In this branch, we should have three commits, each representing + the completion of one task. If while we are working on a task we find a bug or a typo, we should create a + new task and work on it on its own branch and commits.


    - If the new feature is too large or complex, then it needs to be - broken down into smaller iterations. Focus on making a basic - functionality, and then iterate adding extra functionalities one - at a time. Likewise, if a task is too complex, then it should be - broken into sub-tasks and each sub-task should be developed in its - own branch. Don't be afraid of your history looking like the one - below. Use branches!! That's what they are there for!! + If the new feature is too large or complex, then it needs to be broken down into smaller iterations. Focus + on making a basic functionality, and then iterate adding extra functionalities one at a time. Likewise, if + a task is too complex, then it should be broken into sub-tasks and each sub-task should be developed in + its own branch. Don't be afraid of your history looking like the one below. Use branches!! That's what + they are there for!!

    - Rewriting history 1 + Rewriting history 1

    - Having said that, it is not always easy (or even possible) to - maintain a clean history while working. This is where the tools - for rewriting history come into play. With them, we can squash - small and related commits into a single one, split large commits - into smaller ones (each of which should represent a separate logic - of changes). We can also use them to correct or improve commit - messages. We can drop or modify commits (for example, if you - forgot to include a file in a commit). + Having said that, it is not always easy (or even possible) to maintain a clean history while working. This + is where the tools for rewriting history come into play. With them, we can squash small and related + commits into a single one, split large commits into smaller ones (each of which should represent a + separate logic of changes). We can also use them to correct or improve commit messages. We can drop or + modify commits (for example, if you forgot to include a file in a commit).


    - But, rewriting the history of a repository can be dangerous. So, - there are two golden rules for rewriting history: + But, rewriting the history of a repository can be dangerous. So, there are two golden rules for rewriting + history:

    • - Always make sure that you know exactly what you are doing before - doing it. If you thought you knew how to do something and now - realize you didn't, or if you made a mistake while doing it and - you don't know how to fix it, stop what you are doing and, - before touching anything else, seek help. + Always make sure that you know exactly what you are doing before doing it. If you thought you knew how + to do something and now realize you didn't, or if you made a mistake while doing it and you don't know + how to fix it, stop what you are doing and, before touching anything else, seek help.
    • - NEVER REWRITE PUBLIC HISTORY. Public - history is everything that has already been shared with other - people. In essence, if it has been pushed onto a GitHub - repository, then don't change it. Remember that commits are - actually immutable. So when we rewrite history, what we are - actually doing is telling Git to throw away a commit, and - replace it with another (or others). If another person already - started working from where we left off, then our changes might - break their code. + NEVER REWRITE PUBLIC HISTORY. Public history is everything that has already + been shared with other people. In essence, if it has been pushed onto a GitHub repository, then don't + change it. Remember that commits are actually immutable. So when we rewrite history, what we are + actually doing is telling Git to throw away a commit, and replace it with another (or others). If + another person already started working from where we left off, then our changes might break their code.

    - This does not mean that rewriting history is a bad practice. In - fact, it's a good one. Just remember doing it before you push your - changes onto a public repository. This way you make sure that the - history of the project is clean and clear. + This does not mean that rewriting history is a bad practice. In fact, it's a good one. Just remember doing + it before you push your changes onto a public repository. This way you make sure that the history of the + project is clean and clear.

    @@ -120,9 +96,7 @@

    Rewriting History

    - + + diff --git a/pages/059/undoing_commits.html b/pages/059/undoing_commits.html index f9680cb..1c9bbd2 100644 --- a/pages/059/undoing_commits.html +++ b/pages/059/undoing_commits.html @@ -1,16 +1,14 @@ + - + Undoing commits +
    @@ -34,18 +32,13 @@

    Undoing commits

    - Suppose we have a repository that looks like the one on the image - and we want to undo the last commit (088455d). Since this - commit is only in our local repository, we use the + Suppose we have a repository that looks like the one on the image and we want to undo the last commit + (088455d). Since this commit is only in our local repository, we use the reset command.

    - Undoing commits 1 + Undoing commits 1
    @@ -53,100 +46,75 @@

    Undoing commits

    This command has three options that you should know about:

    • - --soft removes from the - repository only. This means that it undoes the - git commit action, but our - changes are still in the staging area. + --soft removes from the repository only. This means that it undoes the + git commit action, but our changes are still in the staging area.
    • - --mixed removes from the - repository and the staging area. This means that it undoes both - git commit and - git add action. Our changes - will still be in our working directory. + --mixed removes from the repository and the staging area. This means + that it undoes both git commit and + git add action. Our changes will still be in our working directory.
    • - --hard removes from the - repository, the staging area, and the working directory. This - means that we are getting rid of our work for good. + --hard removes from the repository, the staging area, and the working + directory. This means that we are getting rid of our work for good.
    - Undoing commits 2 + Undoing commits 2

    - When we reset commits we need to supply the target position for - the HEAD pointer. In this case, - since we are going to be working with the last commit, we should - tell Git that the target commit for the - HEAD pointer is the commit before - last. So we run + When we reset commits we need to supply the target position for the HEAD + pointer. In this case, since we are going to be working with the last commit, we should tell Git that the + target commit for the HEAD pointer is the commit before last. So we run

    git reset --soft HEAD~1

    - The last commit is now gone from our repository and we have - changes that have already been staged and are ready to be - committed. So it's as if we had never run - git commit that last time. + The last commit is now gone from our repository and we have changes that have already been staged and are + ready to be committed. So it's as if we had never run git commit that + last time.

    - If we instead want to remove changes from the repository and the - staging area, then we run + If we instead want to remove changes from the repository and the staging area, then we run

    git reset --mixed HEAD~1

    - The --mixed option is the - default, so we can omit it. Just as before, the commit is now gone - from the repository. But this time notice that the changes are in - the working directory only. They have not been staged. + The --mixed option is the default, so we can omit it. Just as before, the + commit is now gone from the repository. But this time notice that the changes are in the working directory + only. They have not been staged.

    - Undoing commits 3 + Undoing commits 3
    - Undoing commits 4 + Undoing commits 4

    - Lastly, if we want to remove changes from the repository, the - staging area, and the working directory, then we run + Lastly, if we want to remove changes from the repository, the staging area, and the working directory, + then we run

    git reset --hard HEAD~1

    - Notice that now, when we run - git status -s Git is staying that - there's nothing there. This is because we just deleted our changes - from everywhere. It's as if we had never written that code to - begin with. + Notice that now, when we run git status -s Git is staying that there's + nothing there. This is because we just deleted our changes from everywhere. It's as if we had never + written that code to begin with.

    @@ -155,9 +123,7 @@

    Undoing commits

    - + + diff --git a/pages/060/reverting_commits.html b/pages/060/reverting_commits.html index 4055e4c..da2e92e 100644 --- a/pages/060/reverting_commits.html +++ b/pages/060/reverting_commits.html @@ -1,16 +1,14 @@ + - + Reverting commits +
    @@ -34,49 +32,36 @@

    Reverting commits

    - If we have already shared our work with other people, then we - cannot rewrite its history. Other people may have already built - more features or fixed new bugs on top of our code and rewriting - the history of the project could break their work. For these - situations we use git revert. + If we have already shared our work with other people, then we cannot rewrite its history. Other people may + have already built more features or fixed new bugs on top of our code and rewriting the history of the + project could break their work. For these situations we use git revert.


    - Suppose we want to revert the - last commit. So we run + Suppose we want to revert the last commit. So we run

    git revert HEAD

    - Git will create a new commit after our - HEAD that undoes all changes done in - the HEAD commit. The message for - this commit will be Revert "original_commit_message". + Git will create a new commit after our HEAD that undoes all changes done in + the HEAD commit. The message for this commit will be + Revert "original_commit_message".


    - We can also revert earlier commits with - git revert HEAD~n where - n refers to the commit - n steps prior to HEAD. + We can also revert earlier commits with git revert HEAD~n where + n refers to the commit n steps prior to + HEAD.

    - Reverting commits 1 + Reverting commits 1
    - Reverting commits 2 + Reverting commits 2

    We can revert ranges of commits by running, for example

    @@ -84,56 +69,45 @@

    Reverting commits

    git revert HEAD~3..HEAD

    - With this, Git will revert all commits from - HEAD~2 to - HEAD. So, Git will not include the - oldest commit. When we revert a range of commits, Git will revert - them one by one, starting from HEAD. - At each commit, Git will open VS Code and ask us to supply a - commit message (or confirm the default one). + With this, Git will revert all commits from HEAD~2 to + HEAD. So, Git will not include the oldest commit. When we revert a range of + commits, Git will revert them one by one, starting from HEAD. At each + commit, Git will open VS Code and ask us to supply a commit message (or confirm the default one).


    - Because our last commit is HEAD, we - can omit it and run - git revert HEAD~3.. and Git will - start from the HEAD pointer. + Because our last commit is HEAD, we can omit it and run + git revert HEAD~3.. and Git will start from the + HEAD pointer.

    - When reverting a range of commits, is better to produce only one - revert commit. This will leave us with a cleaner history. To do - so, we run + When reverting a range of commits, is better to produce only one revert commit. This will leave us with a + cleaner history. To do so, we run

    git revert --no-commit HEAD~3..

    - With this, Git will figure out what changes need to be done, and - apply those changes to the staging area. We can review the changes - and then run + With this, Git will figure out what changes need to be done, and apply those changes to the staging area. + We can review the changes and then run

    git revert --continue

    - Git will open VS Code so that we can write our commit message. If - while reviewing the changes we realize that we don't want to go - ahead with the revert, we can run + Git will open VS Code so that we can write our commit message. If while reviewing the changes we realize + that we don't want to go ahead with the revert, we can run

    git revert --abort
    - Reverting commits 3 + Reverting commits 3
    @@ -141,9 +115,7 @@

    Reverting commits

    - + + diff --git a/pages/061/recovering_commits.html b/pages/061/recovering_commits.html index 7fb338f..f06be54 100644 --- a/pages/061/recovering_commits.html +++ b/pages/061/recovering_commits.html @@ -1,16 +1,14 @@ + - + Recovering commits +
    @@ -34,29 +32,19 @@

    Recovering commits

    - Sometimes you might make a mistake while resetting the - HEAD and erase a commit you did not - mean to erase. As an example, look at the Git Bash image. Here - I've used a reset hard to 6 commits before the - HEAD pointer. To recover everything, - we'll use the git reflog command. + Sometimes you might make a mistake while resetting the HEAD and erase a + commit you did not mean to erase. As an example, look at the Git Bash image. Here I've used a reset hard + to 6 commits before the HEAD pointer. To recover everything, we'll use the + git reflog command.

    - Recovering commits 1 + Recovering commits 1
    - Recovering commits 2 + Recovering commits 2

    To view the reflog, we run

    @@ -64,45 +52,34 @@

    Recovering commits

    git reflog

    - If we don't supply any other options, Git will show us how our - HEAD pointer has moved throughout - the history of our repository. Every entry in the log has a unique - identifier, starting from - HEAD@{0} (the last position of - the pointer) and moving up one each time the pointer moved. Next - to the identifier, there's a description of what happened in that - entry. The commit ID to the left is the commit to which the - pointer was pointing, after the operation in that entry. So, for - example, after the last operation (which was a reset) the pointer - is at commit af26a96. + If we don't supply any other options, Git will show us how our HEAD pointer + has moved throughout the history of our repository. Every entry in the log has a unique identifier, + starting from HEAD@{0} (the last position of the pointer) and moving up + one each time the pointer moved. Next to the identifier, there's a description of what happened in that + entry. The commit ID to the left is the commit to which the pointer was pointing, after the operation in + that entry. So, for example, after the last operation (which was a reset) the pointer is at commit + af26a96.

    - In this case, to recover our lost commits, we can reset the - HEAD pointer to commit - 3e3b5ed (the second entry in our reflog). To do this, we - run + In this case, to recover our lost commits, we can reset the HEAD pointer to + commit 3e3b5ed (the second entry in our reflog). To do this, we run

    git reset --hard 3e3b5ed

    - We could also use the entry identifier. In that case, we should - have used + We could also use the entry identifier. In that case, we should have used

    git reset --hast HEAD@{0}
    - Recovering commits 3 + Recovering commits 3
    @@ -112,16 +89,14 @@

    Recovering commits

    git reflog show pointer_name

    - and Git will show us its history. Remember that each branch is a - pointer in Git, so we could use it for branches. We can also use - reflogs with time indications. So, for example + and Git will show us its history. Remember that each branch is a pointer in Git, so we could use it for + branches. We can also use reflogs with time indications. So, for example

    git reflog master@{one.week.ago}

    - will show us where master was, one - week ago. + will show us where master was, one week ago.

    @@ -130,9 +105,7 @@

    Recovering commits

    - + + diff --git a/pages/062/amending_last_commit.html b/pages/062/amending_last_commit.html index f61ba76..d54e47c 100644 --- a/pages/062/amending_last_commit.html +++ b/pages/062/amending_last_commit.html @@ -1,16 +1,14 @@ + - + Amending the last commit +
    @@ -34,47 +32,35 @@

    Amending the last commit

    - Suppose we make a commit and then realize that we made a mistake. - If we haven't yet pushed that commit onto a remote repository, we - can make the new changes and then run + Suppose we make a commit and then realize that we made a mistake. If we haven't yet pushed that commit + onto a remote repository, we can make the new changes and then run

    git commit --amend

    - Git will open VS Code and we can write a new message or keep the - original one. If we already know that we want to change the - message, we can run + Git will open VS Code and we can write a new message or keep the original one. If we already know that we + want to change the message, we can run

    git commit --amend -m "New commit message"

    - Keep in mind that we are not really changing the last commit, we - are creating a new one and dropping the last one. So don't amend - commits that you have already pushed onto a remote repository. + Keep in mind that we are not really changing the last commit, we are creating a new one and dropping the + last one. So don't amend commits that you have already pushed onto a remote repository.

    - Amending the last commit 1 + Amending the last commit 1
    - Amending the last commit 2 + Amending the last commit 2

    - Amending also works if we forgot to include a file in the last - commit. Just stage the changes and then run + Amending also works if we forgot to include a file in the last commit. Just stage the changes and then run

    git commit --amend @@ -85,19 +71,13 @@

    Amending the last commit

    - If, on the other hand, we included a file that we shouldn't have, - then we can use a --mixed reset. - This will undo the last commit, and place all changes in our - working directory. We can now choose which files we want to - include and commit again. + If, on the other hand, we included a file that we shouldn't have, then we can use a + --mixed reset. This will undo the last commit, and place all changes in + our working directory. We can now choose which files we want to include and commit again.

    - Amending the last commit 3 + Amending the last commit 3
    @@ -105,9 +85,7 @@

    Amending the last commit

    - + + diff --git a/pages/063/amending_earlier_commits.html b/pages/063/amending_earlier_commits.html index 0903fa6..c0b86f9 100644 --- a/pages/063/amending_earlier_commits.html +++ b/pages/063/amending_earlier_commits.html @@ -1,16 +1,14 @@ + - + Amending earlier commits +
    @@ -32,77 +30,59 @@

    Amending earlier commits

    - Now suppose we want to amend a previous commit. To do this we need - to use interactive rebasing. Remember that with rebasing - we can replay a bunch of commits on top of other commits. The - interactive part of the name means that we want to give Git - instructions while doing it. + Now suppose we want to amend a previous commit. To do this we need to use interactive rebasing. + Remember that with rebasing we can replay a bunch of commits on top of other commits. The interactive part + of the name means that we want to give Git instructions while doing it.


    - As an example, suppose we want to amend commit 8441b05. - To do so, we need to supply its parent commit to Git. That is - 8527033. So we run + As an example, suppose we want to amend commit 8441b05. To do so, we need to supply its parent + commit to Git. That is 8527033. So we run

    git rebase -i 8527033
    - Amending earlier commits + Amending earlier commits

    - Git will open VS Code in a script that looks like the one below. - In this script we can tell Git which operation we want to do for - each commit. If you are using the GitLens extension then commits - will appear in the same order as they would when running - git log. So at the top you'll see - the latest commit and at the bottom the commit we want to edit. - Otherwise, at the top you'll see the commit that we want to edit - and, at the bottom, the latest commit in this branch. + Git will open VS Code in a script that looks like the one below. In this script we can tell Git which + operation we want to do for each commit. If you are using the GitLens extension then commits will appear + in the same order as they would when running git log. So at the top + you'll see the latest commit and at the bottom the commit we want to edit. Otherwise, at the top you'll + see the commit that we want to edit and, at the bottom, the latest commit in this branch.


    - For each commit you can give an instruction. For this demo, we'll - just edit one commit. So, we select the edit option from the - dropdown menu. + For each commit you can give an instruction. For this demo, we'll just edit one commit. So, we select the + edit option from the dropdown menu.

    - Amending earlier commits 2 + Amending earlier commits 2

    - When we close the VS Code window (or click on - Start Rebase if you are using GitLens) the rebase + When we close the VS Code window (or click on Start Rebase if you are using GitLens) the rebase operation will start.


    - Because we told Git that we wanted to edit commit - 8441b05, Git stopped at that commit so that we can make - our changes. We can amend this commit now. + Because we told Git that we wanted to edit commit 8441b05, Git stopped at that commit so that we + can make our changes. We can amend this commit now.


    - In this case, we are just making changes to one file, but we could - add or delete files if we needed to. When we are done, we stage - our changes and commit them by running + In this case, we are just making changes to one file, but we could add or delete files if we needed to. + When we are done, we stage our changes and commit them by running

    git commit --amend @@ -110,35 +90,24 @@

    Amending earlier commits

    just as we would if we were amending the last commit.

    - Amending earlier commits 3 + Amending earlier commits 3
    - Amending earlier commits 4 + Amending earlier commits 4

    - If we take a look at the log, we see that we now have two - branches. One with all the old commits that we are now rebasing - (at its tip you can see the - master pointer). The other branch is - the one that we are creating with the interactive rebase. + If we take a look at the log, we see that we now have two branches. One with all the old commits that we + are now rebasing (at its tip you can see the master pointer). The other + branch is the one that we are creating with the interactive rebase.


    - Because we told Git that we wanted to edit this commit, the - rebasing operation is waiting for us to tell it to continue. When - we do, Git will replay all the other commits involved in the - rebase on top of the new commit. + Because we told Git that we wanted to edit this commit, the rebasing operation is waiting for us to tell + it to continue. When we do, Git will replay all the other commits involved in the rebase on top of the new + commit.


    To continue with the rebase, we run

    @@ -150,37 +119,30 @@

    Amending earlier commits

    - Since at the start of the rebase we told Git that we only wanted - to edit that one commit, when we run continue, Git automatically - took care of the other commits. + Since at the start of the rebase we told Git that we only wanted to edit that one commit, when we run + continue, Git automatically took care of the other commits.


    - Once done rebasing all commits, Git moved the pointer of our - branch (in this case master) to the - tip of the new branch. + Once done rebasing all commits, Git moved the pointer of our branch (in this case + master) to the tip of the new branch.

    - Amending earlier commits 5 + Amending earlier commits 5

    - If at any pause during the rebase operation you decide that you - don't want to go through with it, you can run + If at any pause during the rebase operation you decide that you don't want to go through with it, you can + run

    git rebase --abort

    - and Git will restore everything to the state before starting the - rebase. + and Git will restore everything to the state before starting the rebase.

    @@ -189,9 +151,7 @@

    Amending earlier commits

    - + + diff --git a/pages/064/dropping_commits.html b/pages/064/dropping_commits.html index 0b9ebdc..d088288 100644 --- a/pages/064/dropping_commits.html +++ b/pages/064/dropping_commits.html @@ -1,16 +1,14 @@ + - + Dropping commits +
    @@ -34,27 +32,22 @@

    Dropping commits

    - Now suppose that we want to drop commit 1736531. To do - this, we'll use interactive rebasing. As always, we should start - our rebase process with the parent of that commit. + Now suppose that we want to drop commit 1736531. To do this, we'll use interactive rebasing. As + always, we should start our rebase process with the parent of that commit.


    - If we take a look at the content of that commit, we see that in - that commit we introduced a new file called terms.txt. - When we drop this commit we have two possible scenarios that we - need to be careful of. If a commit after that one touches that - file, and we drop the commit where the file was introduced, then - we will get a conflict when the rebasing operation reaches that - point in which the file is edited and we will have to resolve it. + If we take a look at the content of that commit, we see that in that commit we introduced a new file + called terms.txt. When we drop this commit we have two possible scenarios that we need to be + careful of. If a commit after that one touches that file, and we drop the commit where the file was + introduced, then we will get a conflict when the rebasing operation reaches that point in which the file + is edited and we will have to resolve it.


    - The worst-case scenario is when no other commits touch that file, - but our program needs it. In this case, we will never get a - conflict while rebasing, but we will be introducing a bug in our - program (possibly even a breaking bug). So be very careful when - dropping commits. + The worst-case scenario is when no other commits touch that file, but our program needs it. In this case, + we will never get a conflict while rebasing, but we will be introducing a bug in our program (possibly + even a breaking bug). So be very careful when dropping commits.


    To start the interactive rebase process we run

    @@ -62,63 +55,44 @@

    Dropping commits

    git rebase -i 1736531^

    - The caret (^) means that we want to start at the parent of that - commit. + The caret (^) means that we want to start at the parent of that commit.

    - Dropping commits 1 + Dropping commits 1

    - Git will now open VS Code so that we can select the operation that - we want to perform on each commit. Here we select the - drop option for the commit that we want to drop. If you - are now using GitLens, you can also just delete the line for that - commit. Once we selected all the appropriate options for our - commits, we save the file and close it. Here let's start by - deleting the first WIP commit. + Git will now open VS Code so that we can select the operation that we want to perform on each commit. Here + we select the drop option for the commit that we want to drop. If you are now using GitLens, you + can also just delete the line for that commit. Once we selected all the appropriate options for our + commits, we save the file and close it. Here let's start by deleting the first WIP commit.

    - Dropping commits 2 + Dropping commits 2
    - Dropping commits 3 + Dropping commits 3

    - When we close the file, Git will move forward with the rebase - operation. Take a look at the Git Bash image. It's telling us that - we are at step 2 of 5 during the rebase process. So the commit - that we wanted to drop has been dropped. The next commit edited - that file, which now does not exist, so we get a conflict. + When we close the file, Git will move forward with the rebase operation. Take a look at the Git Bash + image. It's telling us that we are at step 2 of 5 during the rebase process. So the commit that we wanted + to drop has been dropped. The next commit edited that file, which now does not exist, so we get a + conflict.


    - If we check the status, we can see that the - terms.txt file is been deleted (hence the red - D) and modified (hence the red - U) at the same time. This is what's - creating the conflict. + If we check the status, we can see that the terms.txt file is been deleted (hence the red + D) and modified (hence the red U) at the same + time. This is what's creating the conflict.

    @@ -129,22 +103,17 @@

    Dropping commits

    git mergetool

    - Because I haven't configured a merge tool, Git will use one of the - default ones. Git is now asking to choose between one of the two - states of the file. In the local commit (the one we are moving out - of) the file is deleted. In the remote commit (the one we are - trying to move into) the file is modified. Here we choose to keep - the file with the modifications, so we select - m. + Because I haven't configured a merge tool, Git will use one of the default ones. Git is now asking to + choose between one of the two states of the file. In the local commit (the one we are moving out of) the + file is deleted. In the remote commit (the one we are trying to move into) the file is modified. Here we + choose to keep the file with the modifications, so we select m.


    - If we now check the status, we see that the - terms.txt file is been added (since it was deleted in the - previous commit). Notice that there's a new file called - terms.txt.orig. This is a file created by the merge tool. - Some delete them automatically, but even if the merge tool we are - using does not, we can always do so ourselves. + If we now check the status, we see that the terms.txt file is been added (since it was deleted in + the previous commit). Notice that there's a new file called terms.txt.orig. This is a file + created by the merge tool. Some delete them automatically, but even if the merge tool we are using does + not, we can always do so ourselves.


    Since all conflicts have been resolved, when we run

    @@ -154,31 +123,21 @@

    Dropping commits

    Git takes care of rebasing all other involved commits.

    - Dropping commits 4 + Dropping commits 4
    - Dropping commits 5 + Dropping commits 5

    - If we check the log, we can see that the commit is now gone and we - have a much cleaner history. Notice that I've also dropped the - other WIP commit and the Revert commit too. + If we check the log, we can see that the commit is now gone and we have a much cleaner history. Notice + that I've also dropped the other WIP commit and the Revert commit too.


    - Lastly, since Git did not remove the auxiliary file created by the - mergetool, we delete it ourselves. + Lastly, since Git did not remove the auxiliary file created by the mergetool, we delete it ourselves.

    @@ -187,9 +146,7 @@

    Dropping commits

    - + + diff --git a/pages/065/rewording_commits.html b/pages/065/rewording_commits.html index ed9b245..c7650df 100644 --- a/pages/065/rewording_commits.html +++ b/pages/065/rewording_commits.html @@ -1,16 +1,14 @@ + - + Rewording commits +
    @@ -34,78 +32,57 @@

    Rewording commits

    - Suppose that we realize that we made a spelling mistake in the - commit message of a commit previous to the last one, but that we - haven't yet pushed onto a remote repository. We can change the - wording with interactive rebasing. + Suppose that we realize that we made a spelling mistake in the commit message of a commit previous to the + last one, but that we haven't yet pushed onto a remote repository. We can change the wording with + interactive rebasing.


    - As an example, suppose we want to reword commits - 6fb2ba7 and fe1a154. To start interactive - rebasing at the parent of oldest commit we run + As an example, suppose we want to reword commits 6fb2ba7 and fe1a154. To start + interactive rebasing at the parent of oldest commit we run

    git rebase -i 6fb2ba7^
    - Rewording commits 1 + Rewording commits 1

    - Now, in GitLens we select the reword option for both commits. We - save and close the file to start the rebasing process. + Now, in GitLens we select the reword option for both commits. We save and close the file to start the + rebasing process.

    - Rewording commits 2 + Rewording commits 2
    - Rewording commits 3 + Rewording commits 3

    - When we close, Git starts the rebasing process. Every time it - reaches a commit that we want to reword it opens VS Code so that - we can enter our new message. Once we do, we save, close, and Git - continues the rebasing process until all commits have been - rebased. + When we close, Git starts the rebasing process. Every time it reaches a commit that we want to reword it + opens VS Code so that we can enter our new message. Once we do, we save, close, and Git continues the + rebasing process until all commits have been rebased.

    - If we check our log now we will see that the commits that we - selected have been reworded. Notice too that since Git generated - new commits, their IDs are not the same as before the rebase. + If we check our log now we will see that the commits that we selected have been reworded. Notice too that + since Git generated new commits, their IDs are not the same as before the rebase.

    - Rewording commits 4 + Rewording commits 4
    @@ -113,9 +90,7 @@

    Rewording commits

    - + + diff --git a/pages/066/reordering_commits.html b/pages/066/reordering_commits.html index a580c13..23d1318 100644 --- a/pages/066/reordering_commits.html +++ b/pages/066/reordering_commits.html @@ -1,16 +1,14 @@ + - + Reordering commits +
    @@ -34,60 +32,44 @@

    Reordering commits

    - Suppose now that we want to reorder commits. In our example, - commit 099c06d should come before commit - 23b2c04, so we need to change their order. Once again, we - use interactive rebasing to achieve this. So we run + Suppose now that we want to reorder commits. In our example, commit 099c06d should come before + commit 23b2c04, so we need to change their order. Once again, we use interactive rebasing to + achieve this. So we run

    git rebase -i 70ef834

    - since commit 70ef834 is the parent commit of the oldest - of the two commits that we want to reorder. + since commit 70ef834 is the parent commit of the oldest of the two commits that we want to + reorder.

    - Reordering commits 1 + Reordering commits 1

    - Now in GitLens we can grab and drag the commits that we want to - reorder, and drop them in their final destination on the commit - tree. If you are not using GitLens you can move lines around in VS - Code with Alt + arrow (up or down as needed). + Now in GitLens we can grab and drag the commits that we want to reorder, and drop them in their final + destination on the commit tree. If you are not using GitLens you can move lines around in VS Code with Alt + + arrow (up or down as needed).

    - Reordering commits 2 + Reordering commits 2
    - Reordering commits 3 + Reordering commits 3

    - Since there were no conflicts or actions for us to make, Git took - care of everything as soon as we closed the VS Code file. If we - check the log now, we'll see that the commit is where we wanted it - to be. + Since there were no conflicts or actions for us to make, Git took care of everything as soon as we closed + the VS Code file. If we check the log now, we'll see that the commit is where we wanted it to be.

    @@ -96,9 +78,7 @@

    Reordering commits

    - + + diff --git a/pages/067/squashing_commits.html b/pages/067/squashing_commits.html index 5a9a2fa..8ff6806 100644 --- a/pages/067/squashing_commits.html +++ b/pages/067/squashing_commits.html @@ -1,16 +1,14 @@ + - + Squashing commits +
    @@ -34,77 +32,55 @@

    Squashing commits

    - Now let's see how we can squash commits. Squashing commits is the - process of taking two or more commits, and combining all the - changes in those commits into a single commit. For example, here - we will squash commits 78af47a, 7f4e64b, and - 2a57b17 into a single commit. To do this, we use + Now let's see how we can squash commits. Squashing commits is the process of taking two or more commits, + and combining all the changes in those commits into a single commit. For example, here we will squash + commits 78af47a, 7f4e64b, and 2a57b17 into a single commit. To do this, we use interactive rebasing. So we run

    git rebase -i ab0e842

    - where commit ab0e842 is the parent of the oldest commit - that we wish to squash. + where commit ab0e842 is the parent of the oldest commit that we wish to squash.

    - Squashing commits 1 + Squashing commits 1

    - To squash two commits together we need to use the - squash option in VS Code. Notice how GitLens is not - showing us which commits will be squashed into which commit by - simplifying the commit tree. One thing to remember here is that - squashing is an operation that can only be performed between two - consecutive commits. So once the rebasing starts, Git will first - squash commit 7f4e64b into commit 78af47a, and - then squash commit 2a57b17 into the new commit that it - created for the first squashing. If we want to squash commits that - are not consecutive to one another, then we first need to reorder - the commits. + To squash two commits together we need to use the squash option in VS Code. Notice how GitLens is + not showing us which commits will be squashed into which commit by simplifying the commit tree. One thing + to remember here is that squashing is an operation that can only be performed between two consecutive + commits. So once the rebasing starts, Git will first squash commit 7f4e64b into commit + 78af47a, and then squash commit 2a57b17 into the new commit that it created for the + first squashing. If we want to squash commits that are not consecutive to one another, then we first need + to reorder the commits.

    - Squashing commits 2 + Squashing commits 2
    - Squashing commits 3 + Squashing commits 3

    - When we close VS Code and the rebasing starts, Git will ask us to - give the new commit a message. The default message that it will - show is the combination of the commit messages for all the commits - that we are squashing. In general, since we squash commits that - have changes that we should have made into a single commit to - begin with, we should input a new message that reflects the - changes done across all of the commits been squashed. + When we close VS Code and the rebasing starts, Git will ask us to give the new commit a message. The + default message that it will show is the combination of the commit messages for all the commits that we + are squashing. In general, since we squash commits that have changes that we should have made into a + single commit to begin with, we should input a new message that reflects the changes done across all of + the commits been squashed.


    - Now if we look at our log there is only one commit for all three - sets of changes. + Now if we look at our log there is only one commit for all three sets of changes.

    @@ -112,38 +88,26 @@

    Squashing commits

    - If we already know that the message for our squashed commit is the - message for the oldest commit, then we can use the - fixup option instead of the squash option. To - see this in action, first we need to reset our repository to how - it was before the last rebasing. So we bring up our reflog by - running + If we already know that the message for our squashed commit is the message for the oldest commit, then we + can use the fixup option instead of the squash option. To see this in action, first we + need to reset our repository to how it was before the last rebasing. So we bring up our reflog by running

    git reflog

    - and grab the commit ID to which the - HEAD pointer was pointing, before - starting the rebase. In this case, commit d038481 (which - is the finish of the last rebase we did). + and grab the commit ID to which the HEAD pointer was pointing, before + starting the rebase. In this case, commit d038481 (which is the finish of the last rebase we + did).

    - Squashing commits 4 + Squashing commits 4
    - Squashing commits 5 + Squashing commits 5

    Now we use

    @@ -151,47 +115,34 @@

    Squashing commits

    git reset --hard d038481

    - and our repository will be restored to the state before the last - rebase. We can see this in our log. + and our repository will be restored to the state before the last rebase. We can see this in our log.

    - Now we restart the interactive rebase just as before, but when Git - asks us which operation to perform to the commits to squash, we - choose fixup. This will cause Git to ignore the commit - messages from these commits, and thus default to the commit that - they are being squashed into (the one with the + Now we restart the interactive rebase just as before, but when Git asks us which operation to perform to + the commits to squash, we choose fixup. This will cause Git to ignore the commit messages from + these commits, and thus default to the commit that they are being squashed into (the one with the pick operation).

    - Squashing commits 6 + Squashing commits 6
    - Squashing commits 7 + Squashing commits 7

    - Since there are no conflicts for us to resolve, as soon as we save - and close the file, Git will complete the rebasing process. If we - now check the log, we can see that the commits have been squashed, - and the message of the oldest commit was kept without us having to - tell Git which message to use. + Since there are no conflicts for us to resolve, as soon as we save and close the file, Git will complete + the rebasing process. If we now check the log, we can see that the commits have been squashed, and the + message of the oldest commit was kept without us having to tell Git which message to use.

    @@ -200,9 +151,7 @@

    Squashing commits

    - + + diff --git a/pages/068/splitting_a_commit.html b/pages/068/splitting_a_commit.html index 2001b23..14401aa 100644 --- a/pages/068/splitting_a_commit.html +++ b/pages/068/splitting_a_commit.html @@ -1,16 +1,14 @@ + - + Splitting a commit +
    @@ -34,90 +32,65 @@

    Splitting a commit

    - Sometimes we make a commit that combines changes to two separate - logical units of our program, each of which should have its own - commit. We can split these commits using interactive rebasing. As - an example, let's split commit 26986ad into two commits. - To do this we run + Sometimes we make a commit that combines changes to two separate logical units of our program, each of + which should have its own commit. We can split these commits using interactive rebasing. As an example, + let's split commit 26986ad into two commits. To do this we run

    git rebase -i 26986ad^
    - Splitting a commit 1 + Splitting a commit 1

    - To split a commit we use the edit option. When we close - the todo file, Git will start the rebase process, but it - will stop at the commit we want to rebase so that we can make our - edition. At this point, we can reset and then stage and commit the - changes that we want to include in one commit, and then stage and - commit the changes that we want to include in the other commit. + To split a commit we use the edit option. When we close the todo file, Git will start + the rebase process, but it will stop at the commit we want to rebase so that we can make our edition. At + this point, we can reset and then stage and commit the changes that we want to include in one commit, and + then stage and commit the changes that we want to include in the other commit.

    - Splitting a commit 2 + Splitting a commit 2

    - Now that we've closed the file, Git started the rebase process. We - see that the HEAD pointer is at - commit 26986ad. We can use the - reset command to go back to the - state before making that commit. So we run + Now that we've closed the file, Git started the rebase process. We see that the + HEAD pointer is at commit 26986ad. We can use the + reset command to go back to the state before making that commit. So we + run

    git reset --mixed HEAD^

    - and Git will move the HEAD pointer - to one commit before its current position and place the changes - done in the commit it's moving away from into the working - directory. + and Git will move the HEAD pointer to one commit before its current position + and place the changes done in the commit it's moving away from into the working directory.


    - Now we have two un-staged changes. We can stage and commit them - one at a time. + Now we have two un-staged changes. We can stage and commit them one at a time.

    - Splitting a commit 3 + Splitting a commit 3
    - Splitting a commit 4 + Splitting a commit 4

    - Since neither of these commits was part of our commit tree, we - have now diverged from the master branch. To continue with the - rebase we run + Since neither of these commits was part of our commit tree, we have now diverged from the master branch. + To continue with the rebase we run

    git rebase --continue @@ -127,16 +100,12 @@

    Splitting a commit

    - If we now take a look at our log, we see that our tree is clean - and linear. This makes maintaining our project easier. + If we now take a look at our log, we see that our tree is clean and linear. This makes maintaining our + project easier.

    - Splitting a commit 5 + Splitting a commit 5
    @@ -144,9 +113,7 @@

    Splitting a commit

    - + + diff --git a/pages/069/introduction_to_github_actions.html b/pages/069/introduction_to_github_actions.html index 327d3cc..98b118c 100644 --- a/pages/069/introduction_to_github_actions.html +++ b/pages/069/introduction_to_github_actions.html @@ -1,16 +1,14 @@ + - + GitHub Actions +
    @@ -32,165 +30,123 @@

    Introduction to GitHub Actions

    - GitHub Actions is a tool that allows you to automate development - workflows. Each task is called an action. A combination - of tasks is called a workflow. Workflows can be triggered - in different ways: push, pull requests (opened and/or merged), - issues (created, closed, etc), on a specific schedule, or due to - external events. + GitHub Actions is a tool that allows you to automate development workflows. Each task is called an + action. A combination of tasks is called a workflow. Workflows can be triggered in + different ways: push, pull requests (opened and/or merged), issues (created, closed, etc), on a specific + schedule, or due to external events.


    - The workflows will be run in a virtual machine on the GitHub - servers. A workflow can contain one or more jobs, and - each job will run in its own virtual machine. These virtual - machines can use Linux, Windows, or MacOS, and have different - tools installed, and even run Docker Containers. Jobs can be run + The workflows will be run in a virtual machine on the GitHub servers. A workflow can contain one or more + jobs, and each job will run in its own virtual machine. These virtual machines can use Linux, + Windows, or MacOS, and have different tools installed, and even run Docker Containers. Jobs can be run in parallel, or we can specify dependencies between them.


    - A runner is any virtual machine with the GitHub actions - application installed. The runner is responsible for running the - job whenever the triggering conditions are met, and for displaying - back the results. You can use GitHub's runners, or host your own - ones. GitHub hosted runners are maintained by GitHub, but we - cannot customize the hardware configurations. They also come with - some pre-installed tools like curl, git, npm, - yarn, pip, etc, and languages and tools like Python, - Ruby, node.JS, etc. + A runner is any virtual machine with the GitHub actions application installed. The runner is + responsible for running the job whenever the triggering conditions are met, and for displaying back the + results. You can use GitHub's runners, or host your own ones. GitHub hosted runners are maintained by + GitHub, but we cannot customize the hardware configurations. They also come with some pre-installed tools + like curl, git, npm, yarn, pip, etc, and languages and tools like + Python, Ruby, node.JS, etc.

    - Workflows must be written in YAML and placed inside - .github/workflows directory in the root of the project. - This files are composed of key:value pairs, with keys separated - from values by colons, :. To nest objects inside of other - objects in YAML we just need to indent the keys of the child - object with 2 or 4 spaces with respect to the keys of its parent - object. + Workflows must be written in YAML and placed inside .github/workflows directory in the root of + the project. These files are composed of key:value pairs, with keys separated from values by colons, + :. To nest objects inside of other objects in YAML we just need to indent the keys of the child + object with 2 or 4 spaces with respect to the keys of its parent object.


    - Each YAML file in the workflows directory contains the - instructions for one workflow. The first key that we have to - specify is name. The value we pass to it will become the - name of the workflow and GitHub will display it in the Actions - tab. + Each YAML file in the workflows directory contains the instructions for one workflow. The first + key that we have to specify is name. The value we pass to it will become the name of the workflow + and GitHub will display it in the Actions tab.


    - Introduction to GitHub Actions 1 + Introduction to GitHub Actions 1
    - Introduction to GitHub Actions 2 + Introduction to GitHub Actions 2

    - After the name we'll specify the dispatch mode of the - action using the on key. The value of the on key - can be a single value (for example, use push for a - workflow that needs to be dispatched with every push), an array of - values (for example, use [workflow_dispatch, push] for a - workflow that needs to be dispatched with every push, but also - needs to be able to be manually dispatched), or an object - specifying more complex conditions or to alter the behavior of a - pre-defined dispatch mode. + After the name we'll specify the dispatch mode of the action using the on key. The value + of the on key can be a single value (for example, use push for a workflow that needs to + be dispatched with every push), an array of values (for example, use [workflow_dispatch, push] + for a workflow that needs to be dispatched with every push, but also needs to be able to be manually + dispatched), or an object specifying more complex conditions or to alter the behavior of a pre-defined + dispatch mode.


    - After the name and on keys, we need to start - defining the jobs in our workflow. To do so we use the - jobs key. To it we'll need to supply an array of objects - (each element in the array representing a job) where the first key - is the name of the job and takes as its value an object containing + After the name and on keys, we need to start defining the jobs in our workflow. To do so + we use the jobs key. To it we'll need to supply an array of objects (each element in the array + representing a job) where the first key is the name of the job and takes as its value an object containing all the specifications of the job.


    - The first key of every job is runs-on. The value of this - key needs to be the operating system in which the job is going to - run. We can specify a version of the OS, or just use the key - {os}-latest to have GitHub use the latest version of the - OS. + The first key of every job is runs-on. The value of this key needs to be the operating system in + which the job is going to run. We can specify a version of the OS, or just use the key + {os}-latest to have GitHub use the latest version of the OS.


    - Next comes the steps key, where we can specify the - different steps of the job. We can specify a name for each step - using the name key. After that we use the - run key to specify what needs to be run on this step. + Next comes the steps key, where we can specify the different steps of the job. We can specify a + name for each step using the name key. After that we use the run key to specify what + needs to be run on this step.

    - The first and last step are automatically created by GitHub. The - first one sets up the job, and the last one cleans up after - finishing. You can configure GitHub to send notifications after - each workflow run by going to - Profile > Settings > Notifications > Actions . + The first and last step are automatically created by GitHub. The first one sets up the job, and the last + one cleans up after finishing. You can configure GitHub to send notifications after each workflow run by + going to Profile > Settings > Notifications > Actions .


    - We can cancel a workflow while it's still running by pressing the - Cancel check suite button on the top right corner of the - Actions tab. We can also explore the steps, including their - output, buy pressing the arrows left of the step name. We can use - the search bar to explore the logs. If the job failed, we can - trigger a re-run. + We can cancel a workflow while it's still running by pressing the Cancel check suite button on the + top right corner of the Actions tab. We can also explore the steps, including their output, buy + pressing the arrows left of the step name. We can use the search bar to explore the logs. If the job + failed, we can trigger a re-run.


    - For each job we can define artifacts. In a nut shell, an - artifact is a file generated by the job. An artifact that gets - generated by default is the log archive. We can download this file - from the Actions console. The log consists of one .txt file - for each step of the job. It is useful for debugging. + For each job we can define artifacts. In a nut shell, an artifact is a file generated by the job. + An artifact that gets generated by default is the log archive. We can download this file from the Actions + console. The log consists of one .txt file for each step of the job. It is useful for debugging.


    - To see more information on the logs, we need to set the - ACTIONS_RUNNER_DEBUG and - ACTIONS_STEP_DEBUG secrets to true. To do so, we - need to navigate to the Settings tab on the repo, and to - the Secrets option on the left side menu, and click on the - New repository secret button on the top right corner. + To see more information on the logs, we need to set the ACTIONS_RUNNER_DEBUG and + ACTIONS_STEP_DEBUG secrets to true. To do so, we need to navigate to the Settings + tab on the repo, and to the Secrets option on the left side menu, and click on the New + repository secret button on the top right corner.

    - Introduction to GitHub Actions 3 + Introduction to GitHub Actions 3
    - Introduction to GitHub Actions + Introduction to GitHub Actions
    @@ -198,9 +154,7 @@

    Introduction to GitHub Actions

    - + + diff --git a/pages/070/triggers.html b/pages/070/triggers.html index 4ac5b23..e207927 100644 --- a/pages/070/triggers.html +++ b/pages/070/triggers.html @@ -1,16 +1,14 @@ + - + Triggers +
    @@ -32,130 +30,89 @@

    Triggers

    - Workflows can be triggered with different events. These events can - be any GitHub event: push, pull-requests opened or closed, - comments, etc. Triggers must be specified with the - on keyword of the yaml file. We can pass a single value: + Workflows can be triggered with different events. These events can be any GitHub event: push, + pull-requests opened or closed, comments, etc. Triggers must be specified with the on keyword of + the yaml file. We can pass a single value:

    - Triggers 1 + Triggers 1
    - Triggers 2 + Triggers 2

    - If we want the same workflow to trigger on different events we can - pass an array of GitHub events to the on keyword. The - workflow will then trigger whenever at least one of the triggering - conditions is met. + If we want the same workflow to trigger on different events we can pass an array of GitHub events to the + on keyword. The workflow will then trigger whenever at least one of the triggering conditions is + met.

    - Some events have activity types. To use the activities - the value that we pass to the on keyword must be an - object. Each attribute in this object must be itself an object - named after a valid GitHub event (like push, pull_request, etc). - Inside each of these object we can define the types key - and pass to it an array of event activity types on which the - workflow should trigger. + Some events have activity types. To use the activities the value that we pass to the on + keyword must be an object. Each attribute in this object must be itself an object named after a valid + GitHub event (like push, pull_request, etc). Inside each of these object we can define the types + key and pass to it an array of event activity types on which the workflow should trigger.


    - Events that have activity types will have some of those set by - default. For example, if we trigger a workflow - on: pull_request, the workflow - will be triggered on opened, synchronized, or - reopened by default. + Events that have activity types will have some of those set by default. For example, if we trigger a + workflow on: pull_request, the workflow will be triggered on + opened, synchronized, or reopened by default.

    - Triggers 3 + Triggers 3

    The complete list of events and activity types can be found - here. + here.


    - Triggers 4 + Triggers 4

    - Workflow triggers can be filtered so that they only run when - certain branches, files (paths), tags, etc are affected. To - achieve this we need to add more key:value pairs to the - on key. + Workflow triggers can be filtered so that they only run when certain branches, files (paths), tags, etc + are affected. To achieve this we need to add more key:value pairs to the on key.


    - Branches don't necessarily need to be specified by names. They can - also be patterns. Patterns of the form - 'something/*' will only match - branches that start with - something, followed by a slash, - /, followed by some other text, - but not by additional slashes. To match this branches we need to - use 'something/**'. + Branches don't necessarily need to be specified by names. They can also be patterns. Patterns of the form + 'something/*' will only match branches that start with + something, followed by a slash, /, + followed by some other text, but not by additional slashes. To match these branches we need to use + 'something/**'.


    - We can also set the trigger to ignore branches by using the - branches-ignore key. We cannot have branches and - branches-ignore at the same time. But we can ignore - specific branches by adding an exclamation mark, ! in the - branches key. + We can also set the trigger to ignore branches by using the branches-ignore key. We cannot have + branches and branches-ignore at the same time. But we can ignore specific branches by + adding an exclamation mark, ! in the branches key.


    - We can also target specific tags in the same way as we do with - branches. We can use the tags and - tags-ignore keys to specify tags or patterns of tags to - include or ignore, and we can use the exclamation sign to exclude - specific tags. + We can also target specific tags in the same way as we do with branches. We can use the tags and + tags-ignore keys to specify tags or patterns of tags to include or ignore, and we can use the + exclamation sign to exclude specific tags.


    - Finally, we can filter the triggers by paths (files), and ignore - them using the paths-ignore key. We cannot use both keys - in the same workflow, but can also use the exclamation mark here - to ignore. + Finally, we can filter the triggers by paths (files), and ignore them using the paths-ignore key. + We cannot use both keys in the same workflow, but can also use the exclamation mark here to ignore.

    @@ -163,11 +120,8 @@

    Triggers

    You can find all possible patters - here. + here.

    @@ -176,23 +130,15 @@

    Triggers

    - To trigger workflows on a certain schedule we can use - cron jobs scheduling. Scheduling needs to be added by - passing the schedule value to the on key. This - should be an array. Each element of the array needs to contain an - object with the key cron. The value of this key needs to - be a string representing a cron expression. You can use - crontab guru to - create cron expressions. + To trigger workflows on a certain schedule we can use cron jobs scheduling. Scheduling needs to + be added by passing the schedule value to the on key. This should be an array. Each + element of the array needs to contain an object with the key cron. The value of this key needs to + be a string representing a cron expression. You can use crontab guru to create cron expressions.

    - Triggers 5 + Triggers 5
    @@ -205,9 +151,8 @@

    Triggers

    - We can also trigger workflows on external events. To do so we need - to use the repository_dispatch value, and specify which - activity types should trigger the workflow. + We can also trigger workflows on external events. To do so we need to use the repository_dispatch + value, and specify which activity types should trigger the workflow.


    These dispatch requests need to come to the API endpoint

    @@ -215,37 +160,33 @@

    Triggers

    http://api.github/repos/user_name/repo_name/dispatches

    - They need to be POST requests with the - HEADERS - Accept: application/vmd.github.everest-preview+json, and - Content-Type: application/json. The body of the request - needs to be a JSON object with an event_type that matches - at least one activity type for that trigger. + They need to be POST requests with the HEADERS + Accept: application/vmd.github.everest-preview+json, and Content-Type: application/json. + The body of the request needs to be a JSON object with an event_type that matches at least one + activity type for that trigger.


    - These requests need to be authenticated. This requires that the - request has some authorization header with a valid PAT. The PAT - must have a repo scope. + These requests need to be authenticated. This requires that the request has some authorization header with + a valid PAT. The PAT must have a repo scope.

    - We can also add some client_payload for the workflow. - This payload could, for example, be inputs needed during the jobs. + We can also add some client_payload for the workflow. This payload could, for example, be inputs + needed during the jobs.


    - This payload will be available in the github object on - the workflow. To access it, we use the + This payload will be available in the github object on the workflow. To access it, we use the event.client_payload.key attribute.


    - This can be very useful when we want to trigger workflows in one - repository, based on workflows from another repository. + This can be very useful when we want to trigger workflows in one repository, based on workflows from + another repository.

    @@ -259,9 +200,7 @@

    Triggers

    - + + diff --git a/pages/071/shells.html b/pages/071/shells.html index cb3b0a0..223e46a 100644 --- a/pages/071/shells.html +++ b/pages/071/shells.html @@ -1,16 +1,14 @@ + - + Shells +
    @@ -32,11 +30,9 @@

    Shells

    - GitHub actions can use different shells: bash, - powershell, cmd, etc. To change the shell from - the default (bash for Linux and MacOS, powershell for Windows) to - a different one, we need to specify it after the run keyword, - using the shell keyword. + GitHub actions can use different shells: bash, powershell, cmd, etc. To change + the shell from the default (bash for Linux and MacOS, powershell for Windows) to a different one, we need + to specify it after the run keyword, using the shell keyword.

    @@ -50,9 +46,7 @@

    Shells

    - + + diff --git a/pages/072/running_jobs_in_series.html b/pages/072/running_jobs_in_series.html index c2d5766..bff2e77 100644 --- a/pages/072/running_jobs_in_series.html +++ b/pages/072/running_jobs_in_series.html @@ -1,16 +1,14 @@ + - + Running jobs in series +
    @@ -30,46 +28,34 @@

    Running jobs in series

    - By default, jobs will run in parallel. If we want jobs to run in - series we need to specify the needs key. This key takes - as its value an array of job names. The job will only run once all - jobs in the array have finished successfully. + By default, jobs will run in parallel. If we want jobs to run in series we need to specify the + needs key. This key takes as its value an array of job names. The job will only run once all jobs + in the array have finished successfully.

    - Running jobs in series + Running jobs in series

    - We can also create actions that capture output. To do so we must - echo the output of a previous step. We access it by - referencing it with + We can also create actions that capture output. To do so we must echo the output of a previous + step. We access it by referencing it with

    "${{ steps.step_id.outputs.output_element }}"

    - The steps variable is created by GitHub. The step - id we need to define it ourselves in the action that we - want to reference. The outputs attribute is created by - GitHub, and the output_element is defined by the creator - of the action. Check the action's documentation to find which - elements can be output, and their names. + The steps variable is created by GitHub. The step id we need to define it ourselves in + the action that we want to reference. The outputs attribute is created by GitHub, and the + output_element is defined by the creator of the action. Check the action's documentation to find + which elements can be output, and their names.

    - Running jobs in series 2 + Running jobs in series 2
    @@ -77,9 +63,7 @@

    Running jobs in series

    - + + diff --git a/pages/073/actions.html b/pages/073/actions.html index ae96970..52c9a42 100644 --- a/pages/073/actions.html +++ b/pages/073/actions.html @@ -1,16 +1,14 @@ + - + Actions +
    @@ -34,29 +32,24 @@

    Actions

    - Actions are pieces of code that you or someone else has written to - run some task. Actions need to be written in JavaScript. + Actions are pieces of code that you or someone else has written to run some task. Actions need to be + written in JavaScript.


    - To use an action we specify it with the uses key. Actions - can be included in the same repository as the workflow is by - passing the path to it as a value, or they can be published in - public GitHub repositories. To use an action that has been - published in a public GitHub repository the value of the uses key - needs to be user_name/repo_name@branch_name. We can also - target a released version with - user_name/repo_name@tag_name. We can reference a commit - with user_name/repo_name@commit_sha. The preferred method - it to use the tag name, since the tip of a branch might change in - the future and introduce breaking changes. If the version - references only a mayor, then the latest minor of that mayor will - be used. Same logic with patches. + To use an action we specify it with the uses key. Actions can be included in the same repository + as the workflow is by passing the path to it as a value, or they can be published in public GitHub + repositories. To use an action that has been published in a public GitHub repository the value of the uses + key needs to be user_name/repo_name@branch_name. We can also target a released version with + user_name/repo_name@tag_name. We can reference a commit with + user_name/repo_name@commit_sha. The preferred method it to use the tag name, since the tip of a + branch might change in the future and introduce breaking changes. If the version references only a mayor, + then the latest minor of that mayor will be used. Same logic with patches.


    - Actions might require/allow inputs. The inputs need to be passed - by name (key) as child elements of the with key. + Actions might require/allow inputs. The inputs need to be passed by name (key) as child elements of the + with key.

    @@ -70,9 +63,7 @@

    Actions

    - + + diff --git a/pages/074/the_checkout_action.html b/pages/074/the_checkout_action.html index 11b5dd2..1cb7205 100644 --- a/pages/074/the_checkout_action.html +++ b/pages/074/the_checkout_action.html @@ -1,16 +1,14 @@ + - + The checkout action +
    @@ -32,36 +30,30 @@

    The checkout action

    - When we run a CLI command in our local machine, the command is run - on the current directory. When we use workflows, GitHub will set - up a directory in which to run them. This directory is + When we run a CLI command in our local machine, the command is run on the current directory. When we use + workflows, GitHub will set up a directory in which to run them. This directory is

    /home/runner/work/repo_name/repo_name

    - But, by default, that directory will not contain the files in our - directory. The repository is not cloned by default. + But, by default, that directory will not contain the files in our directory. The repository is not cloned + by default.

    - We can use an action to clone the repository into the working - directory. This special action was created by GitHub and is called - checkout. This action will authenticate with our - repository, and checkout to the commit that triggered the run. + We can use an action to clone the repository into the working directory. This special action was created + by GitHub and is called checkout. This action will authenticate with our repository, and checkout + to the commit that triggered the run.

    - Checkout action 1 + Checkout action 1
    @@ -69,9 +61,7 @@

    The checkout action

    - + + diff --git a/pages/075/environment_variables.html b/pages/075/environment_variables.html index bcf6084..2268acd 100644 --- a/pages/075/environment_variables.html +++ b/pages/075/environment_variables.html @@ -1,16 +1,14 @@ + - + Environment variables +
    @@ -35,35 +33,29 @@

    Environment variables

    - Some environment variables are set up automatically by GitHub (in - the runner). We can use these variables in our workflows by - referencing them with $VARIABLE_NAME. + Some environment variables are set up automatically by GitHub (in the runner). We can use these variables + in our workflows by referencing them with $VARIABLE_NAME.


    Some of them are:

    • - $GITHUB_SHA will return the SHA - of the commit that triggered the workflow + $GITHUB_SHA will return the SHA of the commit that triggered the + workflow
    • - $GITHUB_REPOSITORY will return - the user_name/repo_name in which the workflow is - running + $GITHUB_REPOSITORY will return the user_name/repo_name in + which the workflow is running
    • - $GITHUB_WORKSPACE will return - the workspace directory in the runner. + $GITHUB_WORKSPACE will return the workspace directory in the runner

    You can see the complete list of built-in environment variables - here. + here.

    @@ -72,87 +64,67 @@

    Environment variables

    - We can define our own environment variables as well. To declare a - variable we need to use the env key at the start of our - workflow. This key takes as its value a list of key:value pairs, - where the keys are the names of the environment variables that we - are declaring, and its values are the values of the variables. + We can define our own environment variables as well. To declare a variable we need to use the env + key at the start of our workflow. This key takes as its value a list of key:value pairs, where the keys + are the names of the environment variables that we are declaring, and its values are the values of the + variables.


    - After that we can just write our jobs as we would normally do. To - access the variables we just need to use the - ${ VAR_NAME } syntax. + After that we can just write our jobs as we would normally do. To access the variables we just need to use + the ${ VAR_NAME } syntax.


    - Variables declared this way will be available to the whole - workflow. Variables that need to only be available to a specific - job in the workflow are declared and used in the same way, but - using the env in that specific job. + Variables declared this way will be available to the whole workflow. Variables that need to only be + available to a specific job in the workflow are declared and used in the same way, but using the + env in that specific job.


    - Likewise, if we want a variable to only be available in a step of - a job, we use declare and use it in that step. + Likewise, if we want a variable to only be available in a step of a job, we use declare and use it in that + step.

    - Environment variables 1 + Environment variables 1
    - Environment variables 2 + Environment variables 2

    - Some variables need to be encrypted. To do so, we just need to add - the variable value in - Settings > Secrets > Actions > New repository secret. Give - it a name and a value, and save it. These variables will be - available in a workflow using an object called secrets. + Some variables need to be encrypted. To do so, we just need to add the variable value in Settings > + Secrets > Actions > New repository secret. Give it a name and a value, and save it. These + variables will be available in a workflow using an object called secrets.


    - One secret that is automatically available on workflows is - secrets.GITHUB_TOKEN. This token can be used to access - the GitHub API, or to push something to the repo, etc. Basically, - any time that the action needs to interact with the repository it - will need authentication, and we can use this variable to do it. + One secret that is automatically available on workflows is secrets.GITHUB_TOKEN. This token can + be used to access the GitHub API, or to push something to the repo, etc. Basically, any time that the + action needs to interact with the repository it will need authentication, and we can use this variable to + do it.

    - Secrets can be safely logged because GitHub will never expose them - to the logs. It will print them as asterisks. + Secrets can be safely logged because GitHub will never expose them to the logs. It will print them as + asterisks.


    - The authentication token can also be accessed via the - github object. This object is automatically set for us by - GitHub and contains several other values too. More on that object - latter. + The authentication token can also be accessed via the github object. This object is automatically + set for us by GitHub and contains several other values too. More on that object later.

    - Environment variables 3 + Environment variables 3
    @@ -160,36 +132,24 @@

    Environment variables

    - Secrets are useful but they have a limit of 6kbs. Likewise, we - might be using some CLI commands in a workflow that uses some - secrets that need to be stored in a JSON file. We can push - encrypted versions of those files and then include a decryption - step in our jobs. + Secrets are useful but they have a limit of 6kbs. Likewise, we might be using some CLI commands in a + workflow that uses some secrets that need to be stored in a JSON file. We can push encrypted versions of + those files and then include a decryption step in our jobs.


    - To encrypt the file locally we can use tools like - GPG. For details - on how to use this tool, refer to the encrypted secrets - documentation - here. Since this files require a passphrase to be decrypted, that - passphrase needs to be added as a repository secret. And since the - encrypted file itself needs to be available in the runner, - workflows that require them must first include a checkout step. + To encrypt the file locally we can use tools like GPG. + For details on how to use this tool, refer to the encrypted secrets documentation + here. + Since these files require a passphrase to be decrypted, that passphrase needs to be added as a repository + secret. And since the encrypted file itself needs to be available in the runner, workflows that require + them must first include a checkout step.

    - Environment variables 4 + Environment variables 4
    @@ -197,9 +157,7 @@

    Environment variables

    - + + diff --git a/pages/076/expressions_and_contexts.html b/pages/076/expressions_and_contexts.html index 2574b54..5955be9 100644 --- a/pages/076/expressions_and_contexts.html +++ b/pages/076/expressions_and_contexts.html @@ -1,16 +1,14 @@ + - + Expressions and contexts +
    @@ -35,24 +33,16 @@

    Expressions and contexts

    - We've been using the ${{ }} syntax. Whatever we write - inside the ${{ }} is called an expression. These - expressions can be anything that needs to be evaluated, included - literals like numbers, booleans, strings, and even operators (=, - >, &ge, <, &le). + We've been using the ${{ }} syntax. Whatever we write inside the ${{ }} is called an + expression. These expressions can be anything that needs to be evaluated, included literals like + numbers, booleans, strings, and even operators (=, >, &ge, <, &le).


    - Objects that contain some information about the workflow are - called contexts. For example, the github context - contains information about the GitHub repository, the - secrets context contains all repository secrets. You can - find all the contexts - here. + Objects that contain some information about the workflow are called contexts. For example, the + github context contains information about the GitHub repository, the secrets context + contains all repository secrets. You can find all the contexts + here.

    @@ -61,24 +51,16 @@

    Expressions and contexts

    - GitHub comes with a list of functions for some basic operations. - Expressions can be GitHub functions. You can find the complete - list of available functions - here. + GitHub comes with a list of functions for some basic operations. Expressions can be GitHub functions. You + can find the complete list of available functions + here.

    - Expressions and contexts 1 + Expressions and contexts 1
    @@ -86,42 +68,31 @@

    Expressions and contexts

    - One group of GitHub functions that are particularly useful are the - Job status functions. These return information on what - the status of a job is (at the moment of their invocation). They - are commonly used with the if key. This will cause the - steps in the job (or a certain step) to only run if a certain - expression evaluates to true (like, for example, a previous job - being successful). GitHub will treat anything in the - if key as an expression already, so we don't need to use - the ${{ }} syntax. + One group of GitHub functions that are particularly useful are the Job status functions. These + return information on what the status of a job is (at the moment of their invocation). They are commonly + used with the if key. This will cause the steps in the job (or a certain step) to only run if a + certain expression evaluates to true (like, for example, a previous job being successful). GitHub will + treat anything in the if key as an expression already, so we don't need to use the + ${{ }} syntax.


    - The default Job check status is - success() and it will be applied - unless other functions are specified. + The default Job check status is success() and it will be applied unless + other functions are specified.

    - Expressions and contexts + Expressions and contexts

    You can find all Job status functions - here. + here.

    @@ -130,9 +101,7 @@

    Expressions and contexts

    - + + diff --git a/pages/077/continue_on_error.html b/pages/077/continue_on_error.html index c97e0e7..a9e4a59 100644 --- a/pages/077/continue_on_error.html +++ b/pages/077/continue_on_error.html @@ -1,16 +1,14 @@ + - + Continue on error +
    @@ -32,23 +30,16 @@

    Continue on error

    - The if: failure() option was good to force a downstream - step to run even if the previous one had failed. But any step - coming after that immediate failed one, will still not run. If we - need to make sure that all downstream steps do run, we can add the - continue-on-error: true key:value - pair to the job that might fail. By default this key's value is - set to false. + The if: failure() option was good to force a downstream step to run even if the previous one had + failed. But any step coming after that immediate failed one, will still not run. If we need to make sure + that all downstream steps do run, we can add the continue-on-error: true + key:value pair to the job that might fail. By default this key's value is set to false.

    - Continue on error 1 + Continue on error 1
    @@ -56,9 +47,7 @@

    Continue on error

    - + + diff --git a/pages/078/timeout_minutes.html b/pages/078/timeout_minutes.html index 4f3f551..e8af8ae 100644 --- a/pages/078/timeout_minutes.html +++ b/pages/078/timeout_minutes.html @@ -1,16 +1,14 @@ + - + Timeout minutes +
    @@ -34,21 +32,15 @@

    Timeout minutes

    - Another key that we can use is the timeout-minutes. It - can be added either to a job or to a step. This key controls the - maximum number of minutes that the job or step can take. By - default this key's value is set to 360. After the alloted time, - GitHub will cancel the job. + Another key that we can use is the timeout-minutes. It can be added either to a job or to a step. + This key controls the maximum number of minutes that the job or step can take. By default this key's value + is set to 360. After the alloted time, GitHub will cancel the job.

    - Timeout minutes 1 + Timeout minutes 1
    @@ -56,9 +48,7 @@

    Timeout minutes

    - + + diff --git a/pages/079/matrix_and_strategy.html b/pages/079/matrix_and_strategy.html index 0e4b081..4ac91ca 100644 --- a/pages/079/matrix_and_strategy.html +++ b/pages/079/matrix_and_strategy.html @@ -1,16 +1,14 @@ + - + Matrix and strategy +
    @@ -32,80 +30,57 @@

    Matrix and strategy

    - The strategy key will allow us to set up an environment - matrix. GitHub will then run the job in every possible - combination of environments set-ups specified on our matrix. To - set up a strategy we need to include the strategy key in - our job. Inside this key we also need to add the - matrix key. The value of the matrix key needs to - be an object. The keys of this object can be whatever we like. - These keys basically act as parameters. Each value is an array of - the different values that we want to pass to our job for that - parameter. + The strategy key will allow us to set up an environment matrix. GitHub will then run the + job in every possible combination of environments set-ups specified on our matrix. To set up a strategy we + need to include the strategy key in our job. Inside this key we also need to add the + matrix key. The value of the matrix key needs to be an object. The keys of this object + can be whatever we like. These keys basically act as parameters. Each value is an array of the different + values that we want to pass to our job for that parameter.


    - Under the strategy key we can also add the - fail-fast key. By default this key has a value of true. - This means that under this job, if one step fails, all other steps - of the job will be stopped. + Under the strategy key we can also add the fail-fast key. By default this key has a + value of true. This means that under this job, if one step fails, all other steps of the job will be + stopped.


    - We can also add the max-parallel keyword. This key takes - as its value an integer that specifies how many values of the - matrix can run in parallel. By default, GitHub will try to - maximize the number of jobs running in parallel. + We can also add the max-parallel keyword. This key takes as its value an integer that specifies + how many values of the matrix can run in parallel. By default, GitHub will try to maximize the number of + jobs running in parallel.


    - To reference the values of our matrix we need to use an expression - that invokes the matrix context. Using dot notation, we pass the - context and the parameter key that we defined in our matrix. - GitHub will run the job once with each possible combination of - parameter values. + To reference the values of our matrix we need to use an expression that invokes the matrix context. Using + dot notation, we pass the context and the parameter key that we defined in our matrix. GitHub will run the + job once with each possible combination of parameter values.

    - Matrix and strategy 1 + Matrix and strategy 1
    - Matrix and strategy 2 + Matrix and strategy 2

    - If we want to exclude a particular combination in our matrix, we - can use the exclude key to specify an array of values - (one per key) to exclude. + If we want to exclude a particular combination in our matrix, we can use the exclude key to + specify an array of values (one per key) to exclude.

    - There's also an include key, but it's not the opposite of - the exclude key. This key also takes an array of objects - with all the parameters of the matrix, but we use it to specify - additional configurations or variables that are needed for that - combination only. + There's also an include key, but it's not the opposite of the exclude key. This key also + takes an array of objects with all the parameters of the matrix, but we use it to specify additional + configurations or variables that are needed for that combination only.

    - Matrix and strategy 3 + Matrix and strategy 3
    @@ -113,9 +88,7 @@

    Matrix and strategy

    - + + diff --git a/pages/080/docker.html b/pages/080/docker.html index 33e208c..38dc32e 100644 --- a/pages/080/docker.html +++ b/pages/080/docker.html @@ -1,16 +1,14 @@ + - + Docker +
    @@ -33,15 +31,12 @@

    Docker

    - We can specify Docker containers for our jobs to run by using the - container key. To it we pass an object with an - image key, its value being the image that we will be - using. Additionally, we can specify the env (for - environment variables that need to be available in the container), - ports (to specify ports to be exposed in the container), - volumes, options (to be used in the Docker - create command). All steps in the job will run in de container, - and not on the virtual machine. + We can specify Docker containers for our jobs to run by using the container key. To it we pass an + object with an image key, its value being the image that we will be using. Additionally, we can + specify the env (for environment variables that need to be available in the container), + ports (to specify ports to be exposed in the container), volumes, options (to + be used in the Docker create command). All steps in the job will run in de container, and not on the + virtual machine.

    @@ -54,20 +49,17 @@

    Docker

    - We can also specify multiple containers. To specify multiple - containers we pass an object to the services key. Each - element of that object is the key that identifies each one of our - services. In order to communicate between the two containers we - can use the service key (name) as a host name. + We can also specify multiple containers. To specify multiple containers we pass an object to the + services key. Each element of that object is the key that identifies each one of our services. In + order to communicate between the two containers we can use the service key (name) as a host name.

    - We can specify different containers for different steps. To do so, - we simply pass the Docker image to uses keyword of the - respective steps. + We can specify different containers for different steps. To do so, we simply pass the Docker image to + uses keyword of the respective steps.

    @@ -79,9 +71,7 @@

    Docker

    - + + diff --git a/pages/081/executable_files.html b/pages/081/executable_files.html index 127c4e9..22bc1d3 100644 --- a/pages/081/executable_files.html +++ b/pages/081/executable_files.html @@ -1,16 +1,14 @@ + - + Executable files +
    @@ -33,19 +31,13 @@

    Executable files

    - We can create our own executable files and run them in actions. - This includes passing them as the ENTRYPOINT to a Docker - file. When using a shell script, be sure to run - chmod +x path/to/file.sh before - committing the changes. + We can create our own executable files and run them in actions. This includes passing them as the + ENTRYPOINT to a Docker file. When using a shell script, be sure to run + chmod +x path/to/file.sh before committing the changes.

    - Executable files 1 + Executable files 1
    @@ -53,9 +45,7 @@

    Executable files

    - + + diff --git a/pages/082/building_github_actions.html b/pages/082/building_github_actions.html index d7834ad..7d5d23b 100644 --- a/pages/082/building_github_actions.html +++ b/pages/082/building_github_actions.html @@ -1,16 +1,14 @@ + - + Building GitHub Actions +
    @@ -35,23 +33,15 @@

    Building GitHub Actions

    - We can create our own actions to automate our steps. Public - actions require their own dedicated repository. Private actions - can be built in our repository. Actions must be written using - JavaScript. If we need to write the Action in a different - language, we need to run them in Docker containers. They have the - benefit of being consistent (since they run in a controlled - environment defined in the Docker image), but they have the draw - side of being slower (since the image needs to be deployed to the - virtual machine). + We can create our own actions to automate our steps. Public actions require their own dedicated + repository. Private actions can be built in our repository. Actions must be written using JavaScript. If + we need to write the Action in a different language, we need to run them in Docker containers. They have + the benefit of being consistent (since they run in a controlled environment defined in the Docker image), + but they have the draw side of being slower (since the image needs to be deployed to the virtual machine).

    - Building GitHub Actions 1 + Building GitHub Actions 1
    @@ -59,9 +49,7 @@

    Building GitHub Actions

    - + + diff --git a/pages/083/javascript_actions.html b/pages/083/javascript_actions.html index 129e48b..a9ce1b1 100644 --- a/pages/083/javascript_actions.html +++ b/pages/083/javascript_actions.html @@ -1,16 +1,14 @@ + - + JavaScript actions +
    @@ -32,34 +30,25 @@

    JavaScript actions

    - JavaScript actions 1 + JavaScript actions 1

    - We place actions in the - .github/actions directory. Each - action should have its own sub-directory. + We place actions in the .github/actions directory. Each action should + have its own sub-directory.


    - Each action requires an action.yml file. In this file - we'll declare the name, author, and - description of the action. Next we can add objects to the - inputs and outputs keywords. Each elements of - the inputs object is itself an object too, with a - description, required flag, and a - default value. Each element of the outputs object takes a - description. + Each action requires an action.yml file. In this file we'll declare the name, + author, and description of the action. Next we can add objects to the inputs + and outputs keywords. Each elements of the inputs object is itself an object too, with a + description, required flag, and a default value. Each element of the outputs + object takes a description.


    - Below that we need to include the runs keyword. In it we - specify the version of node in the using keyword, and the - location of the file with the action in the main keyword. + Below that we need to include the runs keyword. In it we specify the version of node in the + using keyword, and the location of the file with the action in the main keyword.

    @@ -67,34 +56,25 @@

    JavaScript actions

    - To include this action in a workflow, first we'll need to checkout - the repository and then pass the action path to the - uses keyword. + To include this action in a workflow, first we'll need to checkout the repository and then pass the action + path to the uses keyword.


    - When our actions use external packages we need to compile our code - so that the packages are available in the virtual machine. To do - this, we can use the vercel/ncc package. To install it - locally we run - npm i -D @vercel/ncc. Once - installed we can use it by running + When our actions use external packages we need to compile our code so that the packages are available in + the virtual machine. To do this, we can use the vercel/ncc package. To install it locally we run + npm i -D @vercel/ncc. Once installed we can use it by running

    npx ncc build path/to/file.js -o path/to/output/dist

    - Once the dist is generated we just have to update the - main keyword in our workflow so that it points to it (for - example main: 'dist/index.js'). + Once the dist is generated we just have to update the main keyword in our workflow so that + it points to it (for example main: 'dist/index.js').

    - JavaScript actions 2 + JavaScript actions 2
    @@ -102,9 +82,7 @@

    JavaScript actions

    - + + diff --git a/pages/084/github_toolkit.html b/pages/084/github_toolkit.html index 5fb0786..fc27c1c 100644 --- a/pages/084/github_toolkit.html +++ b/pages/084/github_toolkit.html @@ -1,16 +1,14 @@ + - + GitHub toolkit +
    @@ -32,102 +30,48 @@

    GitHub toolkit

    - GitHub provides a - toolkit - to help facilitate building actions that we can use. This toolkit - is composed of several packages, each specialized in one group of - tools. + GitHub provides a toolkit to help facilitate + building actions that we can use. This toolkit is composed of several packages, each specialized in one + group of tools.

    • - The - core - package provides functions for inputs, outputs, results, - logging, secrets, and variables. + The core package + provides functions for inputs, outputs, results, logging, secrets, and variables.
    • - The - exec - package provides functions to execute CLI tools and process - output. + The exec package + provides functions to execute CLI tools and process output.
    • - The - glob - package provides functions to search for files matching glob - patterns. + The glob package + provides functions to search for files matching glob patterns.
    • The - http-client - package provides a lightweight HTTP client optimized for - building actions. + http-client + package provides a lightweight HTTP client optimized for building actions.
    • - The - io - package provides disk i/o functions (like cp, mv, rmRF, which, - etc). + The io package + provides disk i/o functions (like cp, mv, rmRF, which, etc).
    • The - tool-cache + tool-cache package provides functions for downloading and caching tools.
    • - The - github - package provides an Octokit client hydrated with the context - that the current action is being run in. + The github + package provides an Octokit client hydrated with the context that the current action is being run in.
    • - The - artifact + The artifact package provides functions to interact with actions artifacts.
    • - The - cache - package provides functions to cache dependencies and build - outputs to improve workflow execution time. + The cache package + provides functions to cache dependencies and build outputs to improve workflow execution time.
    @@ -143,9 +87,7 @@

    GitHub toolkit

    - + + diff --git a/pages/085/docker_actions.html b/pages/085/docker_actions.html index 6178217..ee46818 100644 --- a/pages/085/docker_actions.html +++ b/pages/085/docker_actions.html @@ -1,16 +1,14 @@ + - + Docker actions +
    @@ -32,84 +30,57 @@

    Docker actions

    - Docker actions don't run directly on the virtual machine in the - GitHub Action runner, but rather in the container defined by the - Docker build. It will be slower, but allows us to use tools that - are otherwise not available in the GitHub servers. + Docker actions don't run directly on the virtual machine in the GitHub Action runner, but rather in the + container defined by the Docker build. It will be slower, but allows us to use tools that are otherwise + not available in the GitHub servers.


    - The basic directory organization is the same. Create a - sub-directory in the .github/actions directory, and place - the action.yml file in there. We also need to add in this - directory all other files needed for the action (e.g. Dockerfile, - executable files, etc). + The basic directory organization is the same. Create a sub-directory in the .github/actions + directory, and place the action.yml file in there. We also need to add in this directory all + other files needed for the action (e.g. Dockerfile, executable files, etc).

    - Docker actions 1 + Docker actions 1
    - Docker actions 2 + Docker actions 2

    - The action.yml file follows the same structure as before, - but the using key needs to be set to docker, and instead - of main we need to supply an image. This can be - either an image from DockerHub, or one that we create ourselves. + The action.yml file follows the same structure as before, but the using key needs to be + set to docker, and instead of main we need to supply an image. This can be either an + image from DockerHub, or one that we create ourselves.

    - The Dockerfile needs to be placed inside the action - directory. When using Docker actions, we need to define the inputs - in the inputs object, but also pass them to the - args array. This way, arguments will be supplied to the - entrypoint. + The Dockerfile needs to be placed inside the action directory. When using Docker actions, we need + to define the inputs in the inputs object, but also pass them to the args array. This + way, arguments will be supplied to the entrypoint.


    - Dockerfiles in Github actions do have certain limitations. You can - check them - here. + Dockerfiles in Github actions do have certain limitations. You can check them + here.

    - Docker actions 3 + Docker actions 3
    - Docker actions 3 + Docker actions 3

    - To set environment variables when creating actions in Docker - containers we use the syntax + To set environment variables when creating actions in Docker containers we use the syntax

    echo "{environment_variable_name}={value}" >> $GITHUB_ENV @@ -122,9 +93,7 @@

    Docker actions

    - + +