Tell us what’s happening:
Hello Everyone !
can you please help me if you know how to use github?
so I am working on a project with two people, I created an empty repo and added them to the repo, now I’ll start to do my part, and each of them has to do a certain part of the website, each of us will create a branch,
now , how do we combine them together? since I am the one who will do the header should all of them has my code first then continue writing their code?
Thank you so much ,
Tell us what’s happening:
Since you specifically talked about GitHub, did you had a look at the introductory guide to git?
I think you’ll find all your answers there
Thank you so much , I will take a look at the guide right now
Yeah, like Marmiz say, read that guide. I’d also say to look for some youtube tutorials.
now , how do we combine them together?
Right. Usually there is a branch called “master” or “main”. That is your main branch and you don’t work on that. When you work on your stuff, you create a branch. Then usually you “merge” it with master. Depending on your level of trust, you could either do that locally, merging your branch into master and then pushing up, or you can do a “pull request” where you push your project branch up to github and it creates a “pull request” to merge your code into master. Then people can look at it, comment, approve it, whatever. Then once it’s approved, it gets merged into master on the repo. There are other variations.
Yes, it’s confusing. But once you get it working, it is truly magical what it does and allows you to do. But yes, it will be confusing for a little while.
This is extremely helpful ! Thank you for clearing these things out .
I think I got it more now, so if my work got approved , and merged to master, my collogues could do their work and use a certain command that pulls the latest version of the master and solve conflicts when they occur.
It’s indeed confusing , as a beginner, there are a lot of challenging things for me , but the feeling I get when things work out , is totally worth the hardships
My typical workflow would be:
git checkout master # if I'm not already on master git pull master # make sure master is current git checkout -B myBranch # create my branch off of current master and move to that branch # do all my work git add . # make sure git is tracking all these files git commit -m "added scrolling" # commit with a commit message git push # push my changes up to the remote repo and start a pull request
Sometimes, before doing push, I’ll want to make sure that my branch is current with master (especially if a lot of changes have gone in) so I will (before the push):
git checkout master git pull git checkout myBranch git merge master # if it didn't auto-merge, I may have to do another add and commit here
That is a basic workflow. At that point it’s a pull request on the repo. If it can automatically merge, it will do that for you (once it’s time to merge). If not, it will tell you that there are merge conflicts and then you have to do it yourself.
Merging is a bit of an art form. There are tools and IDE things that help, but that is specific to your setup. Generally, the smaller the diff in your PR (the few things you touched) the fewer merge problems you have. Breaking things into small chunks and PRing often makes for easy merges.
I should also point out that that is doing everything from the command line. Like with merging, there are tools that make this more visual and some people prefer those.
And there are other ways to organize this. Some people have a staging branch before you get into the release branch. Some people have branches for different features that then get merged into master after they’re done.
Just wanted to say that yes, git is definitely not the most intuitive thing @beesha. But the way you’re learning it here is what it’s designed for. It’s definitely going to be quite painful, but there are a lot of people on the forums who use it daily and you’ll be able to get answers to any of the questions you have and help with the issues you’re going to hit.
Just a couple of basic things:
- small changes are much easier to deal with. Commit often. Branch off, make a small change, make sure it works, make a PR, merge it in. This can’t always be done and it takes a lot of discipline, but it means the code is much easier to review and the chances of conflicts is much lower. It means you have to figure out how to break the work down into small meaningful parts though (which is where the discipline comes in). It also means you don’t have branches that diverge completely from each other (which is where merge conflicts come in).
- try to make sure each commit leaves you with a [still] fully functional piece of software. This might seem obvious, but again it isn’t always possible, but should always strive for that. Small commits help a lot with this, as if there is an issue, it’s much easier to find where a problem has been introduced.
I’ve actually followed parts of the commands you’ve shared , and THANK YOU, it helped me a lot , and my code went pretty smoothly !
I’ve taken notes from the things you wrote , I am so grateful
Got your point! Actually I’ve not followed this method (yet) when working with github, I always write the fully code, then commit the changes all at once. I am currently working on a website, which needs good analyzes and breaking bigger tasks into smaller ones, the points you added are what I need to accomplish my tasks with a full understanding of what’s going on.
Thank you so much for helping me out
But Dan makes an important point.
A lot of this has to do with planning, breaking things into small chunks that can be worked on incrementally. As Dan says, try to break these tasks into small chunks that still render a functioning app. If you have a features that aren’t quite ready, you can hide them behind feature flags until they are.
I know this kind of work flow may seem uncomfortable at first, but if you are part of a team, it really, really makes your life easier in the long run.