This is the second in a series on Git.
I’m not happy with the description of the workflow in the previous posting. It isn’t wrong, it is just a bit oversimplified. Let’s look at the workflow that you’ll usually do.
Assume you have a repository named Test10, and you have the branch main that was created for you and that is shared among your entire team. You now want to create and work on feature1. You enter
git checkout main git pull git branch feature1 git checkout feature1
You start by checking out main — this gets it from your local repository and puts it in your working area. You then invoke pull to update your branch with the latest from the remote repository. Now your working area has the latest from the main branch.
Next, you create your branch feature1 (third line). You might think this would put you on feature1 but you’d be wrong. You still have to check it out.
Since feature1 was branched from main, and you’ve made no changes, you still have the same code — the code from main in your working area.
Create a console application and name it Test10. In VS the new project will be born with some code. Before you make any changes, let’s get that code into our repo.
git status git add feature1/ git commit
When you typed status, git came back and told you that you had an untracked file. It is actually the entire folder. You add that folder which puts it into the index, and then you commit it which puts it into the local repository.
You now start making changes: revising some files, adding new files, etc. Let’s assume you create a new class (Calculator.cs) and you modify Program.cs. At a good stopping point you’ll want to commit these changes. If you enter
git will come back and tell you that you have an untracked file and a modified file.
Let’s add them both to the index and then commit them.
git add Test10/Test10/Program.cs git add Test10/Test10/Calculator.cs git commit
If you forget to enter a commit message your editor will open and prompt you for one. If you are using VSCode, it might look like this:
Type in a message, save and exit. Git will recognize that what you’ve typed is the message for your commit.
Let’s make another set of changes, modifying Calculator.cs and also modifying Program.cs When that is done, enter
Git will inform you that you. have two modified files. Those files are not yet in the index, and git will not only tell you that they are not staged, it will offer the advice that you use git add <file>. You can then commit the files and then add a message. Or, you can combine all three steps into one line.
git commit -a -m "Add subtract method and second line to program"
Here you have called commit, used the -a (for all) which will stage and commit all the modified files, and used -m (message) followed by your commit message. You’ll have committed your files and if you ask for status, you’ll be told that you are on branch feature1, that there is nothing to commit, and that the working tree is clean. In other words, you’re all set.
Now at this point you have made two commits to your local branch, but the server knows nothing about these commits. Let’s get a copy of those commits up onto the server. To do so, enter
Uh oh. Since this is the first push of this branch, it will come back and say that there is no upstream branch. That is, feature1 doesn’t exist on the server. Fortunately, git also gives you the command to solve this problem. Just copy it and paste it into the prompt and your branch will sail through.
git push --set-upstream origin feature1
After this first time, git push will work for this branch without any folderal.
You can continue to develop and commit and push until you think you are done. At that point, you’ll want to merge your code into main. You’ll do so in three steps
- Merge develop into your branch
- Do an interactive rebase
- Merge your branch into develop
The how’s and why’s of these steps will be covered in the next installment.