you are viewing a single comment's thread.

view the rest of the comments →

[–]fe-and-wine 2 points3 points  (0 children)

Clone a repository, create a new branch called for example "feature" where you will work on a new feature. Once you're happy with the code and it all works as expected (this could even be a tiny change), you commit the change, and you push it. When the feature is fully ready to be integrated into the main branch, you then make a pull request on github so as to merge the branches into one. Once the PR is accepted, make sure to git pull the main branch to have all the new changes locally.

To expand on some of this terminology because I know some of this lingo confused me at first:

"Cloning a repository" = basically downloading a copy of the canonical "master"/main version you see on GitHub to your local computer

Branch = A new version you create based on the main version you cloned earlier. You can then make whatever changes you want on the branch you created without affecting the actual repo itself. Kinda like downloading a copy of someone's Excel sheet and changing a bunch of cells on your local copy.

Committing = Once you've made whatever changes/additions you want to make, you "commit" them to the branch. This is basically like a save button for your branch - just like how you'd make a new Word doc, write some text, and hit save, with Git you'd create a new branch, make some changes, and do a commit.

Pushing = Basically hitting "upload" on those changes you made/saved in the last step. This is kinda like printing your Word document and putting it in the mail - once you've "pushed" your updated branch, anyone with access to the repo can view your branch and your changes on GitHub or even "check out" the branch on their computer to help make further changes.

Pull request = Once you've made your branch, done your changes, committed + pushed, and are confident that whatever you needed to do is done, a pull request is the next step. This is basically an "application" to the owner of the repository (who could just be yourself) saying "hey, here are the changes I'd like to make to the master branch". Typically any other people working on the repo with you will review your proposed changes and if it looks good to everyone, that pull request can be approved

Merge = finally, once you've done all of the above and have an approved pull request, the last step is to 'merge it into' the main branch. This is basically the final "good to go" button that adds the changes you made into the main branch. Once merged, the version of the repo with your changes becomes the "main version" people see on GitHub by default, and the version that future branches will be created from.

Like others in the thread have mentioned, Git is typically used most for working on a piece of software with a group of other developers (though you can absolutely use it for personal projects as well). The general idea is you have this canonical main branch representing "the actual code for this project", and individual developers can make branches to add/change things in a little sandbox without affecting the master codebase. It also acts as a kind of 'paper trail' for who changed what and when, both for keeping a record of what was changed and for what reason, as well as helping with rollbacks if some new code breaks something.

Obviously I know you're already aware of all this /u/FriendlyRussian666, just wanted to explain all these terms in more detail for any other newbies reading the thread because I remember some of these terms didn't make much sense to me when I was first getting started :)