![]() Neither Brackets nor GitHub support the stash and suffice it to say, I’m not a great fan of the stash either- hence I don’t cover it in these pages. There is a way around this, it’s called stashing files and it’s essentially a temporary way of storing files that are a work in progress (WIP in Git terminology) without committing them-it essentially pushes the files onto a storage stack (remember the Z80 push/pop assembler commands?-no?-never mind). YOU CANNOT CHANGE BRANCHES IF YOU HAVE UNCOMMITTED CHANGES IN YOUR WORKING COPY We would lose the changes we had made in the previous branch and that would be bad. Well there is a problem, if we try to change branches with modifications that are in the working directory or staged area, when we change branches, those modifications would be overwritten by whatever files are at the head of the branch we are changing to. Now let’s say we want to go have a quick look on another branch. we are in the process of modifying them and we’re not ready to commit them yet. Let’s say we’re back on the dev-01-branch and we’ve made some changes to 01-intro.html, but we aren’t ready to commit them to the local repository-i.e. In this case we will call it the dev-01-intro branch (I start development branches with dev for clarity in later sections I abbreviate this to d-). Any development work needs to be done on a new branch. In my best practice model for branching ( § 2.4.2), the tested deployable code is always on the master branch. Now let’s suppose that we want to add another page called 01-intro.html. Well let’s suppose that our index.html page is finished and we’re completely happy with it and its finished code is sitting at commit. In this case it is on the master branch (the only one we have) and points to commit which is the most recent commit. The head (by default) points to the latest (most recent) commit on the currently active branch. In Figure 2.12 I’ve added a symbol this is, in Git parlance, the head. This is just a convention you understand, there is absolutely nothing special about the master branch itself, but it is a convention I use and I explain it in the best practice section ( § 2.4.2 and appendix b). In this sense it has had importance thrust upon it the master branch has become the default branch for deployable code. ![]() Not because it is special or particularly important, but because everybody just keeps it. Virtually every project ever created with Git or GitHub will have a master branch. It is perfectly possible to rename it or even delete it. There is nothing special about the master branch, it is just the first branch created in the repository and by default Git always calls it “ master”. By default this branch is called the master branch it is this branch that we have been working on all this time. ![]() Git automatically created a branch for us (Git always has to have at least one branch). When we created ( initialised) the repository in section 2.2.1. Now so far we haven’t mentioned branches, but that doesn’t mean we haven’t been using one. These two commits already exist on a branch, the master branch. We made our first commit at a point in time, and sometime later we made our second commit.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |