See if the structure makes sense to someone who doesn’t know as much about your projects. It matters less for day-to-day use if you have well-named files that can be opened with a fuzzy finder. The structure you pick primarily influences discoverability. You can weave the other projects into this one. These make great candidates as a starting point for the root of your monorepo. You may also have a sort of super-project that ties the other projects together. If you have several projects of the same kind, you may want to sort them into different subfolders of top-level folders such as “services,” “modules,” and “tools.” This is the approach my client and my team took with a brand-new monorepo, though it would’ve also been a great strategy if importing.
This is the approach I took with an internal project recently since each one was part of a collection of interoperating services. Visualizing Where You Want to BeĪn important first step is to visualize where you want to go with this migration. For example, you might want to import each project into a new folder in the root directory. You can weave several repositories together, moving each repository into its own folder, and keep every change made in every repository. Do the simplest thing that can possibly work.īut if you want to keep history, read on. It’ll be as if all projects just appeared one day, fully written. If that’s not important, you can stop reading now. The problem is, you won’t have that history.
#COMMIT AND PUSH TO A DIFFERENT BRANCH NOT MASTER GIT CODE#
Let’s back up a moment - you actually can just copy code into a new monorepo. What can you do? Why You Can’t Just Copy Code In Keeping this history would be really nice, but you also want to organize projects into their own folders. Some have even brought history along from pre-Git days. Maybe you want to simplify testing or deploy everything together with infrastructure-as-code.īut those original repositories carry a lot of history. Maybe you want to share code without constantly publishing dependencies. The next step is to delete the master branch on GitHub.So you have a bunch of Git repositories for individual projects and you want to bring them together into a monorepo. Now that we have a main branch on our local computer, a main branch up on GitHub, and the default branch on GitHub is the main branch. Nice job! One more step to get, we just need to get rid of the master branch so that the main branch is the only branch. Next, click the arrows to change the default branchĪfter the default branch change, you can go back to the main repo page and see that main is now the default branch. Then on the lefthand menu, click on branches
On the main page for your repo, click on settings. We are going to change it so the default repo and the checkmark are next to the main branch. If you go to the main repo page on GitHub and select the branches dropdown menu, you will see two branches listed and a checkmark next to master. You need to do this on GitHub, not on your local computer. You can see which branch you are on using the command below:Ĭhange the default branch on GitHub to main The first step is to create a new branch locally (on your computer) called main. Step 1Ĭreate a new main branch locally, taking the history from master So change all of your GitHub repo names to main. This is confusing and leads to creating new branches that you don't want. Is the master branch in charge of anything? Are other branches subservient to it? And a very practical reason is that since GitHub moved to use main as the default branch, you have to remember when to use git push origin main and when to use git push origin master on a repo-to-repo basis. In addition, the name main just makes more sense.
Language in programming, like master, that supports symbols of racism has no place. The reason to use the name main as the default branch on Github and in your local git repos is that it's the right thing to do. Git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main
0 kommentar(er)
