You know, I am looking for the good git tutorials, and I am not finding them. Here is one of the standard cheatsheets.
Yes, it is easy to bob back and forth between branches.
Branches in git can be way more ephemeral than they were in code repositories in the 1990s.
That means in a typical work day, I am going to go to the develop branch, and do a
git pull
to make sure that I am up-to-date with all the changes my colleagues made yesterday.
Now that I am up-to-date, I am going to do
git checkout -b feature/my_new_branch
That means, I am checking out a new branch called "feature/my_new_branch"
Then, I will muck about on my branch.
When I am done with the mucking about part, I will do
git add .
which will stage all the files I created and prepare them for upload. The "." means "add all the files." I can choose to add some of the files instead, but usually I add them all.
Then I will
git commit -m "Ooh boy, I changed the thingamabob"
This will attach a short message to the staged things.
Then I will
git push
which will send the things to github.
That will only send them if my branch exists on github and all that. If it fails because the branch does not exist on github, it gives you a helpful message to make your branch exist on github. I created a shortcut for the command so I don't remember what it is.
Once on github, I will go to the "Pull requests" tab, and it will say, "Hey, it looks like you uploaded a branch, do you want to do a pull request with that" or something to that effect. I will tell it yes, and then there is a template where my coworkers say, "Explain yourself. What did you do, why did you do it? Do you have a pretty picture?"
Then continuous integration stuff runs. Theses are style checks and code tests. If this fails, I will know how to fix it, or I will say "Help me, this failed in a weird way."
Once it passes all that and the coworkers approve of my nonsense, I do a squash and merge. That means all the things I did get squashed down into one commit and merged into the develop branch.
Some parts of this will be completely irrelevant to you, but that is typically how I use git in my work day.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
timeasmymeasure
no subject
Yes, it is easy to bob back and forth between branches.
Branches in git can be way more ephemeral than they were in code repositories in the 1990s.
That means in a typical work day, I am going to go to the develop branch, and do a
to make sure that I am up-to-date with all the changes my colleagues made yesterday.
Now that I am up-to-date, I am going to do
That means, I am checking out a new branch called "feature/my_new_branch"
Then, I will muck about on my branch.
When I am done with the mucking about part, I will do
which will stage all the files I created and prepare them for upload. The "." means "add all the files." I can choose to add some of the files instead, but usually I add them all.
Then I will
This will attach a short message to the staged things.
Then I will
which will send the things to github.
That will only send them if my branch exists on github and all that. If it fails because the branch does not exist on github, it gives you a helpful message to make your branch exist on github. I created a shortcut for the command so I don't remember what it is.
Once on github, I will go to the "Pull requests" tab, and it will say, "Hey, it looks like you uploaded a branch, do you want to do a pull request with that" or something to that effect. I will tell it yes, and then there is a template where my coworkers say, "Explain yourself. What did you do, why did you do it? Do you have a pretty picture?"
Then continuous integration stuff runs. Theses are style checks and code tests. If this fails, I will know how to fix it, or I will say "Help me, this failed in a weird way."
Once it passes all that and the coworkers approve of my nonsense, I do a squash and merge. That means all the things I did get squashed down into one commit and merged into the develop branch.
Some parts of this will be completely irrelevant to you, but that is typically how I use git in my work day.