Besides direct collaboration, they are often used to: Branches are simply a way to create parallel lines of work. Great, so you just created a new branch and committed some work to it. Also, this commit will be added on the new branch we created.
(period) stands for the current directory in Bash and other shells, so the command basically means "stage all changes in the current directory". Note how we staged changes from all the existing files using git add.
# DIY: Add a heading to each poem # THEN, commit the changes: git add. Open each poem file and add a heading at the top of the contents. Let's actually add our headings now and commit the changes. Now we’ve created a branch and switched to it, so that our active branch is add-headings. # Checkout to current version git checkout master # Create a new branch for adding headings git branch add-headings # Switch to the branch we just created git checkout add-headingsįair enough. If you’re here from part 1, be sure to checkout to the current, latest version. So we’ll name the branch as add-headings (branch names should not contain spaces). Here, the task we want to do is to add headings to our existing poems. The general workflow is to create a separate space for your task, do your task in this space and when done, merge your space into the main line. When people collaborate, it is good practice to keep your work in a separate space to avoid clash of work (imagine five people writing an article on the same piece of paper). This’ll look simpler by the end of the article. Different colours denote different branches, and asterisks are points where one branch merges into another. But now that we are working with other people too, we need to ensure we don’t get in the way of others.Īn example of a project extensively using Git branches. Our book’s going pretty good, but we forgot something - we didn’t add headings on any of our poems! Normally, we would just add headings to our existing files and make a commit for it. So from now, we’ll assume that we are working with some other authors too on our novel.
One of the features of version control systems that allow for easy collaboration are branches, which we’ll be covering in this part. Linus Torvalds developed Git when BitKeeper failed to keep pace with the rapidly growing Linux development community and the kernel project itself (amongst some other reasons). Version control systems are built to allow seamless and nearly painless collaboration between members of a project. Till now, we’ve used Git simply as a personal book-keeping butler, ignoring one of the most important use cases of a powerful version control system - collaboration. We’ll be focusing a bit more on theory this time, so follow closely. This time, we’ll cover some of the more complex concepts and operations of Git - in particular, we’ll dive into how commits are organised inside Git and have a go at using branches and merging them. We also took a little dive into the backstage of how the above operations happen inside Git. In Part 1, we covered initializing a Git repository, staging our changes, committing our work and checking out past versions of our project.
0 kommentar(er)
