Wild Wonder S1 E3 — GIT collaboration
Collaboration for the masses! 👥
This will cover the fantastic collaborative powers of GIT branches and how to fix issues by merging them all back together at the end!
Git Branch
Branches are a great way to stay out of the way of other developers while working on the same code space and allowing you to do what you need to do! For now, we have only the master branch. Think of it as a tree’s trunk, this will be the main place where we create and merge branches back in once we’ve finished.
If you want to see the branches in your repo do a git branch command and it will return a list of all the current branches. Usually, we rename the master branch main as there is a cultural change in the tech industry that has started to remove divisive language.
To do this to our branch we can run the git branch -M main the -M flag denoting the new name for this current branch. To make a new branch you use git branch <new-branch-name>. If you want to delete a branch you use git branch -d <branch-name>. Great if you make a typo when setting up a new branch and you don’t want everyone to see it! 🙈
Git Checkout
To check out which branch you’re on, you can use git branch and see your new branch and our main branch. An Asterix will highlight the active branch we are currently on. To move over to the new branch we need to git checkout <branch-name> this will then switch us over. If you then add to your new branch and commit the change we can git checkout main back and see any commit changes magically disappear!
That is because they live on the other branch so they don’t technically exist here and that’s why they disappear! You can also shorten the above creation and checkout into a single command.
Using a -b flag to make git checkout -b <new branch name> This will make the new branch and switch you over all in one go! Kinda like the git pull is the combined git fetch and git merge. If you also want to switch back to your last branch you can do git checkout -to take you back to your previous branch.
Merge Conflicts
Conflicts can be scary but they don’t have to be, and they can happen more than you think they would. A merge conflict is when you have 2 merges that affect the same line of code in the same file. If you only have local changes and have not made a commit, when you try to merge in something that has also changed the same line of code, it’s going to fail. GIT will ask you to remove, stash (we’ll come back to this), or commit your changes first.
If you commit your changes in and then try to merge again this is when you will get a true merge conflict. You will need to choose what code to keep or choose both, in which case each line will save after one another. Most IDEs have a merge conflict editor/helper to show you the conflicts of your local and remote changes.
You can also use the git diff command to see these differences in the CLI. Once you have gone through all the conflicts and chosen what’s staying and what’s going, you will need to commit to the merge changes. You should then git push to keep everything updated in your remote branch. Otherwise, if you need to stop merging for any reason you can do the git merge --abort . This will stop the merge and go back to your last local changes before the merge tried to take place.
Fork
Forking a repository isn’t a specific thing to GIT but it is to Github and other VCS sites like BitBucket. Forking will make a copy of a repo into your own VCS account. This can be very useful if you’re working on an open-source project. Allowing you the safety to make significant changes without affecting the original repo!
It also keeps a connection to the OG repo allowing you to pull in updates with it set as the upstream. Like we learned back in Episode 2 with Git Pull! You can work away and when ready send a pull request. The repo owner can then pull in your changes from your forked repo, after reviewing, testing and deciding if they want to merge it in or not. Remember it’s still always best to make a branch from a forked repository to make any of your changes on!
Pull Request
Pull Requests (PRs) are the way to get your changes back to your remote or forked OG repo through a VCS provider. To do this you’ll need to go back to a good old git push origin <your branch name> to send it back to the repo, with origin being the original remote repo. When you go back to your online VCS provider and into your forked/cloned repo you should be able to see your pull request.
Some IDEs will give you this link in your terminal after you do your git push command. You’ll find most if not all repos you fork/clone will have some guide for contributing, so remember to read and follow it. When making your pull request it will likely have a checklist of things for you to do if you want your PRs reviewed and approved! Once the owner of the repo has decided they can go ahead and approve the PR and merge your changes into the main OG repo. Others can then make a git pull request and see your wonderful code in action.
This is the third section of the course I followed and my learning so far, please enjoy E1 — GIT setup and E2 — Remote GIT if you haven’t already. I hope you have enjoyed and follow for the final part where I cover the advanced powers of GIT!
Thank you for reading my first Wild Wonder! 💛
